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

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

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

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

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

Определения

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Риск. Помните, что существуют затраты на региональные и централизованные хранилища данных.

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

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

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

• Базы данных SQL для счетчиков производительности.
• Azure Monitor журналы или Azure Data Explorer для трассировочных журналов.
• HDFS для сведений о безопасности.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• 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 Policy поможет обеспечить соблюдение стандартов организации и оценить соответствие требованиям в масштабе.

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

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

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

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

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

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

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

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

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

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