背景

隨著微服務盛行，很多公司都把系統按照業務邊界拆成了很多微服務，在排錯查日志的時候，因為業務鏈路貫穿著很多微服務節點，導致定位某個請求的日志以及上下游業務的日志會變得有些困難。

這時候可能有的小伙伴就會想到使用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的消費者和提供者之間的傳遞。

2.2 對OpenFeign的支持

對于OpenFeign的支持其實也是通過Feign提供的擴展點RequestInterceptor來實現的

發送請求之前，從TLogContext獲取到traceId，將traceId等信息添加到請求頭中，然后就可以通過Http請求將traceId等信息傳遞。

當被調用方接收到請求之后，會經過TLogWebInterceptor這個攔截器進行攔截，從請求頭中獲取到這些參數，設置到TLogContext中。

3、對常用Http框架的支持

除了一些RPC框架，TLog也對一些Http框架進行了適配，比如

• HttpClient
• Okhttp
• hutool-http
• RestTemplate
• forest

使用這些Http框架也可以實現traceId的傳遞

其實這些框架的適配跟Feign的適配都是大同小異，都是基于這些Http框架各自提供的擴展點進行適配的，將traceId等信息放到請求頭中，這里都不舉例了，具體的使用方法可以在官網查看。

4、對SpringCloud Gateway的支持

同樣的，TLog也適配了SpringCloud Gateway

原理也是一樣的，就是適配了Gateway的GlobalFilter，從請求頭中獲取traceId等信息。

除了適配了Gateway網關，TLog也適配了Soul網關。

5、對MQ的支持

對于MQ的支持跟異步線程差不多，需要將你發送的消息包裝成TLogMqWrapBean對象

TLogMqWrapBean

發送的時候直接發送TLogMqWrapBean對象過去

TLogMqWrapBean<BizBean> tLogMqWrap = new TLogMqWrapBean(bizBean);
mqClient.send(tLogMqWrap);

TLogMqWrapBean會將traceId等信息攜帶，消費者接受到TLogMqWrapBean，然后通過TLogMqConsumerProcessor處理業務消息。

TLogMqConsumerProcessor.process(tLogMqWrapBean, new TLogMqRunner<BizBean>() {
    @Override
    public void mqConsume(BizBean o){
     //業務操作
    }
});

如此就實現了traceId通過MQ傳遞。

在實際使用中，根據不同的MQ的類型，可以將消息包裝成TLogMqWrapBean對象的過程和處理消息的過程做統一的封裝處理，以減少發送消息和處理消息對于TLog的耦合。

6、對任務框架的支持

TLog主要是支持一下四種任務框架

• JDK Timer
• Quartz框架
• spring-scheduled
• XXL-JOB框架

其中，spring-scheduled和XXL-JOB在SpringBoot環境底下是無需任務配置的，只需要引入依賴即可。

Timer在使用的時候需要將任務包裝成TLogTimerTask，Quartz需要把QuartzJobBean替換成TLogQuartzJobBean就可以了。

小總結

其實從上面的各種適配可以看出，其實本質都是一樣的，就是根據具體框架的擴展點，在發送請求之前從TLogContext獲取到traceId，將traceId等調用者的信息在請求中攜帶，然后被調用方解析請求，取出traceId和調用者信息，設置到被調用方服務中的TLogContext中。

所以，如果一旦需要遇到官方還未適配的框架或者組件，可以參照上述適配過程進行適配即可。

最后

總的來說，TLog是一款非常優秀的日志追蹤的框架，很適合中小公司使用。這里來總結一下TLog的特性

• 通過對日志打標簽完成輕量級微服務日志追蹤
• 提供三種接入方式：javaagent完全無侵入接入，字節碼一行代碼接入，基于配置文件的接入
• 對業務代碼無侵入式設計，使用簡單，10分鐘即可接入
• 支持常見的log4j，log4j2，logback三大日志框架，并提供自動檢測，完成適配
• 支持dubbo，dubbox，feign三大RPC框架
• 支持Spring Cloud Gateway和Soul網關
• 支持HttpClient和Okhttp等http調用框架標簽傳遞
• 支持多種任務框架，JDK的TimerTask，Quartz，XXL-JOB，spring-scheduled
• 支持日志標簽的自定義模板的配置，提供多個系統級埋點標簽的選擇
• 支持異步線程的追蹤，包括線程池，多級異步線程等場景
• 幾乎無性能損耗，快速穩定，經過壓測，損耗在0.01%

由于本文篇幅有限，無法全面對TLog進行講解，如果想深入了解該框架，可自行閱讀官網或者源碼。