Azure Monitor 中的日志数据引入时间

项目
11/25/2024

Azure Monitor 是一种大规模数据服务，每月为成千上万的客户发送数 TB 的数据，该数据量仍在不断增长。关于日志数据在收集后需要多长时间才可供使用，大家通常存有疑问。本文将对影响此延迟的不同因素进行说明。

平均延迟

延迟是指在监视的系统上创建数据的时间，以及可在 Azure Monitor 中使用该数据进行分析的时间。引入日志数据时的平均延迟时间介于 20 秒到 3 分钟之间。任何特定数据的特定延迟都将根据本文中介绍的多个因素而变化。

影响延迟的因素

特定数据集的总引入时间可细分为下面几个大致方面：

代理时间：发现事件、收集事件，然后将其作为日志记录发送到数据收集终结点的时间。大多数情况下，此过程由代理处理。网络可能会引入更多延迟。
管道时间：引入管道处理日志记录的时间。在该时段，会解析事件属性，而且可能会添加计算的信息。
索引时间：将日志记录引入到 Azure Monitor 大数据存储所花费的时间。

以下部分将详细介绍在此过程中引入的不同延迟。

代理收集延迟

时间不同

代理和管理解决方案使用不同的策略从虚拟机收集数据，这可能会影响延迟。下表列出了一些特定示例。

数据类型	收集频率	备注
Windows 事件、Syslog 事件和性能指标	立即收集
Linux 性能计数器	按 30 秒的时间间隔轮询
IIS 日志和文本日志	在其时间戳更改后收集	对于 IIS 日志，此计划受到 IIS 上配置的滚动更新计划影响。
Active Directory 复制状态	每五天评估一次	只有在评估完成后，代理才会收集这些日志。
Active Directory 评估解决方案	Active Directory 基础结构的每周评估	只有在评估完成后，代理才会收集这些日志。

代理上传频率

小于 1 分钟

为确保 Log Analytics 代理保持轻型，代理会缓冲日志并定期将其上传到 Azure Monitor。上传频率在 30 秒到 2 分钟之间变化，具体取决于数据类型。大多数数据可在 1 分钟内上传。

网络

变化不定

网络状况可能会加剧此数据到达数据收集终结点的延迟。

Azure 指标、资源日志、活动日志

30 秒到 15 分钟

Azure 数据增加了更多时间，以便可用于在数据收集终结点进行处理：

Azure 平台指标不到 1 分钟即可在指标数据库中可用，但导出到数据收集终结点另外还需要 3 分钟时间。
资源日志通常会使延迟增加 30-90 秒，具体取决于 Azure 服务。有些 Azure 服务（具体而言是指 Azure SQL 数据库和 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 时确定记录的不同时间。

步骤	属性或函数	注释
在数据源处创建的记录	TimeGenerated	TimeGenerated 值不能早于接收时间 2 天，也不能晚于当前时间超过一天。否则，Azure Monitor 日志会将 TimeGenerated 值替换为实际接收时间。如果数据源未设置此值，则 Azure Monitor 日志会将该值设置为与 _TimeReceived 相同的时间。
数据收集终结点接收记录	_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

上述两个查询可与除“requests”以外的任何其他 Application Insights 表配对。

停止响应的资源

在某些情况下，资源无法停止发送数据。若要了解资源是否正在发送数据，请查看由标准 TimeGenerated 字段标识的最新记录。

使用 Heartbeat 表来检查 VM 的可用性，因为代理每分钟发送一次检测信号。使用以下查询列出最近尚未报告过检测信号的活动计算机：

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 的服务级别协议。

通过