通过

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

Azure Monitor 是一种大规模数据服务，每月发送数 TB 的数据并继续增长。 在正常服务作下，收集后日志数据可用所需的时间是可预测且一致的。 本文介绍影响此延迟的因素。

平均延迟

延迟是指在受监视系统上创建数据的时间，以及当数据在 Azure Monitor 中可用于分析的时间。 引入日志数据的平均延迟 小于 10 秒。 任何特定数据的特定延迟因本文中所述的几个因素而异。

影响延迟的因素

特定数据集的总引入时间是从客户端到 Azure Monitor 服务的累积时间。

体系结构图，显示 Azure Monitor 引入过程。

  • 客户端时间：发现事件、收集事件的时间，然后将其作为日志记录发送到 数据收集终结点 。 在大多数情况下，Azure Monitor 代理（AMA）等代理将处理此过程。 使用日志引入 API 的自定义应用程序不是本文计算的一部分，但它们可能有与 AMA 客户端时间类似的自己的延迟特征。
  • Azure Monitor 时间：客户端将任务移交给 Azure Monitor 后，处理日志记录的引入时间。 该时间段包括解析事件属性，并且可能添加计算所得的信息。

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

代理收集延迟

延迟：时间变化

代理使用不同的策略收集数据，这可能会影响延迟。 下表列出了一些特定示例。

数据类型 收集频率 备注
Windows 事件、Syslog 事件和性能指标 立即收集
Linux 性能计数器 按 30 秒的时间间隔轮询
IIS 日志和文本日志 在其时间戳更改后收集 对于 IIS 日志，此计划受到 IIS 上配置的滚动更新计划影响。

有关代理性能的详细信息，请参阅 Azure Monitor 代理性能。

代理上传频率

延迟：不到 1 分钟

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

网络

延迟：变化

客户端与 Azure Monitor 数据收集终结点之间的网络可能会增加意外延迟。 当您测量引入延迟时，此网络延迟作为 AgentLatency 计算的一部分包含在 度量引入延迟 部分的示例查询中。

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

延迟：30 秒到 20 分钟

Azure 数据在到达数据收集终结点可用于处理时需要更多时间。

  • Azure平台指标在指标数据库中的一分钟内可用，但它们需要三分钟才能导出到数据收集终结点。
  • 资源日志 通常在 3 到 10 分钟内端到端可用，具体取决于服务和所涉及的 Azure 服务的复杂性。 例如，Azure SQL Database和Azure Virtual Network当前每五分钟提供一次日志。 要在你的环境中检查此延迟，请查看下面的查询。
  • 活动日志可在 3 到 20 分钟内用于分析和警报。

Azure监视器处理时间

延迟：小于 10 秒

数据到达数据收集终结点后，需要不到 10 秒才能对其进行查询。

当 Azure Monitor 引入日志记录时（如 _TimeReceived 属性所示），它会将其写入临时存储。 此步骤可确保租户隔离并防止数据丢失。 此步骤通常添加 5 到 15 秒。

某些解决方案使用更复杂的算法在数据流传入时聚合数据和派生见解。 例如，Application Insights 计算应用程序映射数据。 Azure网络性能监视会聚合三分钟间隔内传入的数据，这实际上增加了三分钟的延迟。

如果数据收集包含 引入时间转换，此转换会将一些延迟添加到 Azure Monitor 进程时间。 使用指标每分钟的日志转换时长来监视转换查询的效率。

处理自定义日志是另一个增加延迟的过程。 在某些情况下，此过程可能会向代理从文件收集的日志添加几分钟的延迟。

新的自定义数据类型预配

从自定义日志或日志引入 API创建新类型的自定义数据时，系统会创建一个专用的存储容器。 这种一次性开销仅在此数据类型首次出现时发生。

检查摄取时间

在不同情况下，不同资源的引入时间可能会有所不同。 使用日志查询识别环境的特定行为。 下表指定在创建记录并将其发送到Azure监视器时如何确定记录的不同时间。 有关日志查询的详细信息，请参阅 Log Analytics 概述。

步骤 属性或函数 注释
在数据源处创建的记录 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 日志的指标的延迟条件：

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

  • Last updated on