Рекомендации по проектированию и созданию системы мониторинга

Статья
11/15/2023

Применяется к этой рекомендации по контрольным спискам операционной эффективности Azure Well-Architected Framework:

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

Связанное руководство. Рекомендации по инструментированию приложения

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

Определения

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

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

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

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

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

Этот конвейер рабочего процесса иллюстрирует систему мониторинга:

Коллекция

Примечание

Чтобы включить ведение журнала, необходимо инструментировать приложение. Дополнительные сведения см. в руководстве по инструментированию.

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

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

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

Данные приложения

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

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

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

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

Данные должны быть не зависят от компьютера, операционной системы или сетевого протокола. Например, вы можете выдавать информацию в самоописающем формате, например JSON, MessagePack или Protobuf, а не ETL/ETW. Стандартный формат позволяет системе создавать конвейеры обработки. Компоненты, которые считывают, преобразуют и отправляют данные в стандартном формате, можно легко интегрировать.

Данные инфраструктуры

Для ресурсов инфраструктуры в рабочей нагрузке убедитесь, что вы собираете журналы и метрики. Для систем IaaS (инфраструктура как услуга) в дополнение к метрикам, связанным с работоспособностью рабочих нагрузок, необходимо записать операционные системы, уровни приложений и журналы диагностики. Для ресурсов платформы как услуги (PaaS) вы можете быть ограничены в возможности записи журналов, связанных с базовой инфраструктурой, но убедитесь, что вы можете записывать журналы диагностики в дополнение к метрикам, связанным со работоспособностью рабочей нагрузки.

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

Стратегии сбора

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

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

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

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

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

Агенты мониторинга

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

Примечание

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

Рекомендации по производительности

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

Одним из способов буферизации данных инструментирования является использование очередей:

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

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

Стратегии консолидации

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

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

Память

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

Примечание

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

Технологии хранения

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

Например, доступ к Хранилище BLOB-объектов Azure и хранилищу таблиц Azure выполняется аналогичным образом. Но операции, которые можно выполнять с ними, различаются, как и степень детализации данных, которые они содержат. Если необходимо выполнять больше аналитических операций или требуются возможности полнотекстового поиска по данным, может быть удобнее использовать то хранилище, возможности которого оптимизированы под определенные типы запросов и доступа к данным. Пример:

Данные счетчика производительности можно сохранять в базу данных SQL для проведения расширенного анализа.
Возможно, лучше хранить журналы трассировки в журналах Azure Monitor или Data Explorer Azure.
Вы можете хранить сведения о безопасности в решении HDFS.

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

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

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

Служба консолидации

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

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

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

Анализ

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

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

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

Например, трехуровневое приложение может иметь:

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

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

Визуализация

Панели мониторинга

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

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

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

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

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

Примечание

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

Отчеты

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

Операционные отчеты обычно включают следующее:

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

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

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

Во многих случаях отчеты могут создаваться процессами пакетной обработки согласно заданному расписанию Задержка обычно не является проблемой. У вас также должны быть пакетные процессы, которые могут создавать отчеты на спонтанной основе по мере необходимости. Например, при хранении данных в реляционной базе данных, такой как Azure SQL Database, можно использовать средство SQL Server Reporting Services для извлечения и форматирования данных и представления их в виде набора отчетов.

видны узлы

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

Пороговые значения

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

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

Упрощение azure

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

Если вы используете несколько рабочих областей, ознакомьтесь с рекомендациями в руководстве по архитектуре рабочих областей Log Analytics.
Application Insights — это расширение Azure Monitor. Он предоставляет функции APM.
Аналитика Azure Monitor — это расширенные средства аналитики для конкретных технологий Azure (например, виртуальных машин, служб приложений и контейнеров). Эти средства являются частью Azure Monitor и Log Analytics.
Azure Monitor для решений SAP — это средство мониторинга Azure для ландшафтов SAP, работающих в Azure.
Политика Azure могут помочь вам обеспечить соблюдение стандартов организации и оценить соответствие требованиям в большом масштабе.

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

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

Контрольный список эффективности операций

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

Контрольный список эффективности операций

Рекомендации по проектированию и созданию системы мониторинга