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

Статья
12/19/2024

В этой статье содержатся подробные метрики и журналы, которые можно использовать для мониторинга производительности и устранения неполадок, связанных с сбором данных в 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, чтобы избежать регулирования.

видны узлы

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

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

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