Рекомендации по разработке надежной стратегии мониторинга и оповещения

  • Статья

Применяется к этой рекомендации по контрольным спискам надежности Платформы Azure Well-Architected Framework:

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

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

Определения

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

Ключевые стратегии проектирования

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

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

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

Общее руководство

  • Узнайте о различиях между метриками, журналами и трассировками.

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

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

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

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

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

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

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

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

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

  • Визуализируйте работоспособность среды в режиме реального времени.

  • Используйте данные, собранные во время инцидентов, для постоянного улучшения моделей работоспособности и стратегии мониторинга и оповещений.

  • Внедрение служб мониторинга и оповещений облачной платформы, в том числе:

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

  • Реализуйте мониторинг резервного копирования и восстановления для записи:

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

    • Успешное и неудачное резервное копирование и восстановление.

    • Продолжительность восстановления для планирования аварийного восстановления.

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

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

  • Данные журнала во время выполнения приложения в рабочей среде. Вам потребуется достаточно информации для диагностики причин проблем в рабочем состоянии.

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

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

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

  • Используйте корреляцию телеметрии , чтобы обеспечить возможность сопоставления транзакций с помощью сквозного приложения и критически важных системных потоков. Этот процесс имеет жизненно важное значение для выполнения анализа первопричин (RCA) для сбоев. Собирайте из приложения метрики и журналы на уровне платформы, такие как процент загрузки ЦП, вход в сеть, выход из сети и дисковые операции в секунду, чтобы информировать модель работоспособности, а также обнаруживать и прогнозировать проблемы. Такой подход помогает различать временные и непереходные сбои.

  • Используйте мониторинг “белого ящика”, чтобы снабдить приложение семантическими журналами и метриками. Собирайте из приложения метрики и журналы уровня приложения, такие как потребление памяти или задержка запросов, для информирования модели работоспособности, а также для обнаружения и прогнозирования проблем.

  • Используйте мониторинг черного ящика для измерения служб платформы и итогового взаимодействия с клиентами. При мониторинге “черного ящика” проверяется наблюдаемое поведение приложения без изучения внутренних компонентов системы. Этот подход является распространенным для измерения ориентированных на клиента показателей уровня обслуживания (SLA), целей уровня обслуживания (SLO) и соглашений об уровне обслуживания (SLA).

Примечание

Дополнительные сведения о мониторинге приложений см. в статье Шаблон мониторинга конечных точек работоспособности.

Мониторинг данных и хранилища

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

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

  • Существует множество метрик для отслеживания баз данных. В контексте надежности важные метрики для мониторинга:

    • Query duration (Длительность запросов)

    • Истекшее время ожидания

    • Время ожидания

    • Нехватка памяти

    • Блокировки

Упрощение azure

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

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

  • Application Insights — это расширение Azure Monitor. Он предоставляет функции мониторинга производительности приложений (APM).

  • Аналитика Azure Monitor — это расширенные средства аналитики, которые помогают отслеживать службы Azure, такие как виртуальные машины, службы приложений и контейнеры. Аналитика основана на Azure Monitor и Log Analytics.

  • Azure Monitor для решений SAP — это собственный продукт мониторинга azure для ландшафтов SAP, работающих в Azure.

  • Политика Azure помогает применять организационные стандарты и оценивать соответствие нормативным требованиям в больших масштабах.

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

  • Рекомендации по использованию нескольких рабочих областей см. в статье Проектирование архитектуры рабочей области Log Analytics.

Пример

Примеры реальных решений для мониторинга см. в разделах Мониторинг веб-приложений в Azure и Базовая архитектура для кластера Служба Azure Kubernetes.

  • Базовые оповещения Azure Monitor (AMBA) — это центральный репозиторий определений оповещений, которые клиенты и партнеры могут использовать для улучшения наблюдаемости благодаря внедрению Azure Monitor.

Контрольный список надежности

Ознакомьтесь с полным набором рекомендаций.

Контрольный список надежности