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

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

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

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

• сбора данных, таких как журналы из ресурсов Azure;
• сбора данных из гостевой ОС Виртуальных машин Microsoft 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 Monitor отслеживает пользовательские приложения с помощью службы Application Insights, которую необходимо настроить для каждого приложения, что требуется отслеживать. Процесс настройки зависит от типа отслеживаемого приложения и необходимого типа мониторинга. Данные, собранные Application Insights, сохраняются в метриках Azure Monitor, журналах Azure Monitor или Хранилище BLOB-объектов Azure в зависимости от настроенной возможности. Данные производительности сохраняются в метриках и журналах 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
• Python
• другие платформы.

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

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

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

Настройка профилировщика

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

Дополнительные сведения о настройке Profiler см. в статье Профилирование приложений в рабочей среде Azure с помощью Application Insights Profiler.

Настройка Snapshot Debugger

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

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

Следующие шаги

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