Создание системы мониторинга для рабочих нагрузок Azure

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

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

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

В этом руководстве рассматривается процесс создания этих этапов и предоставляется рекомендации. Он не охватывает специализированные варианты использования мониторинга, такие как безопасность. Руководство основывается на ключевых стратегиях, описанных в стратегиях архитектуры OE:07 для разработки системы мониторинга, которую необходимо сначала просмотреть.

Терминология

Этап 1. Инструментирование

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

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

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

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

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

Лучшие практики для инструментирования

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

• Выберите технологию, которая не зависит от языка и может интегрироваться с несколькими платформами мониторинга. OpenTelemetry — это независимая от поставщика опция, которую используют множество приложений.

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

• Используйте структурированную телеметрию, которая записывается как в форматах, доступных для чтения человеком, так и в машинном режиме (JSON, MessagePack, Protobuf).

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

• Классифицировать по операционным задачам , чтобы повысить эффективность фильтрации и анализа. Например, укажите назначение данных телеметрии для аудита, безопасности, отладки или производительности.

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

Пример: инструментирование

Рассмотрим приложение электронной коммерции. Когда клиент помещает заказ, начинается бизнес-транзакция. API обрабатывает платеж, базу данных записывает заказ и отправляется сообщение электронной почты подтверждения. Когда система работает должным образом, все завершается в течение ожидаемого периода времени. Но предположим, что что-то сломается.

Без инструментирования вы можете увидеть только сообщение «Сбой при оформлении заказа». Нет контекста, нет ясной причины, в то время как пользовательский опыт незаметно ухудшается. Устранение неполадок становится угадыванием. Не работает ли база данных? Истек ли срок ожидания почтового сервера? Возникают ли проблемы с поставщиком платежей?

При надлежащем инструментировании запрос отслеживается от начала до конца через каждый компонент. Журналы показывают, что платежный API вернул ошибку 500. Распределенная трассировка показывает резкий скачок задержки в службе оплаты. Показатели подтверждают, что уровень отказов при оформлении заказа вырос с 1% до 8% за 10 минут. Это делает диагностику систематическим и управляемым данными, а не спекулятивным.

Этап 2. Сбор и хранение данных телеметрии

Хотя инструментирование касается того, какие операционные сигналы следует отслеживать, этот этап заключается в том, куда направлять данные телеметрии и управлять ими ответственно.

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

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

Данные телеметрии обычно берутся из следующих источников:

• Данные телеметрии на уровне приложения. После инструментирования приложения с помощью пакетов SDK или стандартов, таких как OpenTelemetry, данные телеметрии можно извлекать автоматически с помощью средства управления производительностью приложений (APM), например Azure Application Insights. Он автоматически фиксирует пользовательские бизнес-метрики, такие как OrderPlaced и NewUserProfileCreated, а также данные диагностики, такие как исключения приложений, длительность зависимостей и распределенные трассировки. Затем эти данные передаются в журналы Azure Monitor для анализа. Application Insights позволяет управлять периодами хранения данных, настраивать выборку и управлять определенными параметрами конфиденциальности.

• Телеметрия узла приложения. Хосты приложений излучают несколько категорий телеметрии. Эти сигналы помогают отслеживать поведение платформы приложений, таких как скорость запросов, длина очереди запросов, время отклика, количество вызовов зависимостей и распределение кода состояния HTTP. Application Insights хорошо интегрирован с большинством служб размещения приложений Azure, таких как Функции Azure, Служба приложений и виртуальные машины.

• Журналы платформы. Существует телеметрия, генерируемая другой инфраструктурой, на которой работает приложение. В Azure это в основном журналы действий и журналы ресурсов. Журналы действий отслеживают операции на уровне подписки (создание ресурсов, обновления, удаление). Журналы ресурсов, которые записывают события, относящиеся к ресурсам, например журналы доступа к хранилищу, события брандмауэра.

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

  Для сбора журналов платформы требуется явная настройка. Например, агент Azure Monitor. При установке на виртуальных машинах он извлекает локальные журналы и передает их в Azure Monitor, Microsoft Sentinel и Microsoft Defender для облака.

