共计 2801 个字符，预计需要花费 8 分钟才能阅读完成。
简介：有了这款工具，定位线上问题事倍功半，程序员在日常工作中常常会遇到一些线上问题须要排查，本文的主人公程序员小张也不例外。但排查的过程却时常令他困扰不已。让咱们一起看看他遇到了哪些问题，又是怎么解决的。
大家好，我叫刘玄，负责云效流水线的开发。程序员在日常工作中常常会遇到一些线上问题须要排查，本文的主人公程序员小张也不例外。但排查的过程却时常令他困扰不已。让咱们一起看看他遇到了哪些问题，又是怎么解决的。
焦头烂额的一天
那是一个阳光明媚的上午，小张来到工位，关上电脑，备上咖啡，精力满满的开始了一天的工作。正在小张噼里啪啦的敲着键盘，认真 Coding 之时，钉钉群里的一个钉，突破了平静。客服人员反馈，有客户遇到了一个问题，须要开发人员排查。小张排查了线上日志，发现用户的申请比拟多，日志也比拟多，没有定位到要害信息。小张只能又让客服找用户提供更具体的信息。在和用户重复进行沟通之后，小张最终花了半个多小时才定位到了问题。
繁忙的一天很快完结，正当小张筹备上班，策划着上班之后怎么 happy 时，电话报警的声音，又把他拉回了事实。小张收到后端服务 RT 高的告警后，连忙排查多个后盾利用的监控信息和日志。尽管很快从 Nginx 日志定位到了有问题的申请信息，但小张很难准确的找到这个申请对应的利用日志，所以破费了很长时间才定位到问题：一个第三方服务异样，导致局部性能受影响。定位到起因后，及时采取了降级伎俩，零碎恢复正常。
寻求解决问题的计划
过完了焦头烂额的一天，小张感觉当初解决问题的效率太低，大把的工夫花在了问题定位上。而之所以排查的这么慢，是因为零碎采纳微服务架构，一个申请会波及到多个服务，并且每个服务还会调用 DB、缓存以及其余第三方服务。大抵链路如下：
小张想，应该有成熟的技术计划，可能标识整个申请链路，将异样服务节点清晰标注。小张借助搜寻工具，发现有一种解决方案，链路追踪，刚好适宜本人的场景。
链路追踪工具能够将一次分布式申请还原成残缺的调用链路，将整个申请的调用状况进行展现，比方各个服务上的耗时、各个服务的申请状态、具体调度到各个服务的哪台机器上等信息。
革新零碎
冀望的成果
依据后面遇到的两个问题，小张冀望：
- 用户申请遇到问题时候，能够获取到一个 traceId，只有提供了这个 traceId，就能够看到这个申请在各个服务之间的调用门路。并且能够通过这个 traceId 查到所有利用中相干的日志。
- 当收到 RT 告警时，也可能从 Nginx 的日志中找到这个 traceId。
接入链路追踪
通过技术选型，小张抉择阿里云的产品链路追踪 Tracing Analysis 作为本人链路追踪的服务端。
阿里云链路追踪 Tracing Analysis 提供了残缺的调用链路还原、调用申请量统计、链路拓扑、利用依赖剖析等工具，能够帮忙用户疾速剖析和诊断分布式应用架构下的性能瓶颈，进步微服务时代下的开发诊断效率。
阿里云链路追踪 Tracing Analysis 反对多种常见的链路追踪工具，例如 Zipkin、Skywalking、Jaeper 等。小张抉择应用 Skywalking 作为链路追踪数据埋点。
在阿里云上开明完链路追踪 Tracing Analysis 产品之后，就能够在集群配置中获取到 Skywalking 的接入点。更具体的接入指南参考阿里云官网文档。
因为小张的零碎是基于 spring boot，所以只须要在启动命令中退出以下内容即可。
重新启动利用后，链路追踪埋点数据就会收集到链路追踪 Tracing Analysis 上了。
日志中打印 traceId
为了可能通过 traceId 搜寻到所有的日志，也须要在的利用的日志中展现 traceId 信息，具体形式如下：
在利用中引入以下依赖：
批改 logback 配置文件，例如：tid 即为 Skywalking 的 traceId。
以上改变就能够在日志中看到 traceId 了。如下图所示：图中标红的 TID 值即为 traceId。
同时小张也在零碎出现异常信息时，将 traceId 透出给用户，用户反馈问题时只须要提供 traceId 即可。相应的，须要在代码中把 traceId 写入到响应体中，如下所示：
Nginx 日志中打印 traceId
为了在收到零碎 RT 告警时，也能够取得 traceId，须要批改 Nginx 配置。
接入 Skywalking 之后，零碎间调用的申请都会带上名称为 sw6 的 header (其中 6 为对应的 Skywalking 版本号)，Header 值的的格局为：1-TRACEID-SEGMENTID-3-PARENT_SERVICE-PARENT_INSTANCE-PARENT_ENDPOINT-IPPORT 从这个值中提取出 TRACEID，也就是第一个和第二个横杠之间的局部，再进行 BASE64 decode 就能够获取到 traceId。
而后须要在 Nginx 的 log_format 配置增加对应的 Header，如下如下：
而后就能够在 Nginx 日志中看到了相应的值了，如图：
解决链路追踪多线程失落 traceId 的问题
小张在测试链路追踪时，发现在多线程的应用场景中，只有一个子线程可能正确获取到 traceId，而其它线程中的 traceId 会呈现失落。为了解决上述问题，小张应用 @TraceCrossThread 注解对 Callable 和 Runnable 进行加强，@TraceCrossThread 为 Skywalking 提供的注解,Skywalking 通过加强被此注解正文的类，以此来实现 traceId 的跨线程传递。示例代码如下。
后续提交线程工作时应用革新后的 TraceableCallable 和 TraceableRunnable 即可解决多线程失落 traceId 的问题。
实现以上革新后，以下图为例，用户每一次的申请都会有对应的 traceId，便于将整个申请链路展现进去。
轻松应答线上问题
又一个阳光明媚的早上，小张埋头工作时，又有客服反馈用户问题，这个时候小张镇定自若的依据用户提供 traceId，在阿里链路追踪 https://tracing.console.aliyu… 上查看调用链路，很快定位到异样节点，示例如下：图中状态为红色的节点就是异样节点，图中示例示意因为某个 sql 执行出现异常。
轻松应答一天工作后，小张在上班前又收到利用 RT 过高的告警，因为 Nginx 日志中打印了 traceId 信息，很快就能够定位到耗时的申请，示例如下：
图中耗时比拟长的节点，是因为调用第三方服务造成，小张依据状况，对服务进行降级，很快就解决 RT 过高的问题，避免问题扩散。
接入了链路追踪当前，小张在定位线上问题的耗时大大缩短，能够有更多的工夫专一其余工作。
以上就是小张是如何通过应用链路追踪从焦头烂额的排查线上问题到从容定位线上问题的转变，心愿对仍未应用链路追踪技术的同学有些帮忙。本故事纯属虚构，如有雷同，纯属巧合。
原文链接
本文为阿里云原创内容，未经容许不得转载。