Параметры диагностики в Azure Monitor

Статья
2025-04-18

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

Для каждого ресурса Azure требуется собственный параметр диагностики, определяющий следующие критерии:

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

Один параметр диагностики может определять не более одного из направлений. Если вы хотите отправить данные в несколько определенных типов назначения (например, две разные рабочие области Log Analytics), создайте несколько параметров. Каждый ресурс может иметь до пяти параметров диагностики.

Предупреждение

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

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

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

Сейчас существует четыре места назначения. Метрики и журналы платформы можно отправлять определенным партнерам Azure Monitor.
В ноябре 2021 года появилась новая функция — группы категорий.

Сведения о новых функциях приведены в этой статье.

Источники

Существует три источника диагностических сведений:

Метрики платформы по умолчанию и без какой-либо настройки автоматически отправляются в Azure Monitor Metrics. Дополнительные сведения о поддерживаемых метриках см. в статье "Поддерживаемые метрики" с помощью Azure Monitor
Журналы платформы предоставляют подробную диагностическую и аудиторскую информацию для ресурсов Azure и платформы Azure, от которых они зависят.
- Журналы ресурсов не собираются, пока они не будут направлены в место назначения. Дополнительные сведения о поддерживаемых журналах см. в разделе "Поддерживаемые категории журналов ресурсов" для Azure Monitor
- Журнал действий содержит сведения о ресурсах извне ресурса, например о том, когда ресурс был создан или удален. Записи существуют отдельно, но их можно перенаправить в другие расположения.

Метрики

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

Журналы ресурсов

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

Группы категорий

Замечание

Группы категорий не применяются ко всем поставщикам ресурсов метрик. Если у поставщика в портале Azure нет доступных параметров диагностики, они также не будут доступны через шаблоны Azure Resource Manager.

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

При использовании групп категорий вы:

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

Сейчас существует две группы категорий:

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

Группа категорий "Аудит" представляет собой подмножество группы категорий "Все", но портал Azure и REST API считают их отдельными параметрами. При выборе группы категорий "Все" собираются все журналы аудита, даже если выбрана группа категорий "Аудит".

На следующем изображении показаны группы категорий журналов на странице 'Добавление параметров диагностики'.

Снимок экрана: группы категорий журналов.

Замечание

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

Журнал действий

См. раздел Параметры журналов действий.

Назначения

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

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

Назначение	Описание
Рабочая область Log Analytics	Метрики преобразуются в логарифмическую форму. Этот параметр может быть недоступен для некоторых типов ресурсов. Отправив их в хранилище журналов Azure Monitor (которое доступно через Log Analytics), вы сможете интегрировать их в запросы, оповещения и визуализации с существующими данными журналов.
учетная запись хранилища Azure	Архивация журналов и метрик в учетную запись хранения полезна для аудита, статического анализа или резервного копирования. По сравнению с использованием журналов Azure Monitor и рабочей области Log Analytics, хранилище Azure является более экономичным решением, а журналы могут храниться там неопределенно долго.
Центры событий Azure	Отправка журналов и метрик в Центры событий позволяет выполнять потоковую передачу данных во внешние системы, такие как сторонние решения SIEM и другие решения Log Analytics.
Партнерские решения по Azure Monitor	Специализированные средства интеграции могут использоваться для интеграции Azure Monitor с платформами мониторинга сторонних производителей. Интеграция полезна, если вы уже работаете с одним из партнеров.

Параметры журналов действий

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

Требования и ограничения

В этом разделе рассматриваются требования и ограничения.

Время до получения телеметрии в пункт назначения

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

Журналы не создаются.
Что-то неправильно в базовом механизме маршрутизации.

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

Метрики в качестве источника

Существуют определенные ограничения на экспорт метрик:

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

Чтобы обойти эти ограничения для конкретных метрик, вы можете вручную извлечь их с помощью REST API метрик. Затем их можно импортировать в журналы Azure Monitor с помощью API сборщика данных Azure Monitor.

Это важно

Параметры диагностики не поддерживают идентификаторы ресурсов с символами, отличными от ASCII (например, Preproduccón). Дополнительные сведения см. в разделе Устранение неполадок.

Ограничения по месту назначения

