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

Рекомендации по мониторингу и диагностике для Azure Service Fabric

  • Статья

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

Мониторинг приложений

В процессе мониторинга приложений фиксируются особенности использования возможностей и компонентов приложения. Следите за работой приложений, чтобы перехватить проблемы, влияющие на пользователей. Ответственность за мониторинг приложения лежит на пользователях, разрабатывающих приложение и его службы, так как он привязан к бизнес-логике приложения. Мы рекомендуем настроить мониторинг приложений с помощью Application Insights, средства мониторинга приложений Azure.

Мониторинг платформы (кластера)

Одна из целей создания Service Fabric — сделать работу приложений устойчивой в случае сбоев оборудования. Это достигается благодаря способности системных служб платформы обнаруживать проблемы с инфраструктурой и быстро выполнять отработку отказа рабочих нагрузок на другие узлы в кластере. Но что делать, если в самих системных службах есть проблемы? Или если при попытке развертывания или перемещения рабочей нагрузки нарушаются правила размещения служб? Service Fabric предоставляет средства диагностики этих и других проблем, чтобы убедиться в том, что вы получаете уведомление о взаимодействии платформы Service Fabric с вашими приложениями, службами, контейнерами и узлами.

Для кластеров Windows рекомендуется настроить мониторинг кластера с помощью агента диагностики и журналов Azure Monitor.

Для кластеров Linux журналы Azure Monitor также являются рекомендуемым средством для мониторинга платформы и инфраструктуры Azure. Системы диагностики для платформы Linux требуют другую конфигурацию, записанную в статье События кластера Service Fabric под управлением Linux в системном журнале.

Мониторинг инфраструктуры

Журналы Azure Monitor рекомендуется использовать для мониторинга событий на уровне кластера. После настройки агента Log Analytics с рабочей областью, как описано в предыдущей статье, вы сможете собирать метрики производительности, например использование ЦП, счетчики производительности .NET, такие как использование ЦП на уровне процесса, счетчики производительности Service Fabric, например число исключений из надежной службы, а также метрики контейнера, такие как использование ЦП. Вам необходимо будет записывать журналы контейнера в stdout или stderr таким образом, чтобы они были доступны в журналах Azure Monitor.

Модули наблюдения

Как правило, модуль наблюдения является отдельной службой, которая может отслеживать работоспособность и нагрузку в службах, проверять связь с конечными точками и сообщать о непредвиденных событиях работоспособности в кластере. Он позволяет предотвратить ошибки, которые невозможно обнаружить только на основе производительности отдельной службы. В модулях наблюдения также удобно размещать код, выполняющий корректирующие действия, не требующие участия пользователя (например, очистку файлов журнала в хранилище через определенные интервалы времени). Если вам нужна полностью реализованная служба наблюдения Servie Fabric c открытым кодом, которая включает в себя простую в использовании модель расширяемости модулей наблюдения и работает в кластерах Windows и Linux, см. проект FabricObserver. FabricObserver — это готовое к использованию программное обеспечение. Мы рекомендуем развертывать FabricObserver в тестовых и рабочих кластерах и расширять его в соответствии с потребностями либо через модель подключаемых модулей, либо создав вилку и добавив собственные встроенные наблюдатели. Рекомендуется использовать первый подход (подключаемые модули).

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