无法通过Logs复现Azure Metrics Chart请求数据问题排查

我正在Azure中为服务创建仪表盘，已经给每个服务添加了Azure Metrics Chart，后续想在下方补充服务包含操作的具体详情。

但通过Logs查询相关数据时，得到的请求数量远高于Metrics Chart中的数值，使用的KQL语句如下：

requests
| where cloud_RoleName startswith "notificationengine"
| summarize Count = count() by operation_Name
| order by Count

查询结果如下：

问题是部分Metrics Chart与Logs的数据差异极小甚至完全一致，但部分数据（比如示例中的）差异极大。修改KQL语句和排查后没有进展，疑惑两者都标注为“requests”，实际差异究竟是什么？

核心差异原因 #

1. 采样机制不同
   Metrics默认可能启用了采样，高流量场景下会只采集部分请求来降低成本；而Logs的requests表默认记录所有未被采样过滤的请求（除非你单独配置了Logs采样）。这会导致Metrics是采样后的统计值，Logs是全量或低采样的真实计数。

2. 时间与粒度不匹配
   若Metrics的时间范围、聚合粒度（如5分钟、1小时）和Logs查询的范围不一致，会出现数据差异。比如Metrics用1小时粒度聚合时会合并数据，而Logs查询的是原始时间点的记录；另外，Metrics和Logs的时间戳对齐逻辑可能不同（一个用生成时间，一个用 ingestion 时间）。

3. 指标定义有区别

   • Metrics的Requests可能仅统计成功请求（如HTTP 2xx状态码），而Logs的requests表包含所有请求（失败、拦截的都算）
   • 部分服务的Metrics会排除内部请求、健康检查请求，但Logs会全部记录
   • 分布式追踪场景下，Metrics可能只统计入口请求，Logs却包含上下游服务的内部调用，导致计数重复

4. 数据延迟差异
   Metrics的数据聚合展示更快，Logs的 ingestion 可能有延迟（尤其是流量高峰时）。如果查询的是最近时间段，Logs可能还没接收完所有数据，而Metrics已完成聚合，造成临时差异。

排查验证步骤 #

• 检查采样配置：
  进入Application Insights资源→配置→数据采样，确认Metrics和Logs的采样率是否一致。如果Metrics用了固定低采样率，而Logs是自适应或高采样率，就会出现数值差。

• 对齐时间与粒度：
  在Logs查询中添加和Metrics完全匹配的时间范围与聚合粒度，比如：

  requests
  | where cloud_RoleName startswith "notificationengine"
  | where timestamp between (datetime(2024-05-20T00:00:00)..datetime(2024-05-20T23:59:59)) // 替换为Metrics的时间范围
  | summarize Count = count() by operation_Name, bin(timestamp, 5m) // 匹配Metrics的聚合粒度
  | order by Count
  

• 匹配请求筛选规则：
  按Metrics的可能规则过滤Logs数据，比如只统计成功请求：

  requests
  | where cloud_RoleName startswith "notificationengine"
  | where success == true
  | summarize Count = count() by operation_Name
  | order by Count
  

• 排除内部请求：
  查看Metrics的指标筛选规则，确认是否排除了特定操作名称，在Logs中同步排除后再对比数值。

内容的提问来源于stack exchange，提问作者Whey