Время приема данных журнала в Azure Monitor
Azure Monitor — это высокомасштабируемая служба, которая обслуживает тысячи клиентов, ежемесячно отправляющих стремительными темпами терабайты данных. Часто возникают вопросы о времени, в течение которого собранные данные журнала становятся доступными. В этой статье объясняются факторы, влияющие на эту задержку.
Обычная задержка
Задержка — это время, в течение которого данные создаются в отслеживаемой системе, и время, в течение которого они становятся доступными для анализа в Azure Monitor. Обычная задержка для приема данных журнала составляет от 20 секунд до 3 минут. Тем не менее конкретная задержка для определенных данных зависит от различных факторов, описанных ниже.
Факторы, влияющие на задержку
Общее время приема для конкретного набора данных можно разделить на следующие высокоуровневые составляющие.
- Время агента — время на обнаружение события, его сбора и отправки в точку приема журналов Azure Monitor в виде записи журнала. В большинстве случаев этот процесс обрабатывается агентом. В сети может быть возникнуть дополнительная задержка.
- Время конвейера — время, необходимое конвейеру приема для обработки записи журнала. Сюда входит анализ свойств события и возможное добавление вычисляемых данных.
- Время индексирования — время, затраченное на прием записи журнала в хранилище больших данных Azure Monitor.
Далее приводятся сведения о различных видах задержки, представленных в этом процессе.
Задержка агента сбора данных
Время может изменяться
Агенты и решения по управлению используют разные стратегии для сбора данных с виртуальной машины, что может повлиять на задержку. Вот несколько конкретных примеров.
| Тип данных | Частота сбора | Примечания |
|---|---|---|
| Сбор событий Windows, событий системного журнала и метрик производительности | выполняется немедленно. | |
| Счетчики производительности Linux | опрашиваются с 30-секундным интервалом. | |
| Журналы IIS и текстовые журналы | происходит при изменении метки времени. | Сбор данных журналов служб IIS зависит от расписания переключения, настроенного в службах IIS. |
| Решение для репликации Active Directory | Оценка каждые пять дней | Агент собирает данные этих журналов только после завершения оценки. |
| Решение для оценки Active Directory | Еженедельная оценка инфраструктуры Active Directory | Агент собирает данные этих журналов только после завершения оценки. |
Частота отправки данных агентом
Менее 1 минуты
Подтверждая простоту своего функционала, агент Log Analytics помещает журналы в буфер и периодически отправляет их в Azure Monitor. В зависимости от типа данных частота отправки меняется от 30 секунд до 2 минут. Большая часть данных отправляется меньше чем через минуту.
Сеть
Различается
Состояние сети может отрицательно повлиять на задержку при достижении этими данными точки приема журналов Azure Monitor.
Метрики Azure, журналы ресурсов, журнал действий
От 30 секунд до 15 минут
Отправка данных Azure для обработки в точку приема журналов Azure Monitor занимает дополнительное время:
- Метрики платформы Azure появляются в базе данных метрик в течение минуты, но для их экспорта на точку приема журналов Azure Monitor необходимо еще 3 минуты.
- Журналы ресурсов обычно добавляют к этому сроку 30–90 секунд, в зависимости от службы Azure. Некоторые службы Azure (в частности, База данных SQL Azure и виртуальная сеть Azure) в настоящее время передают журналы каждые 5 минут. Сейчас прилагаются усилия для их улучшения. Ознакомьтесь с запросом ниже, чтобы изучить задержку в своей среде.
- Данные журнала действий принимаются в течение 30 секунд при использовании рекомендуемых параметров диагностики уровня подписки для отправки их в журналы Azure Monitor. В то же время при использовании устаревшей интеграции на этом может потребоваться 10–15 минут.
Сбор данных решениями по управлению
Различается
Некоторые решения не собирают свои данные с агента и могут использовать метод сбора, приводящий к дополнительной задержке. Некоторые решения собирают данные через регулярные интервалы, не предпринимая попыток сбора данных в режиме, близком к реальному времени. Вот несколько конкретных примеров.
- Решение Microsoft 365 опрашивает журналы действий с помощью API действий управления Microsoft 365, который в настоящее время не дает гарантий задержки в режиме, близком к реальному времени.
- Решение Windows Analytics (например, для поддержки обновлений) собирает данные ежедневно.
Частоту сбора данных см. в документации к соответствующему решению.
Время обработки конвейером
30–60 секунд
Когда данные станут доступны в точке приема, потребуется от 30 до 60 секунд дополнительно, чтобы они стали доступны для запросов.
После добавления в конвейер Azure Monitor (согласно свойству _TimeReceived) записи журнала заносятся во временное хранилище, что позволяет обеспечить изоляцию арендатора и сохранность данных. Как правило, этот процесс добавляет еще около 5–15 секунд задержки. В некоторых решениях по управлению реализованы более сложные алгоритмы по объединению данных и получению аналитических сведений по мере потокового поступления данных. Например, решение по мониторингу производительности сети собирает входящие данные через 3-минутные интервалы, добавляя тем самым 3-минутную задержку. Другой процесс, который приводит к увеличению задержки — это процесс, который обрабатывает пользовательские журналы. В некоторых случаях этот процесс может добавить задержку в несколько минут для журналов, собранных из файлов с помощью агента.
Подготовка новых типов пользовательских данных
При создании нового типа пользовательских данных из настраиваемого журнала или API сборщика данных система формирует выделенный контейнер хранилища. Это однократное увеличение нагрузки, которое возникает только при первом входе этого типа данных.
Защита от пиковых нагрузок
Обычно до 1 минуты, но этот срок может быть больше
Наивысшим приоритетом Azure Monitor является сохранность данных клиента, поэтому система оснащена встроенной защитой от резкого увеличения объемов данных. Сюда входят буферы, гарантирующие, что даже при огромный нагрузке система продолжит работать. При обычной нагрузке эти средства управления добавляют задержку меньше минуты, но в экстремальных условиях и при критических сбоях они могут добавлять значительное время, обеспечивая при этом безопасность данных.
Время индексации
5 минут или меньше
На каждой платформе больших данных существует встроенный баланс между предоставлением возможностей анализа и расширенных функций поиска и немедленным предоставлением доступа к данным. Azure Monitor позволяет выполнять мощные запросы к миллионам записей и получать результаты через несколько секунд. Это стало возможным благодаря существенному преобразованию данных во время их приема и их хранению в уникальных компактных структурах. Система помещает данные в буфер до тех пор, пока их не будет достаточно для создания этих структур. Это должно быть сделано до появления записей журнала в результатах поиска.
Сейчас этот процесс занимает около 5 минут при небольшом объеме данных. При более высокой скорости передачи данных задача выполняется быстрее. Это кажется нелогичным, но данный процесс позволяет оптимизировать задержку для производственных рабочих нагрузок большого объема.
Проверка времени приема
В различных условиях время приема может меняться для разных ресурсов. Запросы журналов можно использовать для идентификации конкретного поведения среды. В следующей таблице показано, как можно определить для записи время, когда она была создана и отправлена в Azure Monitor.
| Шаг | Свойство или функция | Комментарии |
|---|---|---|
| Запись создана в источнике данных | TimeGenerated Если источник данных не задает это значение, будет установлено то же время, что и в _TimeReceived. |
Если во время обработки время создания будет раньше, чем три дня назад, строка будет удалена. |
| Запись получена конечной точкой приема 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
Ресурсы, которые перестали отвечать на запросы
В некоторых случаях ресурс может остановить отправку данных. Чтобы понять, отправляет ли ресурс данные или нет, просмотрите его самую последнюю запись, которую можно определить стандартным полем TimeGenerated.
В таблице по пакету пульса вы можете проверить доступность виртуальной машины, так как агент отправляет пакет пульса каждую минуту. Используйте следующий запрос, чтобы получить список активных компьютеров, которые в ближайшее время не передавали отчет пакета пульса.
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
Дальнейшие действия
- Ознакомьтесь со страницей Соглашение об уровне обслуживания для Log Analytics.