Поделиться через

Мониторинг кластера

  • Статья

Важно отслеживать на уровне кластера, чтобы определить, работает ли ваше оборудование и кластер должным образом. Хотя Service Fabric может поддерживать работу приложений во время сбоя оборудования, важно понять, где произошел сбой: в самом приложении или в базовой инфраструктуре. Кроме того, необходимо наблюдать за своими кластерами, чтобы оптимально планировать производительность, что поможет принимать решение о добавлении или удалении оборудования.

Service Fabric предоставляет несколько событий структурированной платформы, например события Service Fabric, с помощью EventStore и различных готовых журналов каналов.

В Windows доступ к событиям Service Fabric можно получить от одного поставщика трассировки событий Windows с набором соответствующих фильтров logLevelKeywordFilters, использующихся для переключения между каналами "Операционный" и "Данные и обмен сообщениями". Так отделяются исходящие события Service Fabric для фильтрации нужным образом.

  • Операционный канал. Высокоуровневые операции, выполняемые Service Fabric и кластером, включая ожидаемые события для узла, новые развертываемые приложения, откат обновлений и т. д. Полный список событий см. здесь.

  • Операционный канал (подробные сведения):
    отчеты о работоспособности и решения для балансировки нагрузки.

Канал операций можно получить с помощью различных способов, включая журналы событий ETW/Windows, EventStore (доступно в Windows в версиях 6.2 и более поздних версиях для кластеров Windows). EventStore позволяет получить доступ к событиям кластера для каждой сущности (включая кластер, узлы, приложения, службы, секции, реплики и контейнеры) и предоставляет эти события через интерфейсы REST API и клиентскую библиотеку Service Fabric. EventStore позволяет отслеживать кластеры для разработки и тестирования, а также получать сведения о состоянии кластеров в рабочей среде в определенный момент времени.

  • Канал данных и обмена сообщениями:
    критически важные журналы и события, создаваемые в системе обмена сообщениями (сейчас только ReverseProxy) и расположении данных (модели Reliable Services).

  • Канал данных и обмена сообщениями (подробные сведения):
    Подробный канал, содержащий все некритические журналы из данных и сообщений в кластере (этот канал имеет большой объем событий).

Кроме этих каналов, есть еще два структурированных канала "Источники событий", а также журналы, которые мы собираем для предоставления поддержки.

  • События Reliable Services
    определенные события модели программирования.

  • События Reliable Actors
    определенные события модели программирования и счетчики производительности.

  • Журналы поддержки:
    системные журналы, созданные Service Fabric только для использования нами при предоставлении поддержки.

Эти различные каналы охватывают большую часть компонентов ведения журнала на уровне платформы, которое рекомендуется использовать. Чтобы оптимизировать ведение журнала на уровне платформы, важно разобраться с моделью работоспособности, добавить настраиваемые отчеты о работоспособности и настраиваемые счетчики производительности, чтобы в режиме реального времени отслеживать влияние служб и приложений на кластер.

Чтобы воспользоваться преимуществами этих журналов, настоятельно рекомендуется оставить функцию "Диагностика" включенной во время создания кластера в портал Azure. Включив диагностика при развертывании кластера, Диагностика Azure сможет подтвердить каналы операционных, надежных служб и надежных субъектов, а также сохранить данные, как описано далее в статистических событиях с Диагностика Azure.

Отчеты о работоспособности и нагрузке Azure Service Fabric

В Service Fabric используется собственная модель работоспособности, которая подробно описана в следующих статьях.

Мониторинг работоспособности крайне важен для многих аспектов работы службы, особенно во время обновления приложения. После того как каждый домен обновления службы обновляется, для него проводится проверка работоспособности. Только после этого можно переходить к развертыванию службы в следующем домене обновления. Если невозможно достичь состояния работоспособности OK, развертывание откатится, чтобы приложение оставалось в известном состоянии OK. В этот период до отката службы некоторые клиенты могут столкнуться с проблемами, но для большинства из них процесс пройдет незаметно. Устранение проблемы происходит довольно быстро и не требует вмешательства человека. Чем больше проверок работоспособности внедрено в код, тем устойчивее служба к проблемам развертывания.

