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

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

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

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

Определения

Основные стратегии проектирования

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

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

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

• Храните собранные данные в стандартизированном, надежном и безопасном решении для хранения.

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

• Анализ обработанных данных для точного определения состояния рабочей нагрузки.

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

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

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

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

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

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

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

Сбор данных инструментирования

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

• Модель отправки: пассивно ожидает отправки данных из компонентов, составляющих каждый экземпляр приложения.

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

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

Вопросы производительности

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

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

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

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

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

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

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

Хранение данных для запроса и анализа

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

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

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

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

• Данные счетчика производительности можно сохранять в базу данных SQL для проведения расширенного анализа.

• Возможно, лучше хранить журналы трассировки в журналах Azure Monitor или Azure Data Explorer.

• Вы можете хранить сведения о безопасности в решении HDFS.

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

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

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

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

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

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

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

Рекомендации по запросам

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

Рекомендации по хранению данных

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

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

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

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

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

Анализ данных для понимания работоспособности рабочей нагрузки

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

• Структура данных на основе ключевых показателей эффективности и метрик производительности, определенных вами.

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

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

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

• Уровень презентации, позволяющий пользователю подключаться к веб-сайту.

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

• Уровень базы данных, в который хранятся данные, связанные с операцией.

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

Рекомендации

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

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

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

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

Визуализация отчетов о работоспособности рабочей нагрузки

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

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

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

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

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

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

Отчетность

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

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

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

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

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

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

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

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

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

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

Определение оповещений для ключевых событий

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

Рекомендации

• Определите процесс для реагирования на оповещение, который указывает владельцев и действия.

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

• Используйте решение автоматического оповещения, например Splunk или Azure Monitor, вместо того, чтобы пользователи активно искали проблемы.

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

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

Пороги

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

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

Упрощение функций 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.

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

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