Моделирование работоспособности для критически важных рабочих нагрузок

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

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

Моделирование здоровья можно расширить на следующие операционные задачи для критически важного развертывания:

• Служба контроля работоспособности приложения — компонент приложения в вычислительном кластере, предоставляющий API для определения работоспособности системы.

• Мониторинг — коллекция счетчиков производительности и приложений, которые оценивают работоспособность и производительность приложения и инфраструктуры.

• Оповещения — действенные оповещения о проблемах и сбоях в инфраструктуре и приложении.

• Анализ сбоев — разбивка и анализ любых сбоев, включая документацию по первопричине.

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

Дополнительные сведения см. в разделе Моделирование и наблюдаемость критически важных рабочих нагрузок в Azure.

Служба контроля состояния приложения

Служба работоспособности приложения (HealthService) — это компонент приложения, который взаимодействует с службой каталогов (CatalogService) и фоновым процессором (BackgroundProcessor) в рамках вычислительного кластера. Служба HealthService предоставляет REST API для вызова Azure Front Door для определения работоспособности метки. HealthService — это сложный компонент, который отражает состояние зависимостей, помимо собственного.

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

• Он пытается выполнить запрос к Azure Cosmos DB.

• Она пытается отправить сообщение в Центры событий. Фоновый рабочий процесс фильтрует сообщение.

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

• Он запрашивает модель работоспособности, чтобы определить, находятся ли все операционные метрики в предопределенных пороговых значениях. Если модель работоспособности показывает, что метка неработоспособна, трафик не должен направляться к метке, даже если другие тесты HealthService прошли успешно. Модель работоспособности принимает более полное представление о состоянии работоспособности.

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

Этот шаблон кэширования важен, так как количество запросов к Службе здоровья значительно увеличивается при использовании глобального маршрутизатора, такого как Azure Front Door: каждый пограничный узел в каждом центре обработки данных Azure, который обрабатывает запросы, обращается к Службе здоровья, чтобы определить, имеет ли он функционирующее внутреннее подключение. Кэширование результатов снижает дополнительную нагрузку на кластер, созданную проверками работоспособности.

Настройка

HealthService и CatalogService имеют общие параметры конфигурации между компонентами, за исключением следующих параметров, используемых исключительно службой HealthService:

Внедрение

Все проверки выполняются асинхронно и параллельно. Если любой из них отказал, то весь штамп будет считаться недоступным.

Результаты проверки кэшируются в памяти с помощью стандартного недистрибуированного ASP.NET Core MemoryCache. SysConfig.HealthServiceCacheDurationSeconds управляет истечением срока действия кэша. Значение по умолчанию — 10 секунд.

В следующей таблице описаны проверки работоспособности компонентов в инфраструктуре:

запросы Azure Cosmos DB

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

SELECT GetCurrentDateTime ()

Запрос записи создает заполнитель ItemRating с минимальным содержимым:

var testRating = new ItemRating()
{
    Id = Guid.NewGuid(),
    CatalogItemId = Guid.NewGuid(), // Create some random (=non-existing) item id
    CreationDate = DateTime.UtcNow,
    Rating = 1,
    TimeToLive = 10 // will be auto-deleted after 10sec
};

await AddNewRatingAsync(testRating);

Наблюдение

Azure Log Analytics используется в качестве центрального хранилища для журналов и метрик для всех компонентов приложения и инфраструктуры. приложение Azure Insights используется для всех данных мониторинга приложений. Каждая метка в инфраструктуре имеет выделенную рабочую область Log Analytics и экземпляр Application Insights. Отдельная Log Analytics рабочая область используется для глобальных общих ресурсов, таких как Front Door и Azure Cosmos DB.

Все марки недолговечны и постоянно заменяются с каждым новым выпуском. Рабочие области Log Analytics, соответствующие каждой метке, развертываются как глобальный ресурс в отдельной группе ресурсов мониторинга, как это делается для ресурсов Log Analytics метки. Эти ресурсы не имеют общий жизненный цикл с штампом.

Дополнительные сведения см. в статье Унифицированный приемник данных для коррелированного анализа.

