Поделиться через

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

  • Статья

Применимо к этой рекомендации Power Platform контрольного списка надежности, хорошо продуманной архитектуры:

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

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

Определения

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

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

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

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

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

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

Поймите разницу между метриками, журналами и трассировками.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

  • Длительность запроса
  • Истечение времени ожидания
  • Времена ожидания
  • Нехватка памяти
  • Блокировки

Возможности в Power Platform

Power Platform интегрируется с Application Insights, которая является частью экосистемы Azure Monitor. Вы можете использовать эту интеграцию следующим образом:

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

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

  • Настройте Power Automate телеметрию для передачи в Application Insights. Вы можете использовать эту телеметрию для мониторинга выполнения облачных потоков и создания оповещений о сбоях этого выполнения.

  • Собирайте данные телеметрии от вашего Microsoft Copilot Studio второго пилота для использования в Azure Application Insights. Вы можете использовать эту телеметрию для мониторинга зарегистрированных сообщений и событий, отправляемых вашему второму пилоту и получаемых от него, тем, которые будут запускаться во время разговоров пользователей, а также пользовательских событий телеметрии, которые могут отправляться из ваших тем.

Power Platform ресурсы регистрируют действия на Microsoft портале соответствия требованиям Purview. Большинство событий доступны в течение 24 часов после их наступления. Не используйте эту информацию для мониторинга в реальном времени. Дополнительную информацию о регистрации действий в Power Platform см. в разделе:

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

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

Как проверить работоспособность моего онлайн-сервиса?

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

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

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