Application Insights Requests表出现重复operation_id的原因及配置方法

一、Requests表出现重复operation_id的常见原因 #

• 分布式链路追踪的原生设计：operation_id 是跨全链路的全局追踪标识，而非单条请求记录的唯一主键。一次完整的调用链路会将同operation_id 关联的请求、依赖调用、异常、日志统一归集，只要同一次逻辑链路中存在多次匹配GetFuelPriceAsync的请求记录，查询结果里就会出现同一operation_id 对应多行数据，这是正常设计而非异常。你当前编写的Kusto查询仅做了接口名称筛选，未做去重或聚合统计，因此会把同链路下所有匹配的请求行直接展示出来，直观上就会呈现为operation_id重复的状态。
• 上下文传递逻辑偏差：如果请求处理过程中出现异步上下文丢失、自定义中间件手动硬编码复用同一个operation_id、代码中手动重复调用遥测上报接口复用了同一个上下文字符串，就会让多次独立的逻辑请求被打上同一个operation_id，或是同一次请求被拆成多条记录上报。
• 多实例部署下的上报冗余：应用多实例运行时，若遥测上报通道遇到网络波动触发重试，或是SDK版本存在兼容缺陷，可能导致同一条request记录被重复上报到Application Insights后端，带着完全相同的operation_id形成重复行。
• 前端会话的透传规则：如果SPA应用或移动端会话在同一次用户操作流中多次调用GetFuelPriceAsync接口，后端遥测会将整个前端会话流标记为同一个根operation_id，不会给每次独立的API请求分配新的operation_id。

二、正确配置保障遥测的operation_id关联一致性 #

• 校准SDK的上下文注册顺序
  对ASP.NET/ASP.NET Core应用，确保AddApplicationInsightsTelemetry()的服务注册顺序在路由、认证、自定义业务中间件之前，避免业务代码先于遥测模块执行导致上下文断连，保证每个独立HTTP请求都会自动生成唯一的operation_id。
• 自定义遥测初始化器的逻辑校验
  检查项目内的自定义TelemetryInitializer，禁止硬编码固定的operation_id值；要基于当前HTTP请求的上下文、或是从请求头透传的分布式链路标识（如traceparent）生成operation_id，不要随意覆盖上游传入的合法链路标识。
• 按业务语义拆分链路粒度
  如果存在一次用户操作触发多次同接口调用的场景，可通过自定义遥测处理器，为每次独立的请求处理流程生成独立的operation_id；对内部嵌套、循环触发的同接口调用，可将其关联为根operation_id的子节点（通过operation_parentId字段关联），避免所有嵌套请求都直接挂载在根operation_id下。
• 优化采样与上报通道配置
  配置自适应采样规则时，设置同operation_id下的关联遥测同步保留/丢弃，避免链路断链；同时对遥测上报通道配置重试去重逻辑，降低网络重试导致的重复上报概率。
• 优化排查用Kusto查询逻辑
  可使用如下调整后的查询，区分正常的链路关联数据和真正的重复异常：

  requests
  | where operation_Name contains "GetFuelPriceAsync"
  | summarize
      链路内请求数 = count(),
      最早上报时间 = min(timestamp),
      最晚上报时间 = max(timestamp),
      请求URL集合 = make_set(url),
      状态码集合 = make_set(resultCode)
    by operation_id, operation_Name
  | where 链路内请求数 > 1
  

  如果查询返回的重复行对应记录的上报时间、URL、状态码完全一致，即可判定为SDK重复上报问题；如果记录存在时间、参数、状态的差异，就是同链路下的正常关联请求。

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