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

Применяется к этой рекомендации по контрольному списку Azure Well-Architected Framework для обеспечения операционного совершенства:

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

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

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

Определения

Выравнивание телеметрии с моделями работоспособности и ключевых показателей эффективности

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

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

Возможность ИИ: Команды проводят время вручную, определяя ключевые показатели эффективности и данные телеметрии. Средства с поддержкой искусственного интеллекта могут предлагать часто используемые данные телеметрии на основе архитектуры, зависимостей служб и кода. Такие инструменты, как GitHub Copilot или Claude Code, также могут помочь добавить инструментирование и создать запросы или инфраструктуру в виде шаблонов кода (IaC). Включите человеческий надзор, чтобы гарантировать, что наблюдаемость на основе искусственного интеллекта остается точной и согласованной с стандартами.

Эмиссия телеметрии из рабочих компонентов

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

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

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

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

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

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

Сбор телеметрии по всей рабочей нагрузке

Системы телеметрии используют две основные модели коллекции. В модели извлечения компонент собирает данные телеметрии, запрашивая целевую систему. В push-модели компоненты передают телеметрические данные по мере отправки данных наружу. Выберите модель на основе факторов, которые применяются к рабочей нагрузке. Например, достаточно ли периодических снимков, или вам нужны данные почти в реальном времени? Каков ожидаемый объём телеметрии? Какой это тип данных: основанный на состоянии или журналы, события и трассировки?

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

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

Стандартизация консолидации данных

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

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

Использование служб консолидации данных для:

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

Риск: Имейте в виду, что использование региональных и централизованных хранилищ данных влечёт дополнительные затраты.

Настройка хранилища и хранения для шаблонов использования

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

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

• Базы данных SQL для счетчиков производительности
• Журналы Azure Monitor или Azure Data Explorer для журналов трассировки
• Распределенная файловая система Hadoop (HDFS) для сведений о безопасности

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

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

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

Сопоставление данных для сквозной аналитики

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

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

Агрегирование журналов на уровне приложения и уровня ресурсов для улучшения устранения неполадок и ускорения обнаружения проблем. Рассмотрим унифицированное решение, например Azure Log Analytics, для запроса и анализа данных на разных уровнях.

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

Анализ и визуализация для поддержки практических решений

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

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

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

Для рабочих нагрузок базы данных оцените встроенные панели мониторинга, предоставляемые облачными службами. Например, База данных Azure для PostgreSQL предлагает встроенные панели мониторинга Grafana на портале Azure через интеграцию Azure Monitor. Эти панели мониторинга показывают использование ЦП, хранилище, активные подключения и пропускную способность запросов с корреляцией журналов, что снижает потребность в отдельных развертываниях мониторинга.

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

Определение оповещений для значимых рабочих условий

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

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

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

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

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

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

Проектирование масштабируемых, устойчивых конвейеров телеметрии

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

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

Для сложных рабочих нагрузок используйте очереди сообщений с семантикой по крайней мере один раз . Запустите несколько служб записи в хранилище для обработки больших объемов. Рассмотрите возможность использования Центры событий Azure для распределения обработки телеметрии и предотвращения узких мест ввода-вывода, связанных с единой точкой.

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

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

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

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

Следите за антипаттернами

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

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

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

Обеспечение Azure

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

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

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

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

• Application Insights является расширением Azure Monitor. Данное приложение предоставляет функции APM.

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

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

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

• Azure Network Watcher — это средство мониторинга, управления и аудита сети для обеспечения безопасности, соответствия требованиям и производительности.

• Средство поиска и устранения неисправностей подключения — это диагностический инструмент в Наблюдатель за сетями. Она предоставляет диагностику по запросу и запись пакетов (PCAP) для изучения проблем с подключением.

• Монитор подключения — это средство мониторинга в Наблюдатель за сетями. Он выполняет непрерывные искусственные тесты и отправляет оповещения в режиме реального времени для проблем с подключением и производительностью.

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

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

Дополнительные ссылки

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

Ссылки на ресурсы сообщества

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

Контрольный список операционного превосходства

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