前言

最近一個朋友老是和我抱怨：公司系統(tǒng)日志打的實在是太爛了，有用的信息很少，沒用的一大堆。就連那有用的信息，在那么多節(jié)點日志之間進行追查，也是痛苦的一筆。

我問他，公司沒有日志收集嗎，日志收集起來看總好過一個節(jié)點一個節(jié)點日志查看。他表示，公司有接入一個收費第三方的日志產(chǎn)品，做了收集。但是僅僅是方便了統(tǒng)一化查看搜索，但是系統(tǒng)本身的日志缺少一些關鍵性的要素。比較亂，在很多微服務之間查看調(diào)用日志時定位很難。

歸納下來問題有以下幾點：

• 并非所有的日志有關鍵性信息，比如訂單號和SKU信息，有些日志有，有些日志沒有，導致有些日志雖然打出了處理步驟日志，但是并不知道是處理哪一個對象。

• 日志沒有統(tǒng)一規(guī)范，導致看起來非常雜亂無章

• 微服務之間同一個請求的調(diào)用鏈追查更加痛苦，往往只能根據(jù)時間戳去搜索，并發(fā)小的時候，通過時間戳還能查到，并發(fā)一大，查問題的成本太大了。

我給他推薦了一些分布式追蹤框架，skywalking，pinpoint。他看過之后表示，很完善，但是搭建和推行成本有點大。還涉及到存儲成本 ，公司已經(jīng)購買了第三方的日志服務。對接起來還是有點麻煩的。恐怕上面不同意這么折騰。

近段時間，在開源社區(qū)看到這么一款開源框架，號稱是輕量級的日志追蹤神器，10分鐘接入，于是我推薦了給了朋友。過了幾日，他和我表示這個東西非常貼切他現(xiàn)在的痛點，現(xiàn)在已經(jīng)上生產(chǎn)，初步效果來看，還是非常滿意的。能給他們的日志定位減少時間成本。

項目特性

受邀請，所以我打算來分析下這款框架。給大家一個直觀的理解。

這個框架叫TLog，項目托管在Gitee上

https://gitee.com/dromara/TLog

主頁長這樣，濃濃的一股暗黑系。。。

我使用下來，直白點的說，就是TLog為每一行日志自動打了前綴，也就是所謂的標簽。標簽分為系統(tǒng)級標簽和業(yè)務型標簽，其中業(yè)務型標簽開發(fā)者可以自定義。畫了張圖便于理解：

TLog最終呈現(xiàn)的每行日志，就如同上圖所示。其中系統(tǒng)日志，能夠展現(xiàn)的信息目前有5個，上游信息能夠讓你知道是誰調(diào)用了你的系統(tǒng)，鏈路TraceId則是跨微服務的全局鏈路唯一ID，搜索一個Id，就能得到所有系統(tǒng)中同一請求的日志。這個還是很香的！

關于SpanId，官網(wǎng)的解釋是，這是一個代表本次調(diào)用在整個調(diào)用鏈路樹中的位置，具體演示借用下官網(wǎng)的圖，解釋的還算清晰：

個人對SpanId的理解是，這個東西可以讓你知道系統(tǒng)在某一個調(diào)用鏈中的層級，如果加以收集，可以通過spanId生成一棵調(diào)用鏈路樹。其實很希望TLog能實現(xiàn)這個樹的展示，可惜現(xiàn)在還不支持。

“TLog的定位是提供了一種最簡單的方式來解決日志追蹤問題，它不收集日志，也不需要另外的存儲空間，它只是自動的對你的業(yè)務日志進行打標簽，自動生成TraceId貫穿你微服務的一整條鏈路。并且提供上下游節(jié)點信息。適合中小型企業(yè)以及想快速解決日志追蹤問題的公司項目使用。“

這是官網(wǎng)的贅述，事實上我在測試的時候，TLog所提供的日志就是日志本身，在多節(jié)點微服務當中，日志還是分散的。只是在邏輯上給日志進行一定程度的串聯(lián)。但是同時，TLog文檔也建議說，利用其它的方案去做日志收集。比如ELK，阿里云日志，其它收費的日志產(chǎn)品等等。TLog只是修改日志，并不生成新的日志。所以對接其它日志收集方案，也是完全沒有任何問題的，對于已經(jīng)對接日志收集方案的公司來說，也完全不需要修改什么。

支持的日志框架

每個公司所用的日志框架形形色色。TLog宣稱支持了主流的三大日志框架：log4j，log4j2，logback

實際測試中，在這3個框架中，TLog也都能夠正常打印出標簽。只是在接入過程中，官方給出的接入方式有3種

