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