Мониторинг: источники данных

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

• Kubernetes мониторинг: параметры диагностики используются для отправки журналов и метрик службы Azure Kubernetes (AKS) в Log Analytics. AKS настраивается для использования Container Insights. Container Insights развертывает OMSAgentForLinus с помощью DaemonSet Kubernetes на каждом узле в кластерах AKS. OMSAgentForLinux может собирать дополнительные журналы и метрики из кластера Kubernetes и отправлять их в соответствующую рабочую область Log Analytics. Эти дополнительные логи и метрики содержат более детализированные данные о модулях, развертываниях, службах и общей работоспособности кластера. Чтобы получить больше аналитических сведений от различных компонентов, таких как ingress-nginx, cert-manager и другие компоненты, развернутые в Kubernetes рядом с критически важной рабочей нагрузкой, можно использовать сбор данных Prometheus. Конфигурация сбора данных Prometheus настраивает OMSAgentForLinux для сбора метрик Prometheus с различных конечных точек в кластере.

• мониторинг данных с помощью Application Insights: Application Insights используется для сбора и мониторинга данных из приложения. Код подготовлен для сбора данных о производительности приложения с помощью Azure Monitor OpenTelemetry Distro. Собираются критически важные сведения, такие как результирующий код состояния, длительность вызовов зависимостей, и счетчики необработанных исключений. Эта информация используется в модели работоспособности и доступна для оповещения и устранения неполадок.

Мониторинг: тесты на доступность в Application Insights

Для мониторинга доступности отдельных штампов и общего решения с внешней точки зрения тесты доступности Application Insights настраиваются в двух местах.

• Региональные тесты доступности: эти тесты настраиваются в региональных экземплярах Application Insights и используются для мониторинга доступности меток. Эти тесты направлены непосредственно на кластеры и статические учетные записи хранения стемпов. Чтобы обратиться к точкам входа в кластеры напрямую, запросы должны содержать правильный заголовок "Front Door ID", в противном случае ингресс-контроллер отклоняет запросы.

• Глобальный тест на доступность: Эти тесты настраиваются в глобальном экземпляре Application Insights и используются для мониторинга доступности всего решения посредством опроса Front Door. Используются два теста: один для тестирования вызова API к CatalogService и один для проверки домашней страницы веб-сайта.

Мониторинг: запросы

Azure Mission-Critical использует различные запросы языка запросов Kusto (KQL) для реализации пользовательских запросов в качестве функций для получения данных из Log Analytics. Эти запросы хранятся в виде отдельных файлов в нашем репозитории кода, разделённых на глобальные и маркированные развертывания. Они импортируются и применяются автоматически через Terraform в рамках каждого запуска конвейера инфраструктуры.

Этот подход отделяет логику запроса от слоя визуализации. Запросы Log Analytics вызываются непосредственно из кода, например из API HealthService. Другим примером является средство визуализации, такое как Azure Dashboards, Monitor Workbooks или Grafana.

Мониторинг: визуализация

Мы используем Grafana для визуализации результатов проверок состояния анализа журналов Log Analytics. Grafana показывает результаты Log Analytics запросов и не содержит логики. Мы выпускаем стек Grafana отдельно от жизненного цикла развертывания решения.

Дополнительные сведения см. в разделе "Визуализация".

Оповещение

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

Эти оповещения образуют расширение модели работоспособности, оповещав оператора об изменении состояния работоспособности, либо на пониженное или желтое состояние, либо на неработоспособное или красное состояние. Задав оповещение для корневого узла модели работы, оператор немедленно узнаёт о любом влиянии на бизнес-уровне, которое сказывается на состоянии решения. Ведь этот корневой узел станет жёлтым или красным, если любой из используемых потоков пользователей или ресурсов сообщает о жёлтых или красных метриках. Оператор может направить свое внимание на визуализацию модели работоспособности для устранения неполадок.

Дополнительные сведения см. в статье "Автоматизированное реагирование на инциденты".

Анализ отказов

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

В следующей таблице перечислены примеры случаев сбоя различных компонентов архитектуры.

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