Мониторинг и устранение неполадок сбора данных DCR в Azure Monitor

  • Статья

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

Внимание

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

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

Функции диагностики 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/00000000-0000-0000-0000-000000000000/resourceGroups/my-resource-group/providers/microsoft.insights/datacollectionrules/my-dcr"

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

DCRLogErrors
| where _ResourceId == "/subscriptions/00000000-0000-0000-0000-000000000000/resourceGroups/my-resource-group/providers/microsoft.insights/datacollectionrules/my-dcr"
| where InputStream == "Custom-MyTable_CL"

Метрики DCR

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

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

Устранение распространенных проблем

Если в рабочей области Log Analytics отсутствуют ожидаемые данные, выполните следующие основные действия, чтобы устранить проблему. Предполагается, что вы включили ведение журнала DCR, как описано выше.

  • Проверьте такие метрики, как Logs Ingestion Bytes per Min и Logs Rows Received per Min убедитесь, что данные достигают Azure Monitor. В противном случае проверка источник данных, чтобы убедиться, что он отправляет данные должным образом.
  • Проверьте Logs Rows Dropped per Min , удаляются ли строки. Это может не указывать на ошибку, так как строки могут быть удалены преобразованием. Если удаленные строки Logs Rows Dropped per Min совпадают с тем, что данные не будут приема в рабочей области. Проверьте наличие Logs Transformation Errors per Min ошибок преобразования.
  • Проверьте Logs Transformation Errors per Min наличие ошибок при преобразовании, примененных к входящим данным. Это может быть связано с изменениями структуры данных или самого преобразования.
  • Проверьте DCRLogErrors наличие ошибок приема, которые могли быть зарегистрированы. Это может предоставить дополнительные сведения о том, как определить первопричину проблемы.

Мониторинг приема журналов

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

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

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