使用篇丨链路追踪（Tracing）其实很简单：请求轨迹回溯与多维链路筛选

作者：涯海

在日常生活中，咱们或许都经历过以下场景：去医院治病就诊，但预约页面迟迟无法翻开；新款手机发布日促销秒杀，下单页面一向卡住转菊花；游戏大版别更新，在线人数过多，导致人物一向在“漂移”。这些问题令产品体会变得十分差，有耐心的同学还会吐槽几句，没耐心的同学早已转身离开。试想一下，作为该体系开发/运维人员，又该怎样避免此类问题发生，或许快速定位止损？

要害途径与多条链路比照

本章咱们将以事务 Owner（小帅）的视角，逐渐了解散布式链路追寻的各种根底用法：小到单次用户恳求的反常根因确诊，大到大局体系的强弱依靠整理，散布式链路追寻都能给予确定性答案。

小帅作为一家电商公司订单中心的事务 Owner，中心 KPI 便是保证创立订单 createOrder 接口的可用性，如呼应时延低于 3s，成功率大于 99.9%。一旦该接口可用性呈现问题，会直接影响用户下单行为，形成事务资损，然后影响小帅的绩效和年终奖。

但创立订单接口直接或间接依靠多个其他体系服务，如资金、地址、优惠、安全等。一旦某个下流体系服务可用性呈现问题，也会形成创立订单失败或超时。为此，小帅特别头痛，每逢创立订单接口不可用时，小帅都十分心急，却不知该怎样定位根因，只能拉上一切下流接口担任人一起评估，不只费时吃力，低效排查也形成事务损失进一步扩展，经常被老板痛骂。

当小美了解这个状况后，引荐接入散布式链路追寻体系，并经过一系列故障应急事例，辅导怎样利用 Tracing 定位问题，整理危险，提前预警，实在进步了订单中心的可用性。小帅经常会遇到各种用户反馈的创立订单超时问题，以往对此类问题颇有些束手无策。不过，接入散布式链路追寻体系后，经过调用链精确回溯超时恳求的调用轨道，小帅就能够轻松定位耗时最长的接口信息，如下图所示，A 接口超时的首要原因是调用 D 接口导致的。

但假如是下面这种状况，A 调用 B，B 又调用 C。那么，导致 A 接口超时的根因到底是 B 接口，仍是 C 接口呢？

为了区别实在影响用户体会的 Span 耗时，咱们先来了解一下要害途径的概念。

要害途径

假如一次 Span 调用有 t 段耗时在要害途径上，那么去掉这 t 段耗时，整条链路的总体耗时也会相应的缩短 t 段时刻。 仍以上面那条链路为例，灰色部分表示要害途径，缩短任意要害途径上的耗时都能够削减全体耗时。此刻，咱们能够判别 A 接口超时的首要原因是 C 接口导致的。

再来看另一种状况，假如 A 接口同一时刻并行调用 B、C、D、E 接口，那么耗时最长的 D 接口就成为要害途径，如下图所示。

可是，假如咱们将 D 接口耗时削减 t1+t2 两段时刻，全体耗时却只削减了 t1 段时刻，由于，当 D 接口耗时小于 B 接口时，D 接口就不再是要害途径，而是由 B 接口替代。这就好像首要矛盾被大幅缓解后，次要矛盾就变成了首要矛盾。

综上所述，咱们在做耗时功能剖析时，应该首要识别出要害途径，然后再做针对性的优化。对于非要害途径上的耗时优化不会对终究的用户体会发生价值。

多条链路比照

单条调用链路只能用来剖析各个接口的肯定耗时，而无法得知每个接口的耗时改变状况。可是，肯定耗时长不代表这个接口就一定有问题，比方数据存储接口耗时一般要比单纯的计算接口耗时要长，这种长耗时是合理的，无需特别重视。

因而，在确诊功能退化问题时，咱们更应该重视相对耗时的改变。比方获取同一个接口在耗时反常时段与正常时段的多条链路进行比对，然后发现导致功能退化的原因。下图展示了 A 接口的两条不同链路，咱们能够清楚的看到，虽然第一条链路的 B 接口耗时要比 C 接口耗时长，可是导致 A 接口全体耗时从 2.6s 涨到 3.6s 的原因，其实是 C 接口的相对耗时变长了 1s，而 B 接口的相对耗时简直不变。因而，当 A 接口的呼应时延超越 3s，不满意可用性要求时，咱们应该优先剖析 C 接口相对耗时增加的原因，而不是 B 接口。

