项目中引入这玩意，排查日志又快又准！_zzyang90

大家好，我是三友~~

背景

随着微服务盛行，很多公司都把系统按照业务边界拆成了很多微服务，在排错查日志的时候，因为业务链路贯穿着很多微服务节点，导致定位某个请求的日志以及上下游业务的日志会变得有些困难。

这时候可能有的小伙伴就会想到使用SkyWalking，Pinpoint等分布式追踪系统来解决，并且这些系统通常都是无侵入性的，同时也会提供相对友好的管理界面来进行链路Span的查询，但是搭建分布式追踪系统还是需要一定的成本的，所以本文要说的并不是这些分布式追踪系统，而是一款简单、易用、几乎零侵入、适合中小型公司使用的日志追踪框架TLog。

TLog简介

TLog提供了一种最简单的方式来解决日志追踪问题，TLog会自动的对你的日志进行打标签，帮你自动生成traceId贯穿你微服务的一整条链路，在排查日志的时候，可以根据traceId来快速定位请求处理的链路。

TLog不收集日志，只在对你原来打印的日志上增强，将请求链路信息traceId绑定到你打印的日志上。当出现微服务中那么多节点的情况，官方推荐使用TLog+日志收集方案来解决。当然分布式追踪系统其实是链路追踪一个最终的解决方案，如果项目中已经上了分布式追踪系统，那TLog并不适用。

如下图，是ELK配合TLog，快速定位请求处理的链路的示例。

TLog接入

1、接入步骤

1.1、引入依赖

<dependency> <groupId>com.yomahub</groupId> <artifactId>tlog-all-spring-boot-starter</artifactId> <version>1.5.0</version> </dependency>

1.2、替换logback配置项

到这其实就已经完成了配置。

1.3、测试

这里是通过slf4j的LoggerFactory获取Logger对象，因为logback适配了slf4j，最终会通过logback来输出日志。

从这可以看出，11794076298070144 就是本次日志输出的时候生成的一个请求的traceId，在排查日志的时候就可以通过这个traceId去搜索出整个请求的链路日志。

2、TLog接入方式

TLog总共提供了三种方式接入项目

Javaagent接入方式
字节码注入方式
日志框架适配器方式

上面案例的接入方式其实是属于日志框架适配器方式，并且是对于Logback框架的适配。TLog除了适配了Logback框架，还适配了Log4j框架和Log4j2框架，项目中可自行选择。

Javaagent接入方式和字节码注入方式相比与日志框架适配器方式对代码的入侵性更小，但是这两种方式仅仅只支持SpringBoot项目，并且相较于日志框架适配器的方式，MDC和异步日志功能并不支持，所以要想完整体验TLog的功能，还是建议选择日志框架适配器方式，日志框架适配器方式其实接入也很快，其实也就是修改一下配置文件的事。

项目环境兼容对比

特性支持对比

TLog的基本原理

1、日志标签

前面在介绍TLog的时候，提到TLog会自动的对你的日志进行打标签，这个标签就是日志标签，一个日志标签最多可以包含如下信息：

preApp：接口调用方服务名
preHost：接口调用方Host
preIp：接口调用方ip
currIp：当前服务ip
traceId：链路id，调用方如果传递就是传递的值，不传递就会重新生成
spanId：链路spanId

默认是按照如下labelPattern进行数据拼接生成日志标签，所以默认只打出spanId和traceId。

这也就是上面为什么示例中会输出 <0><11794076298070144> 这种格式的原因，前面的0其实就是spanId。

如果你想改变日志标签输出其它信息或者输出的顺序，只需要在SpringBoot配置文件中配置日志标签的生成样式就行。

tlog.pattern=[$preApp][$preIp][$spanId][$traceId]

2、TLogContext

TLogContext是TLog是一个核心的组件，这个组件内部是使用了TransmittableThreadLocal来传递traceId、preApp等信息。

当有一个请求过来的时候，会从解析出traceId、preApp等信息，然后设置到TransmittableThreadLocal中，之后就可以在整个调用链路中从TLogContext中获取到traceId等信息。

3、TLogRPCHandler

这个组件是用来处理调用方传递的traceId、preApp等信息，设置到TLogContext和MDC中，同时根据日志标签的格式生成日志标签。

第三方框架的适配

在实际项目中，一个请求处理过程可能会出现以下情况

异步线程处理
跨服务调用
MQ调用

那么对于这些情况来说，traceId应该需要在异步线程、跨服务、MQ等中传递，以便更好地排查一个请求的处理链路。

而TLog对于以上可能出现的情况都做了大量的适配，保证traceId能够在异步线程、微服务间、MQ等中能够正确传递。

1、异步线程

1.1 一般异步线程

所谓的一般异步线程就是指直接通过new Thread的方法来创建异步线程，然后来执行，这种方式TLog是天然支持携带traceId的，如图。

执行结果

从这可以看出这种异步方式的确成功传递了traceId。

1.2 线程池

对于线程池来说，其实默认也是支持传递traceId，但是由于线程池中的线程是可以复用了，为了保证线程间的数据互不干扰，需要使用TLogInheritableTask将提交的任务进行包装。

ThreadPoolExecutor pool = new ThreadPoolExecutor(1, 2, 1, TimeUnit.SECONDS, new LinkedBlockingQueue<>(10)); pool.execute(new TLogInheritableTask() { @Override public void runTask() { logger.info("异步执行"); } });

上述代码的写法会有点耦合，每次提交任务都需要创建一个TLogInheritableTask，比较麻烦，可以按如下写法进行简化。

TLogThreadPoolExecutor

自己写个TLogThreadPoolExecutor继承ThreadPoolExecutor，重写execute方法(submit最终也会调用execute方法执行)，然后将提交的任务统一包装成TLogInheritableTask，这样需要使用线程池的地方直接创建TLogThreadPoolExecutor就可以了，就不需要在提交任务的时候创建TLogInheritableTask了。

ThreadPoolExecutor pool = new TLogThreadPoolExecutor(1, 2, 1, TimeUnit.SECONDS, new LinkedBlockingQueue<>(10)); pool.execute(() -> logger.info("异步执行"));

2、对RPC框架的支持

除了对异步线程的支持，TLog也支持常见的Dubbo，Dubbox，OpenFeign三大RPC框架，在SpringBoot项目中不需要任何配置，只需要引入依赖就可以实现traceId在服务之间的传递

2.1 对Dubbo和Dubbox的支持

对于Dubbo和Dubbox的支持是基于Dubbo的Filter扩展点来的

TLog通过SPI机制扩展Filter，在消费者发送请求前从TLogContext获取到traceId，然后将traceId和其它调用者数据设置请求数据中，服务提供者在处理请求的时候，也会经过Filter，从请求中获取到traceId等信息，然后设置到TLogContext中，从而实现了traceId在dubbo的消费者和提供者之间的传递。