Appearance
链路追踪和日志关联怎么真正用于排障
先说结论
- 链路追踪负责回答“请求经过了哪些服务、哪一段最慢”，日志负责回答“业务到底发生了什么”
- traceId 一定要贯穿网关、应用、异步消息和定时任务，否则关键链路会断
- 真正好用的不是采集越多越好，而是能用少量关键信息快速定位问题
一、为什么光有链路图还不够
很多系统已经接了 SkyWalking、Jaeger 或 OpenTelemetry，但出问题时还是要翻很久日志。原因通常是：
- trace 只告诉你哪段慢
- 但日志没打出订单号、用户号、请求参数、异常上下文
- 或者日志打了，但没有 traceId，根本串不起来
所以更实际的目标是：
先用 trace 找到可疑链路，再用日志把这条链路里的业务事实补全。
二、最少要打通哪几条透传链路
1. 网关到服务
入口请求在网关生成 traceId，往后透传到每个微服务。
2. 服务到 MQ
消息生产时把 traceId、业务单号一起放进消息头或消息体元数据。
3. MQ 到消费者
消费者起处理链路时继续接住原 traceId，否则异步链路会变成断点。
4. 定时任务和补偿任务
这类任务也应该生成自己的 traceId，并把关联的业务 ID 打进去。
三、日志里真正值得保留什么
比起大段无意义文本，更有价值的是固定字段：
- traceId
- spanId
- orderId / paymentId / userId
- 服务名、实例名
- 关键状态变更
- 下游调用耗时
- 异常码和异常摘要
日志要尽量结构化，否则你很难在高并发故障里快速筛出同一条业务链路。
四、最容易踩的坑
1. 采样做得太粗暴
全量采集成本太高，完全随机采样又可能漏掉关键异常。更推荐：
- 高频正常流量按比例采样
- 错误请求尽量全采
- 关键交易链路提高采样率
2. traceId 有了，但业务 ID 没打
你能看到链路，却不知道它是哪笔订单、哪笔支付，排障效率还是很差。
3. MQ 和异步任务没透传上下文
这会让“订单已创建 -> 支付回调 -> 发货补偿”这类链路在图上看起来像多段孤岛。
4. 日志太多，但没有关键摘要
大量 debug 日志并不等于可观测，真正关键的是关键状态点是否打齐。
五、排障时更实用的顺序
- 先按错误时间段找到异常接口或异常 trace。
- 看最慢的 span 在哪一段。
- 再用 traceId 去日志系统查这条链路的业务上下文。
- 如果是异步问题，继续按业务 ID 串 MQ 消费和补偿任务。
这样比单独查日志或单独看追踪图都要高效。
总结
链路追踪和日志关联真正的价值，不是为了做出一张很漂亮的调用图，而是让你能在异常发生时，从入口请求一路追到业务事实。trace 找慢点，日志补语义，traceId 和业务 ID 一起透传，这套组合才真正能用于排障。