Перед созданием параметров диагностики необходимо сначала создать все места назначения. Назначение не обязательно должно находиться в той же подписке, что и ресурс, отправляющий журналы, если пользователь, настраивающий параметр, обладает соответствующим ролевым управлением доступом Azure (RBAC) к обеим подпискам. С помощью Azure Lighthouse можно настроить отправку параметров диагностики в рабочую область, учетную запись для хранения данных или концентратор событий в другом клиенте Microsoft Entra.

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

Назначение	Требования
Рабочая область Log Analytics	Рабочая область не обязательно должна находиться в том же регионе, что и отслеживаемый ресурс.
учетная запись хранения	Не используйте существующую учетную запись хранения с другими, несвязанными с мониторингом данными, хранящимися в ней. Разделение типов данных позволяет лучше управлять доступом к данным. Если вы архивируете журнал действий и журналы ресурсов, то можете использовать одну и ту же учетную запись хранения для централизованного хранения всех данных мониторинга. Чтобы предотвратить изменение данных, отправьте его в неизменяемое хранилище. Задайте неизменяемую политику для учетной записи хранения, как описано в разделе "Настройка и управление политиками неизменяемости для объектов BLOB в Azure Storage". Необходимо выполнить все действия, описанные в статье по ссылке выше, в том числе включить защищенные операции записи для добавления BLOB-объектов. Учетная запись хранения должна находиться в том же регионе, что и отслеживаемый ресурс, если ресурс является региональным. Параметры диагностики не могут получить доступ к учетным записям хранения при включении виртуальных сетей. Необходимо включить Разрешить надежным службам Microsoft, чтобы обойти эти настройки брандмауэра в учетных записях хранения, предоставив службе параметров диагностики Azure Monitor доступ к вашей учетной записи хранения. Конечные точки зоны Azure DNS (предварительная версия) и учетные записи хранения Azure Premium LRS (локально избыточное хранилище) не поддерживаются в качестве назначения журнала или метрик.
Центры событий	Политика общего доступа для пространства имен определяет разрешения, предоставленные механизму потоковой передачи. Для потоковой передачи в Центры событий нужны разрешения на управление, отправку и прослушивание. Чтобы обновить параметр диагностики для включения потоковой передачи, необходимо иметь разрешение ListKey для правила авторизации этих Центров событий. Пространство имен концентратора событий должно находиться в том же регионе, что и отслеживаемый ресурс, если ресурс является региональным. Параметры диагностики не могут получить доступ к ресурсам Центров событий, если включены виртуальные сети. Необходимо включить параметр Разрешить доверенным службам Майкрософт обходить этот брандмауэр в центре событий, чтобы служба Azure Monitor (параметры диагностики) получила доступ к ресурсам центров событий.
Решения партнеров	Решения зависят от партнера. Для получения подробной информации см. документацию по службам Azure Native ISV.

Журналы диагностики для Application Insights

Если вы хотите хранить журналы диагностики для Application Insights в рабочей области Log Analytics, не отправляйте журналы в ту же рабочую область, на которую основан ресурс Application Insights. Эта конфигурация может привести к отображению повторяющихся данных телеметрии, так как Application Insights уже хранит эти данные. Отправьте журналы Application Insights в другую рабочую область Log Analytics.

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

Управление затратами

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

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

Подсказка

Стратегии снижения затрат Azure Monitor см. в статье "Оптимизация затрат" и Azure Monitor.

Устранение неполадок

Категория метрики не поддерживается

При развертывании параметра диагностики появляется сообщение об ошибке, подобное этому: Категория метрики "xxxx" не поддерживается. Эта ошибка может возникнуть, даже если предыдущее развертывание выполнено успешно.

Эта проблема возникает при использовании шаблона Resource Manager, REST API, Azure CLI или Azure PowerShell. Параметры диагностики, созданные с помощью портал Azure, не затрагиваются, так как отображаются только поддерживаемые имена категорий.

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

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

Параметр исчезает из-за использования в resourceID символов, не входящих в ASCII

Параметры диагностики не поддерживают идентификаторы ресурсов с символами, отличными от ASCII (например, Preproduccón). Так как вы не можете переименовать ресурсы в Azure, необходимо создать новый ресурс без символов, отличных от ASCII. Если персонажи находятся в группе ресурсов, ресурсы можно переместить в новую группу.

Возможность дублирования или удаления данных

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

Неактивные ресурсы

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

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

Это поведение применяется только к экспортируемым метрикам и не влияет на оповещения на основе метрик или автомасштабирование.