咱们再来看一个缓存未命中的比方，如下图所示。第一条链路调用了5次数据库，每一次调用的耗时都不算很长，可是 A 接口全体耗时却达到了 3.6s。当咱们比对之前未超时的链路时，发现 A 接口并没有调用数据库，而是恳求了5次缓存，全体耗时只要 1.8s。此刻，咱们能够判别 A 接口超时的原因是调用依靠行为发生了改变，本来应该恳求缓存的调用变成了恳求数据库，很或许是缓存被打满，或许是该次恳求的参数命中了冷数据，终究导致了接口超时。

经过上面两个事例，咱们认识到剖析功能问题时，不只需求知道肯定耗时的多少，更要重视相对耗时的改变。当然，有经历的同学假如对本身事务的正常链路形状了若指掌，就能够直接观察反常链路得出定论。

相关信息回溯

经过前面的学习，小帅现已成功掌握了调用链的轨道回溯才能，能够娴熟运用调用链剖析功能瓶颈点，快速定位反常的接口。可是，他又遇到了新的困惑，便是找到了反常接口之后，下一步该怎样办？比方 C 接口的耗时从 0.1s 增加到了 2.1s，导致了上游的 A 接口超时。可是只是知道这个信息还不够，C 接口耗时增加背面的原因是什么？怎样处理这个问题，让它恢复到本来的功能基线？

许多线上问题，很难只经过接口粒度的链路信息定位根因，需求结合愈加丰厚的相关数据，辅导下一步的举动。接下来，咱们经过几个事例，介绍几类最典型的链路相关数据，以及相应的用法。

本地办法栈

小帅担任的订单体系，每天上午十点都会有一波周期性的事务峰值流量，偶然呈现一些超时恳求，但下流调用耗时都很短，无法判别超时的具体原因，导致这个问题一向悬而未决，为此小帅十分头痛，只好求助小美。正常恳求与超时恳求的调用链路比照如下图所示。

由于超时恳求链路的相对耗时增加首要是 A 接口本身，因而，小美主张小帅启用慢调用办法栈自动剖析功能，自动抓取超时恳求的完整本地办法栈，如下图所示。

经过本地办法栈，小帅得知超时恳求是卡在 log4j 日志结构 callAppenders 办法上，本来 log4j 在高并发场景的同步输出会触发 “热锁”现象，小帅将 log4j 的日志输出由同步形式改为异步形式后，就处理了事务峰值超时的问题。

假如小帅运用的散布式链路追寻体系，并没有供给慢调用办法栈自动剖析功能，也能够经过 Arthas 等在线确诊东西手动抓取办法栈，定位到反常办法后，再考虑将其增加至本地办法插桩埋点中，进行常态化追寻。

自动相关数据

依据散布式链路追寻的结构阻拦点，能够自动相关多种类型的数据，比方接口恳求的出/入参数，调用进程中抛出的反常仓库，数据库恳求的履行 SQL 等等。此类信息不影响调用链的形状，却会极大的丰厚链路的信息，更明确的论述为什么会呈现这样或那样状况的原因。

比方小帅接到上游事务方反馈，某个新途径的商品下单总是超时，经过排查后发现该途径订单依靠的数据库调用十分的慢，经过剖析 SQL 明细才知道这个数据库调用是获取途径优惠信息，但没有做途径过滤，而是全量查询了一切优惠规则，优化 SQL 查询句子后超时问题就处理了。

自动相关数据一般由散布式链路追寻产品默许供给，用户依据本身的需求选择是否敞开即可，无需额外的操作成本。一般状况下，SQL明细和反常仓库相关主张常态化敞开，而记载恳求出/入参数需求消耗较大的体系开销，主张默许封闭，仅在需求的时分临时敞开。

自动相关数据

小帅的老板希望能够定时剖析来自不同途径、不同品类、不同用户类型的订单状况，而且将订单接口反常排查的才能向一线运营小二敞开赋能，进步用户支撑功率。正在小帅一筹莫展之际，小美主张小帅将事务信息相关至调用链上，供给事务标签统计、事务日志轨道排查等才能。

