Время приема журнальных данных в Мониторе Azure

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

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

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

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

Общее время приема для определенного набора данных — это совокупное время от клиента к службе мониторинга Azure.

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

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

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

Задержка: время варьируется

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

Дополнительные сведения о производительности агента см. в разделе Azure Мониторинг производительности агента.

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

Задержка: до 1 минуты

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

Сеть

Задержка: зависит

Сетевая инфраструктура между клиентом и конечной точкой сбора данных Azure Monitor может вносить непредвиденные задержки. При измерении задержки приема эта задержка сети включается как часть AgentLatency вычисления в примерах запросов в разделе измерении задержки приема.

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

Задержка: 30 секунд до 20 минут

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

• Метрики платформы Azure доступны менее чем через минуту в базе данных метрик, однако их экспорт в точку сбора данных занимает еще три минуты.
• Resource журналы обычно доступны в течение 3–10 минут в полном объёме, в зависимости от сложности сервиса и задействованных служб Azure. Например, База данных SQL Azure и Azure Virtual Network в настоящее время предоставляют свои журналы каждые пять минут. Чтобы изучить эту задержку в вашей среде, ознакомьтесь с приведенным ниже запросом.
• Журналы действий доступны для анализа и оповещения в течение 3–20 минут.

Azure мониторинг времени процесса

Задержка: менее 10 секунд

После того как данные достигают конечной точки сбора данных, она занимает менее 10 секунд, прежде чем вы сможете запросить ее.

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

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

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

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

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

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

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

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

Задержка загрузки данных

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

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

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:

// Workspace-based Application Insights schema
// This query can be paired with any other Application Insights table other than "requests"
let start=datetime("2026-01-21 05:00:00");
let end=datetime("2026-01-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

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

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