Рекомендации по проектированию надежной стратегии мониторинга и оповещения
Применяется к этой рекомендации проверки надежности платформы Azure Well-Architected Framework:
| RE:10 | Измеряйте и публикуйте индикаторы работоспособности решения. Непрерывно фиксируйте время простоя и другие данные надежности из рабочей нагрузки, а также из отдельных компонентов и ключевых потоков. |
|---|
В этом руководстве описаны рекомендации по разработке стратегии надежного мониторинга и оповещения. Реализуйте эту стратегию, чтобы группы операций были информированы о состоянии работоспособности вашей среды и убедитесь, что выполнены установленные целевые показатели надежности для рабочей нагрузки.
Определения
| Термин | Определение |
|---|---|
| Метрики | Числовые значения, собираемые через регулярные интервалы. Метрики описывают некоторые аспекты системы в определенное время. |
| Журналы ресурсов | Данные, создаваемые системой. Он предоставляет сведения о состоянии системы. |
| Трассировки | Данные, предоставляющие сведения о пути, по которому запрос перемещается через службы и компоненты. |
Основные стратегии проектирования
Перед созданием стратегии мониторинга и оповещения выполните следующие задачи для рабочей нагрузки в рамках планирования надежности:
Определите критические и некритические потоки.
Выполните анализ режима сбоя (FMA) для потоков.
Определение целевых показателей надежности.
Проектирование для надежности путем реализации избыточности, масштабирования, самосохранения и самовосстановления.
Разработка надежной стратегии тестирования.
Моделиируйте работоспособность рабочей нагрузки и ее компонентов.
Создайте стратегию мониторинга и оповещения, чтобы обеспечить надежную работу рабочей нагрузки. Стратегия мониторинга и оповещения обеспечивает осведомленность для ваших рабочих групп, чтобы они уведомляли об изменениях в состоянии рабочей нагрузки и могут быстро устранять проблемы. Создайте надежную и надежную стратегию мониторинга, создав модель работоспособности для критически важных потоков и компонентов, составляющих эти критически важные потоки. Модель работоспособности определяет здоровые, деградированные и неработоспособные состояния. Создайте операционную осанку, чтобы немедленно поймать изменения в этих состояниях. При изменении состояния работоспособности на неработоспособные или неработоспособные механизмы оповещения активируют автоматические корректирующие меры и уведомляют соответствующие команды.
Выполните следующие рекомендации для разработки стратегии мониторинга и оповещений, которая соответствует требованиям вашего бизнеса.
Реализация общей стратегии мониторинга
Понять разницу между метриками, журналами и трассировками.
Включите ведение журнала для всех облачных ресурсов. Используйте автоматизацию и управление в развертываниях, чтобы включить ведение журнала диагностики во всей среде.
Перенаправите все журналы диагностики в централизованный приемник данных и платформу аналитики, например рабочую область Log Analytics. Если у вас есть требования к суверенитету данных региона, необходимо использовать локальные приемники данных в регионах, которые соответствуют этим требованиям.
Компромисс. Существуют затраты на хранение и запросы журналов. Обратите внимание на то, как анализ журналов и хранение влияют на бюджет, и определите оптимальный баланс использования в соответствии с вашими требованиями. Дополнительные сведения см. в рекомендациях по оптимизации затрат.
Если рабочие нагрузки подвержены одной или нескольким платформам соответствия требованиям, некоторые журналы компонентов, обрабатывающие конфиденциальную информацию, также применяются к этим платформам. Отправьте соответствующие журналы компонентов в систему управления безопасностью и событиями (SIEM), например Microsoft Sentinel.
Создайте политику хранения журналов, которая включает долгосрочные требования к хранению, которые платформы соответствия налагают на рабочую нагрузку.
Используйте структурированное ведение журнала для всех сообщений журнала для оптимизации запросов к данным журнала.
Настройте оповещения для активации, когда значения передают критические пороговые значения, которые коррелируют с изменением состояния модели работоспособности, например зеленым на желтый или красный.
Пороговая конфигурация — это практика непрерывного улучшения. По мере развития рабочей нагрузки пороговые значения, которые вы определяете, могут измениться. В некоторых случаях динамические пороговые значения являются хорошим вариантом для стратегии мониторинга.
Рассмотрите возможность использования оповещений при улучшении состояний, таких как красный на желтый или красный цвет, чтобы команды операций могли отслеживать эти события для будущих ссылок.
Визуализировать работоспособность среды в режиме реального времени.
Используйте данные, собранные во время инцидентов, для непрерывного улучшения моделей работоспособности и стратегии мониторинга и оповещения.
Включение служб мониторинга и оповещений облачной платформы, в том числе:
Работоспособности уровня платформы, например Работоспособности служб Azure.
Работоспособности на уровне ресурсов, например Azure Работоспособность ресурсов.
Включите встроенный расширенный мониторинг и аналитику, которые предлагает поставщик облачных услуг, например средства аналитики Azure Monitor.
Реализуйте мониторинг резервного копирования и восстановления для записи:
Состояние репликации данных, позволяющее обеспечить восстановление рабочей нагрузки в целевой целевой точке восстановления (RPO).
Успешные и неудачные резервные копии и восстановление.
Длительность восстановления для информирования о планировании аварийного восстановления.
Мониторинг приложений
Создавайте пробы работоспособности или проверяйте функции и регулярно выполняйте их извне приложения. Убедитесь, что тестируются из нескольких расположений, которые географически близки к клиентам.
Журнал данных во время работы приложения в рабочей среде. Для диагностики причин проблем в рабочем состоянии требуется достаточное количество информации.
Регистрируйте события в границах служб. Включите идентификатор корреляции в границах служб. Если транзакция проходит через несколько служб и одна из них завершается ошибкой, идентификатор корреляции помогает отслеживать запросы в приложении и определить, почему транзакция завершилась ошибкой.
Используйте асинхронное ведение журнала. Синхронные операции ведения журнала иногда блокируют код приложения, что приводит к тому, что запросы на резервное копирование записываются по мере записи журналов. Используйте асинхронное ведение журнала, чтобы сохранить доступность во время ведения журнала приложения.
Разделяйте журнал приложений и аудит. Записи аудита обычно хранятся для обеспечения соответствия нормативным требованиям и должны быть полными. Чтобы избежать удаления транзакций, сохраняйте журналы аудита отдельно от журналов диагностики.
Используйте корреляцию телеметрии, чтобы обеспечить сопоставление транзакций с помощью сквозного приложения и критически важных системных потоков. Этот процесс жизненно важен для выполнения анализа первопричин (RCA) для сбоев. Сбор метрик и журналов уровня платформы, таких как процент ЦП, сеть в сети, исходящие сети и операции с дисками в секунду, из приложения для информирования модели работоспособности и обнаружения и прогнозирования проблем. Этот подход может помочь различать временные и непереходные ошибки.
Используйте мониторинг “белого ящика”, чтобы снабдить приложение семантическими журналами и метриками. Сбор метрик и журналов на уровне приложения, таких как потребление памяти или задержка запросов, из приложения для информирования модели работоспособности и обнаружения и прогнозирования проблем.
Используйте мониторинг черного ящика для измерения служб платформы и результирующего взаимодействия с клиентами. При мониторинге “черного ящика” проверяется наблюдаемое поведение приложения без изучения внутренних компонентов системы. Этот подход распространен для измерения показателей уровня обслуживания (SLIS), целей уровня обслуживания (SLOS) и соглашений об уровне обслуживания (СОГЛАШЕНИЯ об уровне обслуживания).
Примечание.
Дополнительные сведения о мониторинге приложений см . в шаблоне мониторинга конечных точек работоспособности.
Мониторинг данных и хранилища
Отслеживайте метрики доступности контейнеров хранилища. Если эта метрика снижается ниже 100 процентов, она указывает на сбои записи. Временные падения доступности могут произойти, когда поставщик облачных служб управляет нагрузкой. Отслеживайте тенденции доступности, чтобы определить, возникла ли проблема с рабочей нагрузкой.
В некоторых случаях падение метрик доступности для контейнера хранилища указывает на узкий место в вычислительном слое, связанном с контейнером хранилища.
Существует множество метрик для мониторинга баз данных. В контексте надежности важные метрики для мониторинга включают:
Длительность запросов
Время ожидания
Время ожидания
Нехватка памяти
Блокировки
Упрощение функций 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.
Дополнительные ссылки
- Оповещения для DevOps
- Оповещение об операциях
- Руководство по мониторингу и диагностике.
- Мониторинг веб-приложений в Azure
Ссылки на ресурсы сообщества
- Оповещения базовых показателей Azure Monitor (AMBA) — это центральный репозиторий определений оповещений, которые клиенты и партнеры могут использовать для улучшения возможностей наблюдения за счет внедрения Azure Monitor.
Контрольный список надежности
Ознакомьтесь с полным набором рекомендаций.