小帅听取了小美的主张后，首要将途径、品类、用户类型等事务标签增加到散布式链路追寻的 Attributes 方针中，这样就能够分别统计不同标签的流量趋势，时延散布和过错率改变；其次，小帅将事务日志也相关到散布式链路追寻的 Event 方针中，这样就能够查看一次订单恳求在不同体系中的事务轨道与信息，即使是不懂技能的运营同学也能够清晰的判别问题原因，更有用的支撑客户，如下图所示。

由于事务逻辑千变万化，无法穷举，所以事务数据需求用户自动进行相关，散布式链路追寻体系仅能简化相关进程，无法完成彻底自动化。此外，自界说标签和事务日志是最常用的两种自动相关数据类型，能够有用地将调用链确实定性相关才能扩展至事务领域，处理事务问题。

归纳剖析

经过本末节的学习，相信咱们现已十分了解散布式链路追寻的恳求轨道回溯才能，咱们再来全体回顾一下：首要调用链供给了接口维度的轨道追寻，而本地办法栈能够详细描述某个接口内部的代码履行状况，自动相关数据和自动相关数据在不改变链路形状的前提下，极大的丰厚了链路信息，有用辅导咱们下一步的举动。在一些比较复杂的问题场景，需求结合以上信息进行多角度的归纳判别，如下图所示。

上一末节咱们介绍了怎样经过调用链和相关信息进行问题确诊，可是，仔细的读者或许会有一个疑问，整个体系有那么多的调用链，我怎样知道哪条链路才是实在描述我在排查的这个问题？假如找到了不相符的链路岂不是会南辕北辙？

没错！在运用调用链剖析问题之前，还有一个很重要的进程，便是从海量链路数据中，经过各种条件挑选出实在反应当时问题的调用链，这个动作就叫做链路挑选。那什么叫多维呢？多维是指经过 TraceId、链路特征或自界说标签等多种维度进行链路挑选。每一种挑选条件都是由日常开发/运维的场景演变而来，最为符合当下的运用办法，进步了链路挑选的功率和精准度。

多维度链路挑选

（一）依据链路标识 TraceId 的挑选

说到链路挑选，咱们很天然的就会想到运用大局链路仅有标识 TraceId 进行过滤，这是最精准、最有用的一种办法。可是，TraceId 从哪里来？我该怎样获取呢？

怎样获取 TraceId？

虽然TraceId 贯穿于整个 IT 体系，只不过大部分时分，它只是静静合作上下文承担着链路传达的职责，没有显式的暴露出来。常见的 TraceId 获取办法有以下几种:

• 前端恳求 Header 或呼应体 Response：大部分用户恳求都是在端上设备发起的，因而 TraceId 生成的最佳地址也是在端上设备，经过恳求 Header 透传给后端服务。因而，咱们在经过浏览器开发者形式调试时，就能够获取当时测试恳求 Header 中的 TraceId 进行挑选。假如端上设备没有接入散布式链路追寻埋点，也能够将后端服务生成的 TraceId 增加到 Response 呼应体中回来给前端。这种办法十分适合前后端联调场景，能够快速找到每一次点击对应的 TraceId，然后剖析行为背面的链路轨道与状况。
• 网关日志：网关是一切用户恳求发往后端服务的署理中转站，能够视为后端服务的进口。在网关的 access.log 拜访日志中增加 TraceId，能够帮助咱们快速剖析每一次反常拜访的轨道与原因。比方一个超时或过错恳求，到底是网关本身的原因，仍是后端某个服务的原因，能够经过调用链中每个 Span 的状况得到确定性的定论。
• 运用日志：运用日志能够说是咱们最了解的一种日志，咱们会将各种事务或体系的行为、中间状况和结果，在开发编码的进程中顺手记载到运用日志中，运用起来十分便利。一起，它也是可读性最强的一类日志，即使对错开发运维人员也能大致了解运用日志所表达的意义。因而，咱们能够将 TraceId 也记载到运用日志中进行相关，一旦呈现某种事务反常，咱们能够先经过当时运用的日志定位到报错信息，再经过相关的 TraceId 去追溯该运用上下流依靠的其他信息，终究定位到导致问题呈现的根因节点。
• 组件日志：在散布式体系中，大部分运用都会依靠一些外部组件，比方数据库、音讯、配置中心等等。这些外部组件也会经常发生这样或那样的反常，终究影响运用服务的全体可用性。可是，外部组件一般是共用的，有专门的团队进行维护，不受运用 Owner 的操控。因而，一旦呈现问题，也很难形成有用的排查回路。此刻，咱们能够将 TraceId 透传给外部组件，并要求他们在自己的组件日志中进行相关，一起敞开组件日志查询权限。举个比方，咱们能够经过 SQL Hint 传达链 TraceId，并将其记载到数据库服务端的 Binlog 中，一旦呈现慢 SQL 就能够追溯数据库服务端的具体表现，比方一次恳求记载数过多，查询句子没有建索引等等。

