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

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

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

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

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

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

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

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

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

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

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

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

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

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

Network

Меняется

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

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

От 30 секунд до 15 минут

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

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

Сбор данных решениями по управлению

Меняется

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

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

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

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

30–60 секунд

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

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

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

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

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

Подготовка новых типов пользовательских данных

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

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

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

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

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

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

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

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

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

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

Задержки приема данных

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