Еще один аспект работоспособности службы — передача метрик из службы. Метрики важны в Service Fabric, так как они используются для балансировки использования ресурсов. Метрики также служат признаком работоспособности системы. Допустим, вы используете приложение с несколькими службами, в котором каждый экземпляр передает метрику количества запросов в секунду (RPS). Если одна из служб использует больше ресурсов, чем другая, Service Fabric перемещает экземпляры службы по кластеру, поддерживая равномерное использование ресурсов. Использование ресурсов подробно описано в статье Управление потреблением ресурсов и нагрузкой в Service Fabric с помощью метрик.

Также метрики дают представление об эффективности службы. С их помощью вы можете убедиться, что служба работает с соблюдением заданных параметров. Например, если статистические данные показывают, что в 9:00 в понедельник выполняется в среднем 1000 запросов в секунду, вы можете настроить отчет о работоспособности, который оповестит о том, что число запросов в секунду оказалось больше 1500 или меньше 500. Возможно, все работает нормально, но такие отклонения следует проверять дополнительно, чтобы гарантировать удобство работы для ваших клиентов. Для службы можно определить набор метрик, которые будут информировать о работоспособности, но не будут использоваться для балансировки ресурсов кластера. Для этого присвойте весу метрик нулевое значение. Рекомендуется запускать все метрики с нулевым весом, а не увеличивать вес, пока вы не уверены, что вес метрик влияет на балансировку ресурсов для кластера.

Совет

Не используйте много метрик с ненулевым весом. Вам будет сложно понять, почему экземпляры службы перемещаются для балансировки. Нескольких метрик вполне достаточно.

Для метрик и отчетов о работоспособности подойдет любая информация, которая указывает на работоспособность и производительность приложения. Счетчик производительности ЦП может показать, как используется узел, но он не даст информации о работоспособности определенной службы, так как на одном узле может быть запущено несколько служб. Для этих целей лучше подойдут такие метрики, как количество запросов в секунду, количество обработанных элементов или задержка выполнения запроса.

Журналы поддержки Service Fabric

Если вы будете обращаться в службу поддержки корпорации Майкрософт с вопросами по управлению кластером Azure Service Fabric, вам почти наверняка потребуются журналы поддержки. Если кластер размещен в Azure, эти журналы автоматически настраиваются в процессе создания кластера, а затем собираются. Эти журналы хранятся в выделенной учетной записи хранения, размещенной в группе ресурсов вашего кластера. У этой учетной записи хранения нет фиксированного имени, но ее можно опознать по наличию таблиц и контейнеров больших двоичных объектов, имена которых начинаются с префикса fabric. Сведения о настройке сбора журналов для автономного кластера см. в статьях Создание изолированного кластера под управлением Windows Server и Параметры конфигурации для автономного кластера Windows. Для автономных экземпляров Service Fabric журналы следует передавать в локальный файловый ресурс. Вам необходимо иметь эти журналы для поддержки, но они не предназначены для использования кем-либо за пределами группы поддержки клиентов Майкрософт.

Показатель производительности

Измеряйте производительность кластера, чтобы понять, как она может обрабатывать нагрузку и управлять решениями по масштабированию кластера (см. дополнительные сведения о масштабировании кластера в Azure или локальной среде). Данные о производительности также полезны при сравнении с действиями, которые вы или ваши приложения и службы могли предпринять при анализе журналов в будущем.

Список счетчиков производительности, собираемых при использовании Service Fabric, см. в разделе "Метрики производительности"

Ниже приведены два простых способа настройки сбора данных производительности для кластера:

  • Использование агента.
    Это предпочтительный способ сбора данных производительности на компьютере. У агентов обычно есть список возможных метрик производительности, которые можно собрать. Процесс их выбора или изменения достаточно прост. Дополнительные сведения об агенте Log Analytics (агенте наблюдения, который может собирать данные производительности для виртуальных машин кластера и развернутых контейнеров) см. в следующих статьях о журналах Azure Monitor как о предложении Azure Monitor: Интеграция журналов Azure Monitor и Настройка агента Log Analytics.

  • Счетчики производительности в Хранилище таблиц Azure.
    Вы также можете отправлять метрики производительности в то же хранилище таблиц, что и события. Это требует изменения конфигурации системы диагностики Azure таким образом, чтобы выполнялся сбор соответствующих данных счетчиков производительности с виртуальных машин в кластере и статистики Docker при развертывании контейнеров. Дополнительные сведения о настройке счетчиков производительности в WAD и Service Fabric для настройки их сбора см. в этой статье.

Следующие шаги