Время приема данных журнала в Azure Monitor

2024-11-21

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

Средняя задержка

Задержка относится к времени создания данных в отслеживаемой системе и времени, которое оно становится доступным для анализа в Azure Monitor. Средняя задержка приема данных журнала составляет от 20 секунд до 3 минут. Определенная задержка для любых конкретных данных зависит от нескольких факторов, описанных в этой статье.

Факторы, влияющие на задержку

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

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

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

Задержка сбора данных агентом

Время может изменяться

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

Тип данных	Частота сбора	Примечания.
События Windows, события системного журнала и метрики производительности	Собрано немедленно
Счетчики производительности Linux	Проводится опрос каждые 30 секунд
Журналы IIS и текстовые журналы	Собранные после того, как изменились метки времени	Для журналов IIS это расписание зависит от расписания повтора, настроенного в настройках IIS.
Решение для репликации Active Directory	Оценка каждые пять дней	Агент собирает журналы только после завершения оценки.
Решение для оценки Active Directory	Еженедельная оценка инфраструктуры Active Directory	Агент собирает журналы только после завершения оценки.

Частота отправки данных агентом

Менее 1 минуты

Подтверждая простоту своего функционала, агент Log Analytics помещает журналы в буфер и периодически отправляет их в Azure Monitor. В зависимости от типа данных частота отправки меняется от 30 секунд до 2 минут. Большая часть данных отправляется меньше чем через минуту.

Сеть

Меняется

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

Метрики Azure, журналы ресурсов, журнал действий

30 секунд до 20 минут

Данные Azure добавляют больше времени для получения доступа к конечной точке сбора данных для обработки:

Метрики платформы Azure доступны в течение минуты в базе данных метрик , но они занимают еще 3 минуты для экспорта в конечную точку сбора данных.
Журналы ресурсов обычно добавляют от 30 до 90 секунд времени в зависимости от службы Azure. Некоторые службы Azure (в частности, База данных SQL Azure и Azure виртуальная сеть) в настоящее время сообщают о своих журналах через 5 минут. Продолжаются работы по дальнейшему улучшению этого показателя. Чтобы изучить эту задержку в вашей среде, ознакомьтесь с приведенным ниже запросом.
Журналы действий доступны для анализа и оповещения в течение 3–20 минут.

Коллекция решений по управлению

Меняется

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

Решение Microsoft 365 опрашивает журналы активности с помощью Management Activity API, который в настоящее время не гарантирует минимальную задержку в режиме, близком к реальному времени.
Данные решений Windows Analytics (например, Update Compliance) собираются ежедневно.

Сведения о частоте сбора решений см. в документации по каждому решению.

Время конвейерной обработки

30–60 секунд

После того как данные будут доступны в конечной точке сбора данных, для запроса потребуется еще 30–60 секунд.

После приема записей журнала в конвейер Azure Monitor (как указано в свойстве _TimeReceived ), они записываются во временное хранилище, чтобы обеспечить изоляцию клиента и убедиться, что данные не потеряны. Обычно этот процесс добавляет от 5 до 15 секунд.

Некоторые решения реализуют более сложные алгоритмы для агрегирования данных и извлечения инсайтов по мере поступления потоковой информации. Например, Application Insights вычисляет данные карты приложений; Мониторинг производительности сети Azure агрегирует входящие данные с 3-минутными интервалами, что фактически добавляет 3-минутную задержку.

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

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

Настройка новых типов пользовательских данных

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

Защита от пиковых нагрузок

Как правило, менее 1 минуты, но может быть больше

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

Время индексации

5 минут или меньше

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

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

Проверка времени приема

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

Этап	Свойство или функция	Комментарии
Запись создана в источнике данных	TimeGenerated	Значение TimeGenerated не может быть более чем за два дня до времени получения или более чем на день в будущем. В противном случае журналы Azure Monitor заменяют значение TimeGenerated фактическим полученным временем. Если источник данных не задает это значение, журналы Azure Monitor задают значение в то же время, что и _TimeReceived.
Запись, полученная конечной точкой сбора данных	_ВремяПолучения	Это поле не оптимизировано для массовой обработки и не должно использоваться для фильтрации больших наборов данных.
Запись сохранена в рабочей области и доступна для запросов	ingestion_time()	Рекомендуется использовать `ingestion_time()`, если требуется отфильтровать только записи, которые были получены в определенное время. В таких случаях мы рекомендуем добавить также фильтр `TimeGenerated` с более широким диапазоном.