怎样在日志中相关 TraceId？

已然 TraceId 相关有这么多的优点，那么咱们怎样在日志输出时增加 TraceId 呢？首要有两种办法：

• 依据 SDK 手动埋点：链路透传的每个节点都能够获取当时调用生命周期内的上下文信息。最根底的相关办法便是经过 SDK 来手动获取 TraceId，将其作为参数增加至事务日志的输出中。
• 依据日志模板自动埋点：假如一个存量运用有大量日志需求相关 TraceId，一行行的修正代码增加 TraceId 的改形成本属实有点高，也很难被履行下去。因而，比较老练的 Tracing 完成结构会供给一种依据日志模板的自动埋点办法，无需修正事务代码就能够在事务日志中批量注入 TraceId，运用起来极为便利。

依据 SDK 手动完成日志与 TraceId 相关示例

以 Jaeger Java SDK 为例，手动埋点首要分为以下几步：

1. 翻开运用代码工程的 pom.xml 文件，增加对 Jaeger 客户端的依靠（正常状况下该依靠现已被增加，能够越过）。

<dependency>
    <groupId>io.jaegertracing</groupId>     
    <artifactId>jaeger-client</artifactId>     
    <version>0.31.0</version> 
</dependency>

2. 在日志输出代码前面，先获取当时调用生命周期的 Span 方针，再从上下文中获取 TraceId 标识。

String traceId = GlobalTracer.get().activeSpan().context().toTraceId();

3. 将 TraceId 增加到事务日志中一并输出。

log.error("fail to create order, traceId: {}", traceId);

4. 终究的日志效果如下所示，这样咱们就能够依据事务要害词先过滤日志，再经过相关的 TraceId 查询上下流全链路轨道的信息。

fail to create order, traceId: ee14662c52387763

依据日志模板完成日志与 TraceId 自动相关示例

依据 SDK 手动埋点需求一行行的修正代码，无疑是十分繁琐的，假如需求在日志中批量增加 TraceId，能够选用日志模板注入的办法。

现在大部分的日志结构都支撑 Slf4j 日志门面，它供给了一种 MDC（Mapped Dignostic Contexts）机制，能够在多线程场景下线程安全的完成用户自界说标签的动态注入。

MDC 的运用办法很简单，只需求两步。

第一步，咱们先经过 MDC 的 put 办法将自界说标签增加到确诊上下文中：

@Test
public void testMDC() {     
  MDC.put("userName", "xiaoming");     
  MDC.put("traceId", GlobalTracer.get().activeSpan().context().toTraceId());     
  log.info("Just test the MDC!"); 
}

第二步，在日志配置文件的 Pattern 描述中增加标签变量 %X{userName} 和 %X{traceId}。

<appender name="console" class="ch.qos.logback.core.ConsoleAppender">
    <filter class="ch.qos.logback.classic.filter.ThresholdFilter">         
        <level>INFO</level>     
    </filter>     
    <encoder>         
        <pattern>%d{HH:mm:ss} [%thread] %-5level [userName=%X{userName}] [traceId=%X{traceId}] %msg%n</pattern>         
        <charset>utf-8</charset>     
    </encoder> 
</appender>

这样，咱们就完成了 MDC 变量注入的进程，终究日志输出效果如下所示：

15:17:47 [http-nio-80-exec-1] INFO [userName=xiaoming] [traceId=ee14662c52387763] Just test the MDC!

看到这儿，仔细的读者或许会疑问，MDC 注入不是也需求修正代码么？答案是确实需求，不过好在 Tracing 结构现已供给了简易的相关办法，无需逐行修正日志代码，极大的削减了改造量。比方 Jaeger SDK 供给了 MDCScopeManager 方针，只需求在创立 Tracer 方针时趁便相关上 MDCScopeManager 就能够完成 traceId、spanId 和 sampled 自动注入到 MDC 上下文中，如下所示：

