请求返回500错误时谁添加activity id？为何Application Insights无对应日志？

一、谁在响应中添加了Activity ID？ #

• APIM 原生生成：只要请求进入APIM的处理管线，无论后续是否能成功转发到后端，APIM都会自动生成并注入activityid到响应中。这个ID是APIM用于追踪自身处理流程的核心标识，默认由APIM系统层面添加。
• 额外排查点：如果你的APIM配置了自定义策略（比如set-header类策略），可以检查入站/出站策略是否存在手动注入activityid的逻辑，但绝大多数场景下都是APIM原生生成。

二、为何无法通过Activity ID在Application Insights中找到对应日志？ #

可能存在以下几种核心原因：

• 日志采集配置未生效：
  • 检查APIM的诊断设置，确认是否已开启将「请求日志」「依赖项日志」发送到目标Application Insights资源，且日志级别包含Error或Verbose。若诊断设置是故障发生后才配置的，那当时的请求日志不会被回溯采集。
• 查询方式错误：
  • 在App Insights中，APIM的activityid对应日志字段是operation_Id，需在日志查询界面使用精确语句检索，比如：

    requests | where operation_Id == "<你的activityid>"
    

    或

    dependencies | where operation_Id == "<你的activityid>"
    

    直接全局搜索可能因字段不匹配导致无法命中。
• 请求未完成日志上报流程：
  • 若500错误发生在APIM处理的早期阶段（比如入站策略验证失败、路由配置错误），APIM可能还未完成日志上报流程就返回了错误；或者APIM自身出现内部异常，导致日志上报中断。
• APIM控制台测试的特殊性：
  • APIM测试控制台的请求走内部环路，不会经过应用网关，且部分测试请求会被标记为内部流量，未纳入正式日志采集范围，这也是控制台测试超时却找不到对应日志的原因。

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