測試下來，javaagent的方式對于有些項目的確不太穩(wěn)定，有些復雜的項目會出現(xiàn)無效的情況。對于宣稱最穩(wěn)定的日志適配方式，測試了一下公司的項目，的確能順利接入。

接入方式，按照文檔一步步來就可以了。

支持的RPC框架

既然是跨微服務進行日志追蹤，在實現(xiàn)方面也要對常用的RPC進行支持。TLog支持了Dubbo，SpringCloud，Dubbox三種常用的RPC，這點還是不錯的。

實際測試中，在Spring cloud這塊，TLog還支持了SpringCloud的Gateway。

在接入過程中，無論是哪種RPC框架，在springboot環(huán)境下TLog也能自動適配，引入一個就能自動裝配。無需額外的配置。這點很方便。

但是在原生spring環(huán)境下(非springboot)，還是需要xml的額外配置的，但是也相對簡單，文檔也有專門的說明。

業(yè)務標簽

除了系統(tǒng)給予的標簽外，我發(fā)現(xiàn)TLog另一大特點就是允許開發(fā)者自定義標簽。接入也很簡單，舉個例子：

@TLogAspect({"str","user.name","user.userDetail.company","user.dddd"})public?void?test(String?str,?User?user){log.info("這是自定義表達標簽");log.info("這是業(yè)務日志1");log.info("這是業(yè)務日志2");log.info("這是業(yè)務日志3");log.info("這是業(yè)務日志4");log.info("這是業(yè)務日志5");}

只要在方法上加一個標簽，那么這個方法下面所有的日志，包括之后的N個層級，都會自動加上你定義的標簽

這個功能在對日志的排版和查找上，又能增加很多個標記。這個很贊！

甚至于自定義標簽還支持對信息的邏輯處理，可以自定義類去處理這些信息

@TLogAspect(convert?=?CustomAspectLogConvert.class) public?void?demo(Person?person){log.info("自定義Convert示例"); }

這個具體效果，大家可以去試試。總之一個標簽搞定所有的自定義標簽。

其他場景的支持

參數(shù)&耗時打印支持：

引入了TLog之后，發(fā)現(xiàn)TLog還附帶了無論在哪種框架之下每個方法的參數(shù)打印和耗時，默認為關閉，需要的只需要配置下就可以了：

tlog.enableInvokeTimePrint=true

出來的效果如下：

異步線程&線程池的支持

如果你的項目有異步線程，對于標簽傳遞的連貫性，也是自動支持的，沒有任何問題。

但是對于線程池場景，TLog并沒有原生支持。但是提供了一個輔助類，需要少量的侵入代碼。這點還有待改善。

MQ支持

同樣的，TLog也考慮到了MQ場景標簽的傳遞。這個也需要少量的侵入代碼。如果你什么都不改，則在MQ場景下無法支持。

性能

對于性能，我對TLog進行了簡單的測試，只在log4j2的環(huán)境下進行了測試，測試條件是同步打印出幾w條日志，在原生環(huán)境下的耗時和加入TLog框架之后的耗時對比，每組分別測10次，取平均值

測試代碼非常簡單:

StopWatch?stopWatch?=?new?StopWatch(); stopWatch.start(); for?(int?i?=?0;?i?<?100;?i++)?{log.info("test?log?{}",?i+1); } stopWatch.stop(); log.info("耗時:{}",stopWatch.getTotalTimeSeconds());

不加TLog

加入TLog

測試結果有點出乎意料，加了TLog后10次平均下來反而比不加要快第一點。但是我推測應該是測試環(huán)境和樣本數(shù)量太少的問題，并不是說加反而比不加要快。只能說，如果進行100次，1000次測試。2者應該是差不多的。

從這個性能測試也側面反映了，TLog不會給系統(tǒng)帶來額外的開銷。這點也贊一下。

總結

這次評測這款開源框架TLog總體上還算是個日志框架，但是集成了分布式追蹤，日志標簽和其他一些小功能還算是一個蠻有特色的Java開源項目，從結構上來說，它非常小巧，而且性能也非常優(yōu)越。從實用性上來說，它解決了在中小公司快速定位日志的痛點。缺點是不收集日志，無法做更有效的日志挖掘，但是這也是TLog號稱10分鐘接入的原因。從客觀上來分析，這有利也有弊。希望TLog在之后能夠完善這一部分的功能。

有道無術，術可成；有術無道，止于術

歡迎大家關注Java之道公眾號

好文章，我在看??

總結

以上是生活随笔為你收集整理的对乱糟糟的日志说再见的全部內(nèi)容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。