Рекомендации Azure Monitor: настройка сбора данных

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

Проектирование архитектуры рабочей области Log Analytics

Для включения журналов Azure Monitor требуется не менее одной рабочей области Log Analytics, необходимой для:

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

Другие службы, такие как Microsoft Sentinel и Microsoft Defender для облака, также используют рабочую область Log Analytics. Они могут использовать тот же ресурс, который используется для Azure Monitor.

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

Инструкции по созданию рабочей области Log Analytics см. в статье Создание рабочей области Log Analytics на портале Azure, а сведения о настройке доступа — в статье Управление доступом к рабочим областям Log Analytics. Вы можете использовать для настройки рабочих областей масштабируемые методы, такие как шаблоны Resource Manager, однако в этом часто нет необходимости, так как требуемое количество в большинстве сред минимально.

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

Сбор данных из ресурсов Azure

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

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

Соберите журналы арендаторов и подписок

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

Нет затрат на отправку журнала действий в рабочую область, но есть плата за прием данных и хранение журналов Microsoft Entra.

См. статью "Интеграция журналов Microsoft Entra с журналами Azure Monitor" и "Создание параметров диагностики для отправки журналов и метрик платформы в разные места назначения", чтобы создать параметры диагностики для клиента и подписки, которые позволят отправлять записи журналов в рабочую область Log Analytics.

Получение журналов ресурсов и метрик платформы

Ресурсы в Azure автоматически создают журналы ресурсов, содержащие сведения об операциях, выполняемых в ресурсе. В отличие от метрик платформы, необходимо настроить сбор журналов ресурсов. Создайте параметр диагностики для их отправки в рабочую область Log Analytics, чтобы объединить их с другими данными, используемыми для журналов Azure Monitor. Этот же параметр диагностики можно использовать для отправки метрик платформы для большинства ресурсов в ту же рабочую область. Таким образом, данные метрик можно анализировать с помощью запросов к журналу с другими собранными данными.

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

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

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

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

Включить аналитические сведения

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

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

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

Мониторинг виртуальных машин

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

Мониторинг контейнеров

Контейнеры создают аналогичные данные, как и другие ресурсы Azure, но им требуется контейнерная версия агента Log Analytics для сбора необходимых данных. Аналитика контейнеров помогает подготовить контейнерную среду для мониторинга. Он работает совместно со сторонними инструментами для обеспечения комплексного мониторинга Службы Azure Kubernetes (AKS) и поддерживаемых рабочих процессов. Для получения информации о выделенном сценарии мониторинга AKS с помощью Azure Monitor обратитесь к статье "Мониторинг Azure Kubernetes Service с помощью Azure Monitor".

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

Azure Monitor отслеживает пользовательские приложения с помощью службы Application Insights, которую необходимо настроить для каждого приложения, что требуется отслеживать. Процесс настройки зависит от типа отслеживаемого приложения и необходимого типа мониторинга. Данные, собранные Application Insights, хранятся в метриках Azure Monitor, журналах Azure Monitor или Azure Blob-хранилище в зависимости от возможностей. Данные производительности сохраняются в метриках и журналах Azure Monitor без дополнительной настройки.

Создание ресурса приложения

Application Insights — это функция Azure Monitor для мониторинга собственных и гибридных приложений в облаке.

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

При создании ресурса приложения необходимо выбрать, следует ли использовать классическую модель или модель на основе рабочей области. Создание классического приложения описано в разделе Создание ресурса Application Insights. Сведения о создании приложения на основе рабочей области см . в ресурсах Application Insights на основе рабочей области. Данные журнала, собранные Application Insights, сохраняются в журналах Azure Monitor для приложения, использующего рабочее пространство. Данные журнала для классических приложений хранятся отдельно от рабочей области Log Analytics.

Настройка безкодового или кодового отслеживания

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

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

• Приложения, размещенные в веб-приложениях Azure
• Приложения Java
• Приложения ASP.NET, размещенные в IIS на Виртуальных машинах Azure или в Масштабируемом наборе виртуальных машин Microsoft Azure
• Приложения ASP.NET, размещенные в IIS локально

Мониторинг с написанием кода обеспечивает больше возможностей настройки и собирает дополнительные данные телеметрии, но требует добавления в код зависимости от пакетов NuGet для пакетов SDK для Application Insights. Сведения о том, как включить мониторинг на основе приложения, см. в следующих статьях:

• Приложения ASP.NET
• приложения ASP.NET Core
• Консольные приложения .NET
• Java
• Node.js
• Питон
• Другие платформы

Настройка теста доступности

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

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

Настройка Профилировщика Application Insights для .NET

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

См. раздел Профилирование рабочих приложений в Azure с помощью Application Insights для получения информации о настройке профилировщика .NET.

Настройка Snapshot Debugger

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

Дополнительные сведения о настройке Snapshot Debugger см. в статье Отладочные моментальные снимки для исключений в приложениях .NET.

Дальнейшие действия

Если сбор данных настроен для всех ресурсов Azure, возможности анализа соответствующих данных см. в статье Анализ и визуализация данных.