作者：涯海
通过后面多篇内容的学习，想必大部分同学都曾经熟练掌握分布式链路追踪的根底用法，比方回溯链路申请轨迹，定位耗时瓶颈点；配置外围接口黄金三指标告警，第一工夫发现流量异样；大促前梳理利用上下游要害依赖，分割相干方协同备战等等。随着深刻应用链路追踪技术，问题发现与诊断方面的能力想必都有大幅晋升。
但理论生产过程中的问题可能更加辣手：
比方接口偶发性超时，调用链只能看到超时接口名称，看不到外部办法，无奈定位根因，也难以复现，怎么办？
比方接口调用胜利，然而业务状态异样，导致后果不合乎预期，如何排查？
比方大促压测时或公布变更后，发现 CPU 水位十分高，如何剖析利用性能瓶颈点，针对性优化？
比方同一份代码，本地调试都失常，然而公布到线上环境就报错，如何定位代码行为不统一的起因？
诸如此类的难题它们如同不属于链路追踪的领域，却又与链路追踪有着千头万绪的分割。
链路追踪是可观测不可分割的一部分，咱们不应该人为的划分边界，而是要突破数据孤岛，紧密结合其余可观测技术，以进步零碎稳定性为指标，最大化的施展链路追踪的关联价值。
本大节通过对经典案例的解读，大家将把握链路追踪与其余可观测技术联合利用的诀窍，突破对链路追踪固有的认知，深刻了解链路追踪在可观测畛域的关联价值。
01 利用日志关联：一次订单领取失败行为的全息排查
【问题形容】 某天，收到了来自火线小二反馈的客户投诉，订单领取始终失败，客户情绪十分烦躁，须要尽快给予回复，投诉工单记录了领取失败的订单号 213589741238xxxx。
【难点剖析】 订单领取接口依赖了多个上游服务，接口调用自身是胜利的，然而业务报错导致领取失败。而且只有订单核心的利用日志记录了订单号，上游利用日志没有订单号信息，无奈间接通过订单号进行全利用扫描。
【解决思路】 利用链路追踪的上下游追溯能力进行信息串联。
a. 通过失败订单号检索订单核心的利用日志，并找到日志中关联的 TraceId。
b. 通过 TraceId 查问全链路调用轨迹，找到当次申请依赖的上下游调用。
c. 通过查问上下游利用跟当次申请相干的利用日志，定位到订单领取失败起因，原来是优惠券生效导致的。
【延长思考】 通过上述案例，能够发现全息排查的前提是实现 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 上涨，排除宿主机“超卖”，磁盘故障等硬件因素的烦扰。
b. 查看线程剖析监控，判断是哪一类线程（池）耗费的 CPU 最多，以及此类线程的 CPU 耗时曲线是否与 CPU 利用率曲线吻合，初步定位异样线程类别。
c. 通过 CPU 诊断工具，剖析异样时段内的 CPU 火焰图，确定 CPU 占比最高的办法调用栈，进行针对性的优化。如下图所示，耗费 CPU 99.7% 占比的办法是 CPUPressure.runBusiness() 办法。
【延长思考】
- CPU 剖析的难点是不足无效的工具，可能给出资源到代码之间的映射关系，间接定位异样代码片段，领导研发同学进行优化。此外，诊断行为绝对于问题产生往往是滞后的，工具必须具备常态化运行，主动保留异样现场的能力。如何均衡现场快照的信息度与工具本身的资源开销，十分考验产品设计与技术实现能力，许多商业化产品在这一点上存在着不小的差距。
- 如果某个外围办法的代码逻辑变更频繁，容易造成性能进化，还能够为其增加链路埋点，进行常态化的监听。更进一步，还能够将该办法关联的 CPU 开销展现在调用链上，进步诊断的效率，如下图所示。
04 内存异样“三步排查法”：利用频繁 FGC 或是内存解体，如何定位根因，保障服务可用性？
【问题形容】 FullGC 相对是 Java 利用最常见问题之一，对象创立过快、大对象调配、内存透露等各种起因都会导致 FGC。比 FGC 更重大的是内存解体，比方不合理的应用堆外内存 DirectBufferMemory，可能导致 OOM（OutOfMemoryError），JVM 解体，服务不可用等严重后果。
【难点剖析】 导致内存异样的起因千奇百怪，最无效的形式就是记录内存异样的现场快照。然而内存快照的记录老本十分高，很难常态化主动保留。等到真正出问题的时候又可能来不及记录了，这就导致内存诊断变得十分艰难。
【解决思路】 以 Java 利用为例，联合工具由易到难逐渐定位内存异样起因，次要分为以下三步：
a. 查看 JVM 监控，剖析新生代、老年代、Metaspace、DirectBuffer 等内存变动，初步定界内存异样的类型，以及确认是否存在内存泄露景象。
b. 通过轻量化内存诊断，剖析异样时段的内存对象调配火焰图，定位分配内存最多的办法，进行重点剖析。如下图所示，99.92% 的内存是通过 AllocMemoryAction.runBusiness() 办法申请的。
c. 分配内存多，并不代表常驻内存多，大部分对象可能通过 YGC 就开释掉了。因而，针对一些疑难杂症，还须要应用 HeapDump 来进行最终定位。
【延长思考】 轻量化内存诊断是介于 JVM 监控与 HeapDump 之间的折中办法，能够常态化记录内存申请信息，在大部分场景能够无效工作。与 CPU 诊断相似，如果某个外围办法频繁申请内存，能够思考对其增加链路埋点，并关联内存申请与 GC 等信息，进步调用链信息集成度与诊断效率。
05 白屏化在线诊断：程序运行不合乎预期，本地调试胜利的代码，公布到线上就报错，怎么办？
【问题形容】 本地调试通过的代码，一旦公布到线上环境就各种报错，到底哪里出了问题？置信开发同学都经验过这样的噩梦。导致这种问题的起因有很多，比方 Maven 依赖多版本抵触，不同环境动静配置参数不统一，不同环境依赖组件差别，本地无奈模仿线上环境实在流量参数或压力等等。
【难点剖析】 本地、日常、预发、生产，不同环境之间总存在着这样或那样的一些差别，导致同一份代码体现出不同的行为或异样，必须在以后环境进行诊断定位。传统的近程 debug 模式操作简单，平安危险高。而相似 Arthas 这种单机诊断工具须要黑屏登录，命令行交互，应用起来也比拟麻烦。
【解决思路】 在 APM 探针中内置在线诊断模块，通过控制台进行白屏化交互，依照诊断场景进行命令封装，进一步简化操作老本。比方通过调用链找到异样调用的全门路类名与办法后，对该办法执行源码解析、出入参拦挡等经典诊断命令，实时查看以后程序运行态的源代码、出入参、执行办法栈与耗时、动态对象或动静实例的值等等，让在线调试就像本地调试一样不便，一键定位错慢根因。
【延长思考】 白屏化只是在线诊断的第一步优化，如何进一步升高诊断开销与危险，从单机诊断降级为集群诊断，从主动式诊断降级为主动触发式诊断，从特定语言（如 Java）向全语言笼罩，须要更多新技术与产品的迭代。
06 摸索式链路剖析与监控：1 秒战斗，如何常态化治理入口申请慢响应问题？
【问题形容】 入口申请的响应时延间接影响着终端用户的体验，依据 Google 的统计，时延每减少 500 毫秒就会导致 20% 的访问量散失，而 Amazon 也有相似的发现，每减少 100 毫秒的时延就会导致 1% 的销售额降落。因而，很多企业 IT 服务都会制订严格的入口服务响应时延 SLA，尽可能保障终端用户的拜访可能失去疾速响应。然而，影响时延的因素有很多，流量不均、单机故障、程序异样、依赖组件瓶颈等都会显著影响入口申请的时延，如何低成本的进行常态化治理呢？
【难点剖析】 不同企业、不同类型的服务对时延的要求不尽相同，影响时延的维度特色也比拟发散，很难通过开源或商业化产品内置的根底监控实现慢申请的筛选与剖析。基于明细数据的剖析尽管比拟灵便，然而全量检索的老本比拟高，当剖析规定较多时，不适用于常态化的监控与告警，无奈被动告诉时延进化危险。
【解决思路】 咱们须要将链路剖析与监控的能力进行联合，既能灵便满足用户自定义的查问剖析诉求，还能将用户的剖析规定进行固化，生成自定义链路指标，实现常态化的监控与告警。
a. 通过 TraceExplorer 对链路明细数据进行在线筛选与剖析，能够依据业务须要灵便设置各种条件，比方查看特定入口利用大于 3 秒的慢申请散布在哪些接口，如下图所示。
b. 保留刚刚设置的查问剖析规定，便于后续一键疾速剖析。不过这一步还是基于链路明细数据，剖析老本比拟高，并且后果的准确性强依赖链路数据采样率，不适宜常态化监控与告警。
c. 为了实现低成本的常态化监控与告警，还能够将查问剖析规定下推，在数据处理端生成新的自定义链路指标（预聚合）。
【延长思考】 在理论生产环境中，服务通常是标准化的，但业务却须要分类分级。同样的订单服务，咱们须要依照类目、渠道、用户等维度进行分类统计，实现精细化经营。比方，对于线下批发渠道而言，每一笔订单、每一个 POS 机的稳定性都可能会触发舆情，线下渠道的 SLA 要求要远高于线上渠道。那么，咱们如何在通用的电商服务体系中，精准的监控线下批发链路的流量状态和服务质量呢？答案就在链路数据的自定义标签 Attributes 中，比方，咱们在入口服务针对线下订单打上一个 {“attributes.channel”: “offline”} 的标签，而后再针对不同门店、用户客群和商品类目别离打标。最初，通过对 attributes.channel = offline 进行过滤，再对不同的业务标签进行 group by 分组统计调用次数、耗时或错误率等指标，就能够疾速的剖析出每一类业务场景的流量趋势与服务质量。
07 智能根因定位：如何让老手具备“专家级”诊断能力，疾速定位经典问题根因？
【问题形容】 线上利用危险次要分为“错”、“慢”两大类。其中“错”的起因通常是程序运行不合乎预期 ，比方 JVM 加载了谬误版本的类实例，代码进入异样分支，环境配置谬误等。 而“慢”的起因通常是资源有余，比方突发流量导致 CPU 打满，微服务或数据库线程池被耗尽，内存透露导致继续 FGC 等等。无论是“错”问题，还是“慢”问题。从用户的角度，都是心愿可能疾速定位根因，及时止损，并消除隐患。然而，绝大部分线上问题无奈仅通过链路追踪的根底能力就能无效定位并解决，须要联合资源监控、代码诊断等多方面能力，对排查人员的教训和能力要求十分高，如何让更多同学疾速具备“专家级”诊断能力呢？
【难点剖析】 一个谬误的运维动作可能引发大范畴的可用性故障，线上环境的低容错性与高时效性特色，对于根因定位的精度与速度要求很高。因而，很多基于概率的机器学习算法并不适用于运维畛域。此外，一个具备丰盛教训和能力的诊断专家须要大量的工夫积淀与案例“喂养”，在互联网疾速迭代的背景下，只有少部分公司可能造就出此类稀缺人才，无奈疾速批量复制。
【解决思路】 线上利用危险是有肯定的迹象可循的，针对常见经典问题，咱们能够基于领域专家教训联合比拟成熟的算法，实现经典问题的主动根因定位或定界，进步诊断效率，升高诊断门槛。比方咱们首先通过时序异样检测算法，辨认到 A 利用下单接口耗时突增，查看 A 利用本身资源并没有发现瓶颈，而后查看下单接口依赖服务，发现上游接口耗时突增，逐级追溯后最终定位到 C 利用有 2 台机器 CPU 利用率过高，达到 95%+，对 C 利用进行紧急扩容后复原。
【延长思考】 针对运维畛域的经典问题根因定位，在现阶段更适宜采纳以专家教训为主，算法为辅的伎俩，实质上是人工查看流程的自动化积淀，还远未达到智能化的水平，也不该自觉谋求“高大上”的算法，而应以实用为主，优先解决数据残缺度与丰盛度。
08 小结
链路追踪（Trace）最大的价值在于“关联”，无论是从数据层面关联利用日志（Logs）、要害事件（Events）、性能指标（Metrics）或诊断工具（Profiling），还是从零碎层面关联用户终端、网关、利用、中间件、容器与基础设施，链路追踪最大的价值不在于本身，而在于关联性的场景化出现，让咱们一起来持续开掘更多更有价值、也更有意思的用法吧！