乐趣区

关于阿里云:使用篇丨链路追踪Tracing其实很简单请求轨迹回溯与多维链路筛选

jiezi

作者：涯海

在日常生活中，咱们可能都经验过以下场景：去医院看病就诊，但预约页面迟迟无奈关上；新款手机公布日促销秒杀，下单页面始终卡住转菊花；游戏大版本更新，在线人数过多，导致人物始终在“漂移”。这些问题令产品体验变得十分差，有急躁的同学还会吐槽几句，没急躁的同学早已转身来到。试想一下，作为该零碎开发 / 运维人员，又该如何防止此类问题产生，或者疾速定位止损？

要害门路与多条链路比照

本章咱们将以业务 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>
  1. 在日志输入代码后面，先获取以后调用生命周期的 Span 对象，再从上下文中获取 TraceId 标识。
String traceId = GlobalTracer.get().activeSpan().context().toTraceId();
  1. 将 TraceId 增加到业务日志中一并输入。
log.error("fail to create order, traceId: {}", traceId);
  1. 最终的日志成果如下所示，这样咱们就能够依据业务关键词先过滤日志，再通过关联的 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 在线诊断等工具进行二次剖析。

预报

在残缺介绍分布式链路追踪的前世今生及根底概念之后，本文理解了申请轨迹回溯、多维链路筛选场景，接下来的章节咱们将持续介绍：

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

更多内容，敬请期待！

退出移动版