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

  • Статья

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

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

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

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

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

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

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

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

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

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

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

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

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

Чтобы воспользоваться преимуществами этих журналов, мы рекомендуем оставить включенной диагностику во время создания кластера на портале Azure. Если включить диагностику в развернутом кластере, система диагностики Microsoft Azure сможет распознавать операционный канал, каналы Reliable Services и Reliable Actors, а также хранить данные, как описано в инструкциях по статистической обработке событий с помощью системы диагностики Azure.

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

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

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

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

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

Совет

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

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

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

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

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

Измерение производительности кластера помогает понять, как обрабатывать нагрузку и принимать решения для масштабирования кластера. Дополнительные сведения о масштабировании кластера см. статьях Масштабирование кластера Service Fabric с помощью правил автомасштабирования и Добавление узлов в автономный кластер Service Fabric под управлением Windows Server или удаление узлов из него. Данные о производительности также полезны при сравнении с действиями, которые вы или ваши приложения и службы могли выполнить, для последующего анализа журналов.

Дополнительные сведения о списке счетчиков производительности, данные которых необходимо собрать при использовании Service Fabric, см. в этой статье.

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

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

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

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