Решение о хранении данных телеметрии

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

Создайте матрицу, которая четко выделяет варианты использования, требования и технологии. Приведем пример:

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

Рекомендации по производительности и надежности телеметрии

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

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

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

Управление жизненным циклом данных телеметрии

Не все данные телеметрии должны жить вечно. Будьте уверены, как долго вы хотите сохранять данные, основываясь на их использовании. Например, необработанные данные отладки могут требовать только краткосрочного хранения, в то время как метрики производительности, исторические тенденции или записи аудита могут потребовать долгосрочного хранения.

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

Помимо политик хранения, которые архивируют старые данные в хранилище с более низкими затратами, существуют и другие методы оптимизации затрат. При необходимости выполните понижение детализации для уменьшения объёма хранилища, сохраняя при этом достаточное разрешение для анализа. Агрегировать связанные события, чтобы сократить объем хранилища и ускорить обработку данных.

Безопасность данных телеметрии

Хотя телеметрия не является функциональными данными рабочей нагрузки, она по-прежнему важна с точки зрения работы. С точки безопасности: защита данных от случайного удаления; управление доступом с помощью управления доступом на основе ролей (RBAC). Рассмотрим использование следующих вариантов:

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

• Примените блокировки ресурсов, чтобы предотвратить непредвиденные изменения или удаление важных ресурсов.

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

Этап 3. Корреляция, агрегирование, анализ

После сбора и хранения данных телеметрии необходимо преобразовать необработанные данные (журналы, метрики и трассировки) в аналитические сведения. Результат этого этапа заключается в том, чтобы понять , что означает значение данных и как обеспечить, чтобы правильные люди могли действовать с ними?

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

• Испытывают ли пользователи сбои?
• Снижается ли производительность?
• Замедляются ли зависимости?
• Достигнут ли предел емкости?
• Наблюдается ли снижение ключевых показателей эффективности бизнеса?

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

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

Корреляция

Корреляция — это процесс связывания данных телеметрии с нескольких системных слоев , чтобы понять, что происходит во всей среде приложения. Хотя отдельные журналы, метрики или трассировки предоставляют моментальные снимки активности, корреляция объединяет эти фрагменты, чтобы выявить связи причин и эффектов.

Корреляция также важна для диагностики сбоев. Исключение в компоненте нижнего уровня (например, в базе данных или службе инфраструктуры) может распространяться вверх и вызывать ошибки на уровне приложения.

Для поддержки эффективной корреляции данные телеметрии должны включать достаточный контекст, например идентификаторы действий или идентификаторы корреляции, метки времени в универсальном формате и идентификаторы служб или компонентов. Убедитесь, что информация включена во время инструментирования.

Поддержка горячего, теплого и холодного анализа

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

• Горячий анализ (в режиме реального времени)

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

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

• Теплый анализ (исследование почти в режиме реального времени)

  Теплый анализ происходит после сбора и легко агрегирования телеметрии. Обычно это связано с сопоставлением нескольких источников телеметрии, чтобы понять, почему что-то произошло.

  Для этого анализа требуется агрегирование нескольких событий, корреляции и статистического анализа в группе событий.

  Часто используется теплый анализ для анализа производительности и устранения неполадок с операционной деятельностью.

• Холодный анализ (исторические долгосрочные данные)

  Холодный анализ работает с большими объемами исторических данных телеметрии и обычно выполняется на запланированной или нерегламентированной основе. Это полезно для выявления тенденций в течение длительного периода.

Рекомендации по оповещениям

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

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

Пример: корреляция, агрегирование, анализ

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

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

На основе собранных метрик они изучили показатели платформы за тот же период и заметили, что загрузка ЦП сервера базы данных достигла и оставалась на уровне 90% за этот период, что подтвердило, что исчерпание ресурсов базы данных на уровне инфраструктуры было причиной таймаутов запросов.

Теплый анализ показал, что причина была зависимость от базы данных, которая находилась под тяжелой нагрузкой, так как:

• Журналы приложений показали ошибки с исключениями времени ожидания
• Задержка базы данных удвоилась в течение этого времени
• Журналы платформы показали, что загрузка процессора на сервере базы данных составляет 90%.

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

Этап 4. Визуализация

С помощью анализа необходимо выполнить следующие действия. Как сделать аналитические сведения видимыми?

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

Рекомендации по визуализации

• Ориентируйтесь на модель работоспособности, показывающую, что компоненты должны быть помечены как "Работоспособный", "Деградировавший" или "Неработоспособный" в соответствии с целями по обслуживанию (СЦО).

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

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

• Настройка панелей мониторинга для целевой аудитории. Например,

  Аудитория	Просмотр
  Разработчики	Журналы в режиме реального времени, трассировки, тенденции ошибок
  Операторы	Ключевые показатели эффективности, использование ресурсов, оповещения
  Заинтересованные лица бизнеса	Высокоуровневые метрики, ключевые показатели эффективности, влияющие на доходы

• Настройка панелей мониторинга для предполагаемого использования. Например,

  Использование	Просмотр
  Операционные отчеты	Использование ресурсов, тенденции, исключения, эффективность
  Отчеты о безопасности	Аудит действий пользователей, отслеживание аномалий соответствия требованиям
  Бизнес-отчеты	Тенденции ключевого показателя эффективности, доход на пользователя, транзакции с течением времени

Пример. Визуализация

Давайте вернемся к приложению электронной коммерции. Ориентированная на разработчика панель мониторинга визуализирует:

• Тенденции задержки за последние 24 часа
• Частота сбоев по конечной точке
• Использование ЦП базы данных
• Заказы обрабатываются в минуту

На этой панели мониторинга разработчик может сузить сведения о пиках сбоев, когда ЦП базы данных превышает 85%. Между тем, если задержка превышает 2 секунды для потока пользователя оформления заказа, разработчик видит идентификатор запроса, загрузку базы данных и последние ошибки. На этом этапе при достаточном тестировании автоматизированного рабочего процесса активируется масштабирование уровня базы данных.

Мониторинг антипаттернов и как избежать их

Следующие антипаттерны чаще всего подрывают эффективность мониторинга рабочих нагрузок.

Упрощение функций Azure

Базовая платформа мониторинга:

• Azure Monitor — это центральная платформа для сбора, анализа и действия с данными телеметрии из облачных и локальных сред. Он предоставляет унифицированные метрики, журналы и мониторинг приложений.

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

  • Журналы Azure Monitor предоставляют Log Analytics с KQL для анализа данных журналов и создания пользовательских аналитических сведений.

  • Оповещения Azure Monitor позволяют интеллектуальное оповещение с группами действий, маршрутизацией уведомлений и автоматическими ответами.

Мониторинг производительности приложений:

• Application Insights предоставляет возможности APM с комплексной трассировкой, сопоставлением зависимостей и аналитикой поведения пользователей.

Визуализация и анализ:

• Azure Workbooks предоставляют возможность создания пользовательских интерактивных панелей с помощью интерактивной аналитики и богатых визуализаций для сценариев с углубленным анализом.

• Панели мониторинга Azure предоставляют централизованные представления ресурсов Azure и данные мониторинга с помощью управления доступом на основе ролей.

• Log Analytics — это подсистема аналитики для запроса и сопоставления журналов с несколькими уровнями с расширенными возможностями тренда.

• Azure VM Insights предоставляет специализированный мониторинг рабочих нагрузок виртуальных машин с картами производительности и отслеживанием зависимостей.

• Служба Azure Container Insights предлагает мониторинг работоспособности кластера, производительности узлов и аналитики на уровне pod.

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

Связанные ссылки

• Рекомендации по проектированию и созданию платформы наблюдаемости
• Создание эффективного плана управления инцидентами для управления нарушениями
• Принципы проектирования эффективности производительности
• Рекомендации по проектированию надежной стратегии мониторинга и оповещения