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

欢迎大家来到IT世界,在知识的湖畔探索吧!

点击链接阅读原文，获取更多技术内容：进阶篇丨链路追踪（Tracing）很简单：常见问题排查-阿里云开发者社区

作者：涯海

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

欢迎大家来到IT世界,在知识的湖畔探索吧!

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

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

【问题描述】负责稳定性的同学对这种场景应该不陌生：系统在夜间或整点促销时会出现偶发性的接口超时，等到发现问题再去排查时，已经丢失了异常现场，并且难以复现，最后只能不了了之。上述场景重复上演直至酿成故障，最终蒙受巨大的业务损失。

【难点分析】开源的链路追踪实现通常只能记录超时的接口，无法细化到具体的方法栈，开发同学不知道该如何修复。而偶发性异常没有规律，又难以复现，很难通过手动 jstack 或者 Arthas 等在线诊断工具去精准定位根因。

【解决思路】为链路追踪埋点添加回调函数，自动记录慢请求的本地方法栈，真实还原代码执行的第一现场。如下图所示，当接口调用超过一定阈值（比如2秒），会启动对该次慢请求所在线程的监听，直至该次请求结束后立即停止监听，精准保留该次请求生命周期内所在线程的快照集，并还原完整的方法栈及耗时，最终定位耗时主要消耗在请求数据库连接 getConnection 方法上，通过增加数据库连接数可以解决响应慢的问题。

【延伸思考】目前主流的开源链路实现并不支持慢调用方法栈自动剖析，只有少数商业化产品（如阿里云 ARMS）支持了该特性。为了能够获取完整的方法栈信息，传统的链路插桩（Instrument）并不适合获取方法栈监听，只能利用采样法（Sampling）进行堆栈聚合，但全局采样的高开销很难实现常态化自动监听，必须结合链路追踪埋点，精准定位慢调用所在线程与生命周期，低成本实现精准、轻量级的采样监听。

03 CPU利用率高“三步排查法”：大促前夕压测发现CPU水位非常高，如何分析应用性能瓶颈点，针对性优化？

【问题描述】双十一大促前夕，部门组织了核心应用全链路压测，然而小玉负责的订单中心在第一波压测流量脉冲下 CPU 利用率瞬间飙升到 90% 以上，接口调用大量超时，成为了全链路性能瓶颈，导致压测活动草草结束，主管责令她在一周内限期完成优化。

【难点分析】CPU 利用率高可能是单纯的机器资源不足，也可能是不合理的代码导致的。基础的 CPU 监控只能反映问题，无法定位根因，缺乏资源到代码的映射关系，导致很多同学无法简单直接的进行代码优化，只能盲目扩容。

【解决思路】以 Java 应用为例，我们可以利用工具一步步定位导致 CPU 利用率高的异常代码片段，主要分为以下三步：

a. 查看 CPU 基础监控，确定流量洪峰与 CPU 利用率飙升曲线在时间上是否吻合，CPU 利用率上涨的主要原因是否为用户态 CPU 上涨，排除宿主机“超卖”，磁盘故障等硬件因素的干扰。

阿里云开发者社区，千万开发者的选择。百万精品技术内容、千节免费系统课程、丰富的体验场景、活跃的社群活动、行业专家分享交流，尽在：

阿里云开发者社区-云计算社区-阿里云