进阶篇丨链路追踪（Tracing）很简单：常见问题排查

经过前面多篇内容的学习，想必大部分同学都已经熟练掌握分布式链路追踪的基础用法，比如回溯链路请求轨迹，定位耗时瓶颈点；配置核心接口黄金三指标告警，第一时间发现流量异常；大促前梳理应用上下游关键依赖，联系相关方协同备战等等。随着深入使用链路追踪技术，问题发现与诊断方面的能力想必都有大幅提升。

但实际生产过程中的问题可能更加棘手：

比如接口偶发性超时，调用链只能看到超时接口名称，看不到内部方法，无法定位根因，也难以复现，怎么办？

比如接口调用成功，但是业务状态异常，导致结果不符合预期，如何排查？

比如大促压测时或发布变更后，发现 CPU 水位非常高，如何分析应用性能瓶颈点，针对性优化？

比如同一份代码，本地调试都正常，但是发布到线上环境就报错，如何定位代码行为不一致的原因？

诸如此类的难题它们好像不属于链路追踪的范畴，却又与链路追踪有着千丝万缕的联系。

链路追踪是可观测不可分割的一部分，我们不应该人为的划分边界，而是要打破数据孤岛，紧密结合其他可观测技术，以提高系统稳定性为目标，最大化的发挥链路追踪的关联价值。

本小节通过对经典案例的解读，大家将掌握链路追踪与其他可观测技术结合应用的窍门，打破对链路追踪固有的认知，深入理解链路追踪在可观测领域的关联价值。

01 应用日志关联：一次订单支付失败行为的全息排查

【问题描述】某天，收到了来自前线小二反馈的客户投诉，订单支付一直失败，客户情绪非常焦躁，需要尽快给予回复，投诉工单记录了支付失败的订单号 213589741238xxxx。

【难点分析】订单支付接口依赖了多个下游服务，接口调用本身是成功的，但是业务报错导致支付失败。而且只有订单中心的应用日志记录了订单号，下游应用日志没有订单号信息，无法直接通过订单号进行全应用扫描。

【解决思路】利用链路追踪的上下游追溯能力进行信息串联。

a. 通过失败订单号检索订单中心的应用日志，并找到日志中关联的 TraceId。

b. 通过 TraceId 查询全链路调用轨迹，找到当次请求依赖的上下游调用。

c. 通过查询上下游应用跟当次请求相关的应用日志，定位到订单支付失败原因，原来是优惠券失效导致的。

【延伸思考】通过上述案例，可以发现全息排查的前提是实现 TraceId 与应用日志的双向绑定，目前业界的主流做法是将 TraceId 添加到应用日志中实现关联。在链路多维筛选小节中，我们介绍了两种在日志输出中添加 TraceId 的方式：基于 SDK 手动埋点与基于日志模板自动埋点，感兴趣的同学可以详细阅读相关章节的介绍。

02 慢调用方法栈自动剖析：偶发性慢调用，如何定位导致问题的那一行代码？

【问题描述】负责稳定性的同学对这种场景应该不陌生：系统在