MDCScopeManager scopeManager = new MDCScopeManager.Builder().build(); 
JaegerTracer tracer = new JaegerTracer.Builder("serviceName").withScopeManager(scopeManager).build();

经过 MDC 机制，有用推动了实践出产环境中运用日志与 Trace 链路的相关，你也快动手试试吧。

日志相关 TraceId 的限制有哪些？

并不是一切日志都能够与 TraceId 进行相关，最底子的原因便是在日志输出的时机找不到相对应的链路上下文，这是怎样回事呢？

本来，链路上下文仅在调用周期内才存在，一旦调用完毕，或许没有开端，又或许由于异步线程切换导致上下文丢掉等场景，都会无法获取链路上下文，也就无法与日志进行相关了。比方，在运用启动阶段，许多方针的初始化动作都不在恳求处理主逻辑中，强行相关 TraceId 只会获取到一个空值。

所以，在实践运用中，假如发现无法在运用日志中输出 TraceId，能够逐个查看以下几点：

1. 承认相似 MDCScopeManager 初始化的变量注入工作是否完成？
2. 承认日志模板中是否增加 %X{traceId} 变量？
3. 承认当时日志是否在某个调用的生命周期内部，且确保链路上下文不会由于异步线程切换导致丢掉。

综上所述，咱们能够在体系报错时，快速找到相关的 TraceId，再进行整条链路的轨道信息回溯，终究定位根因处理问题。可是，假如咱们由于各种限制还没有完成 TraceId 的相关，那么该怎样办呢？接下来咱们来介绍两种不需求 TraceId 的挑选办法。

（二）依据链路特征的挑选

链路特征是指调用链本身所具有的一些根底信息，比方接口名称，恳求状况，呼应耗时，节点IP、所属运用等等。这些根底信息被广泛运用于各类监控、告警体系。一旦运用呈现反常，会依据统计数据先判别出大致的问题影响面，比方在哪个运用，哪个接口，是变慢了仍是过错率升高了？

然后，再依据这些根底信息组合挑选出满意条件的调用链路，例如：

serviceName=order AND spanName=createOrder AND duration>5s

这样，咱们就能够过滤出运用名称为 order，接口名称为 createOrder，恳求耗时大于 5秒的一组调用链路，再结合上一末节学习的单链路或多链路轨道回溯剖析，就能够轻松定位问题根因。

（三）依据自界说标签的挑选

在排查某些事务问题时，链路特征无法完成调用链的精准挑选。比方下单接口的来源途径能够细分为线上门店、线下批发、线下零售、直播途径、三方推行等等。假如咱们需求精确剖析某个新途径的链路问题，需求结合自界说标签来挑选。

小帅地点的公司新拓展了线下零售形式，作为集团战略，需求要点保证线下零售途径的订单接口可用性。因而，小帅在下单接口的链路上下文中增加了途径（channel）标签，如下所示：

@GetMapping("/createOrder")
public ApiResponse createOrder(@RequestParam("orderId") String orderId, @RequestParam("channel") String channel) { 
... 
// 在链路上下文中增加途径标签 
GlobalTracer.get().activeSpan().setTag("channel", channel); 
... 
}

每逢线下零售同学反馈订单接口反常时，小帅就能够依据 channel 标签精准过滤出满意条件的调用链路，快速定位反常根因，如下所示：

serviceName=order AND spanName=createOrder AND duration>5s AND attributes.channel=offline_retail

（四）一个典型的链路确诊示例

本末节咱们介绍了三种不同的链路挑选办法，结合上一末节的恳求轨道回溯，咱们来看一个典型的链路挑选与确诊进程，首要分为以下几步：

1. 依据 TraceId、运用名、接口名、耗时、状况码、自界说标签等任意条件组合过滤出方针调用链。
2. 从满意过滤条件的调用链列表中选中一条链路查询概况。
3. 结合恳求调用轨道，本地办法栈，自动/自动相关数据（如SQL、事务日志）归纳剖析调用链。
4. 假如上述信息仍无法定位根因，需求结合内存快照、Arthas 在线确诊等东西进行二次剖析。

预告

在完整介绍散布式链路追寻的前世今生及根底概念之后，本文了解了恳求轨道回溯、多维链路挑选场景，接下来的章节咱们将持续介绍：

• 链路实时剖析、监控与告警
• 链路拓扑

更多内容，敬请期待！