Мониторинг сбора данных DCR в Azure Monitor

2025-06-19

В этой статье содержатся подробные метрики и журналы, которые можно использовать для мониторинга производительности и устранения неполадок, связанных с сбором данных в Azure Monitor. Эта телеметрия в настоящее время доступна для сценариев сбора данных, определенных правилами сбора данных (DCR), такими как агент Azure Monitor и API приема журналов.

Это важно

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

Журналы, собранные с помощью агента Azure Monitor (AMA)
Журналы, полученные с использованием API приема журналов
Журналы, собранные другими методами, использующими преобразование рабочей области DCR

См. документацию по другим сценариям для всех доступных сведений о мониторинге и устранении неполадок.

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

Журналы ошибок DCR

Журналы ошибок создаются, если данные достигают конвейера приема Azure Monitor, но не достигают точки назначения. Ниже приведены примеры условий ошибок:

Ошибки доставки логов
Ошибки преобразования , в которых структура журналов делает преобразование KQL недопустимым
Вызовы API загрузки журналов:
- с любым HTTP-ответом, отличным от 200/202
- с полезной нагрузкой, содержащей искаженные данные
- с полезной нагрузкой превышающей любые ограничения приема
- регулирование из-за превышения ограничений вызовов API

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

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

Сбои, вызванные неправильным кодом URI вызова (код ответа HTTP 404)
Некоторые внутренние ошибки сервера (код ответа HTTP 500)

Включение журналов ошибок DCR

Журналы ошибок DCR реализуются как журналы ресурсов в Azure Monitor. Включите сбор журналов, создав диагностическую настройку для DCR. Каждому DCR потребуется собственный параметр диагностики. Дополнительные сведения см. в статье "Создание параметров диагностики" в Azure Monitor . Выберите категорию Ошибки журнала и Отправить в рабочую область Log Analytics. Вы можете выбрать ту же рабочую область, которая используется DCR, или вы можете объединить все журналы ошибок в одной рабочей области.

Получение журналов ошибок DCR

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

Получение всех журналов ошибок для определенного DCR

DCRLogErrors
| where _ResourceId == "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/microsoft.insights/datacollectionrules/my-dcr"

Получение всех журналов ошибок для определенного входного потока в определенном DCR

DCRLogErrors
| where _ResourceId == "/subscriptions/aaaa0a0a-bb1b-cc2c-dd3d-eeeeee4e4e4e/resourceGroups/my-resource-group/providers/microsoft.insights/datacollectionrules/my-dcr"
| where InputStreamId == "Custom-MyTable_CL"

Метрики DCR

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

Единица измерения	Измерения	Описание
Журналы поступления байтов в минуту	Входной поток	Общее число байтов, принятых за минуту.
Запросы на сбор логов за минуту	Входной поток Код HTTP-ответа	Количество звонков, полученных в минуту.
Строки журналов, удаленные в минуту	Входной поток	Количество строк журнала, удаленных во время обработки за минуту. К ним относятся строки, удаленные как из-за условий фильтрации при преобразовании KQL, так и из-за ошибок.
Полученные строки в минуту	Входной поток	Количество строк журнала, полученных для обработки за минуту.
Длительность трансформации логов за минуту	Входной поток	Среднее время выполнения преобразования KQL в минуту. Отражает эффективность кода преобразования KQL. Потоки данных с более длительным временем преобразования могут испытывать задержки при обработке данных.
Ошибки преобразования логов в минуту	Входной поток Тип ошибки	Количество ошибок обработки, возникающих в минуту.

Мониторинг получения логов

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

Сигнал	Возможные причины и действия
Новые записи в `DCRErrorLogs` или внезапное изменение `Log Transform Errors`.	* Проблемы с настройкой API загрузки журналов, такие как проверка подлинности, доступ к DCR или DCE, проблемы с данными нагрузки вызова. — Изменения структуры данных, вызывающие сбои преобразования KQL. — изменения в конфигурации назначения данных, вызывающие сбои доставки данных.
Внезапное изменение `Logs Ingestion Bytes per Min`	* Изменения в конфигурации сбора журналов на клиенте, включая параметры AMA. — изменения структуры отправленных журналов.
Внезапное изменение соотношения между `Logs Ingestion Bytes per Min` и `Logs Rows Received per Min`	* Изменения в структуре отправленных журналов. Проверьте изменения, чтобы убедиться, что данные правильно обработаны с помощью преобразования KQL.
Внезапное изменение `Logs Transformation Duration per Min`	* Изменения структуры журналов, влияющие на эффективность критериев фильтрации в преобразовании KQL. Проверьте изменения, чтобы убедиться, что данные правильно обработаны с помощью преобразования KQL.
`Logs Ingestion Requests per Min` или `Logs Ingestion Bytes per Min` приближается к ограничениям службы API приема журналов.	* Проверьте и оптимизируйте конфигурацию DCR, чтобы избежать ограничения скорости.

Уведомления

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

Состояние	Сведения об оповещении
Внезапные изменения строк были удалены	Правило оповещения о метриках с использованием динамического порога для `Logs Rows Dropped per Min`.
Число вызовов API, приближающихся к ограничениям службы	Правило оповещения о метриках с использованием статического порога для `Logs Ingestion Requests per Min`. Установите порог около 12 000, который является ограничением производительности службы для максимального числа запросов в минуту на DCR.
Журналы ошибок	Уведомление журнального запроса с помощью `DCRLogErrors`. Используйте меру строки таблицы и пороговое значение 1, чтобы получать оповещения при регистрации любых ошибок.

Поделиться через