Задержки латентности интеграции данных

Вы можете измерить задержку определенной записи, сравнивая результат функции ingestion_time() со свойством TimeGenerated . Эти данные можно использовать с различными агрегациями, чтобы узнать, как ведет себя задержка при приеме данных. Изучите некоторый процентиль времени приема, чтобы получить аналитические сведения о больших объемах данных.

Например, в следующем запросе вы увидите, у каких компьютеров было наибольшее время обработки данных за последние 8 часов.

Heartbeat
| where TimeGenerated > ago(8h)
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated
| extend AgentLatency = _TimeReceived - TimeGenerated
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) by Computer
| top 20 by percentile_E2EIngestionLatency_95 desc

Предыдущие анализы процентилей хорошо подходят для поиска основных закономерностей задержки. Чтобы указать краткосрочный всплеск задержки, использование максимального значения (max()) может быть более эффективным.

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

Heartbeat
| where TimeGenerated > ago(24h) //and Computer == "ContosoWeb2-Linux"
| extend E2EIngestionLatencyMin = todouble(datetime_diff("Second",ingestion_time(),TimeGenerated))/60
| extend AgentLatencyMin = todouble(datetime_diff("Second",_TimeReceived,TimeGenerated))/60
| summarize percentiles(E2EIngestionLatencyMin,50,95), percentiles(AgentLatencyMin,50,95) by bin(TimeGenerated,30m)
| render timechart

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

Heartbeat
| where TimeGenerated > ago(8h)
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated
| extend AgentLatency = _TimeReceived - TimeGenerated
| summarize percentiles(E2EIngestionLatency,50,95),percentiles(AgentLatency,50,95) by RemoteIPCountry

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

AzureDiagnostics
| where TimeGenerated > ago(8h)
| extend E2EIngestionLatency = ingestion_time() - TimeGenerated
| extend AgentLatency = _TimeReceived - TimeGenerated
| summarize percentiles(E2EIngestionLatency,50,95), percentiles(AgentLatency,50,95) by ResourceProvider

Используйте ту же логику запроса для диагностики условий задержки для данных Application Insights:

// Classic Application Insights schema
let start=datetime("2023-08-21 05:00:00");
let end=datetime("2023-08-23 05:00:00");
requests
| where timestamp > start and timestamp < end
| extend TimeEventOccurred = timestamp
| extend TimeRequiredtoGettoAzure = _TimeReceived - timestamp
| extend TimeRequiredtoIngest = ingestion_time() - _TimeReceived
| extend EndtoEndTime = ingestion_time() - timestamp
| project timestamp, TimeEventOccurred, _TimeReceived, TimeRequiredtoGettoAzure , ingestion_time(), TimeRequiredtoIngest, EndtoEndTime
| sort by EndtoEndTime desc

// Workspace-based Application Insights schema
let start=datetime("2023-08-21 05:00:00");
let end=datetime("2023-08-23 05:00:00");
AppRequests
| where TimeGenerated > start and TimeGenerated < end
| extend TimeEventOccurred = TimeGenerated
| extend TimeRequiredtoGettoAzure = _TimeReceived - TimeGenerated
| extend TimeRequiredtoIngest = ingestion_time() - _TimeReceived
| extend EndtoEndTime = ingestion_time() - TimeGenerated
| project TimeGenerated, TimeEventOccurred, _TimeReceived, TimeRequiredtoGettoAzure , ingestion_time(), TimeRequiredtoIngest, EndtoEndTime
| sort by EndtoEndTime desc

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

Ресурсы, которые перестали отвечать на запросы

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

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

Heartbeat
| where TimeGenerated > ago(1d) //show only VMs that were active in the last day 
| summarize NoHeartbeatPeriod = now() - max(TimeGenerated) by Computer
| top 20 by NoHeartbeatPeriod desc

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

Ознакомьтесь с соглашением об уровне обслуживания для Azure Monitor.