Azure Application Insights/Log Analytics：如何正确关联exceptions与其他表？

一、Operation ID、Span ID、Trace ID的区别 #

这三个ID是分布式追踪体系的核心标识，作用清晰区分：

• Trace ID：整个分布式请求链路的全局唯一标识。比如用户发起一次下单请求，该请求经过网关、订单服务、支付服务等多个环节，所有环节产生的日志、异常、请求记录都会共享同一个Trace ID，用来串联完整业务流程。
• Span ID：单个操作单元的唯一标识。一个Trace由多个Span组成，每个Span代表一个独立工作步骤——比如一次数据库查询、一段代码逻辑执行、一个下游服务调用。Span之间可存在父子关系，精准反映调用链的层级结构。
• Operation ID：在Application Insights中是Trace ID的别名，作用完全等价，用于在不同表（如requests、traces、exceptions）中关联同一次请求链路的所有数据。

二、关联Exceptions表与其他表的正确方式 #

完全可以通过关联获取更多故障信息，以下是几种合理的关联方式：

1. 与Requests表关联 #

使用operation_Id作为关联键，必须用左外连接（leftouter）——因为很多异常不对应HTTP请求（比如后台定时任务、异步线程抛出的异常），内连接会直接丢失这部分数据。
示例查询：

exceptions
| project operation_Id, exception_type = type, exception_message = details
| join kind=leftouter (
    requests
    | project operation_Id, request_url = url, response_code = resultCode, request_duration = duration
) on operation_Id
| project operation_Id, request_url, response_code, exception_type, exception_message, request_duration

2. 与Traces表关联 #

有两种关联维度，按需选择：

• 通过operation_Id关联：可获取异常所在整个请求链路的所有日志，适合查看异常发生的完整上下文，排查链路各环节问题。
• 通过Span ID关联：如果应用日志和异常日志都携带Span ID（通常在customDimensions或标准字段中），可精准关联到异常发生的具体操作步骤对应的日志，定位异常触发的具体环节。
  同样建议使用左外/右外连接，避免丢失无对应关联的数据。
  示例（Span ID关联）：

exceptions
| project span_id = tostring(customDimensions.SpanId), exception_type = type, exception_msg = message
| join kind=leftouter (
    traces
    | project span_id = tostring(customDimensions.SpanId), trace_msg = message, log_level = severityLevel
) on span_id
| project span_id, trace_msg, log_level, exception_type, exception_msg

三、对你提供的KQL查询的分析 #

你的查询逻辑是筛选4xx状态码的追踪日志，关联对应异常后统计分类数量，这个思路可行，但有几个细节需要注意：

1. arg_max(resultCode, *) by spanId的逻辑：如果同一个Span ID对应多条不同resultCode的日志，会保留最新的那条。若你的场景中一个Span仅对应一个状态码，该逻辑没问题；若存在多个状态码，需确认是否符合统计需求。
2. 左外连接的使用合理，确保所有4xx追踪日志都被统计，即使没有对应异常。
3. Span ID的来源：依赖customDimensions.SpanId存在风险——部分SDK或配置不会自动将Span ID写入自定义维度，建议优先检查表中的标准spanId字段（如果存在），避免关联失效。

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