Мониторинг и устранение неполадок сбора данных DCR в Azure Monitor
В этой статье содержатся подробные метрики и журналы, которые можно использовать для мониторинга производительности и устранения неполадок, связанных с сбором данных в 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/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 InputStreamId == "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, чтобы получать оповещения при каждом журнале ошибок. |