前言

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

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

歸納下來(lái)問(wèn)題有以下幾點(diǎn)：

• 并非所有的日志有關(guān)鍵性信息，比如訂單號(hào)和SKU信息，有些日志有，有些日志沒(méi)有，導(dǎo)致有些日志雖然打出了處理步驟日志，但是并不知道是處理哪一個(gè)對(duì)象。

• 日志沒(méi)有統(tǒng)一規(guī)范，導(dǎo)致看起來(lái)非常雜亂無(wú)章

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

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

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

項(xiàng)目特性

受邀請(qǐng)，所以我打算來(lái)分析下這款框架。給大家一個(gè)直觀的理解。

這個(gè)框架叫TLog，項(xiàng)目托管在Gitee上

https://gitee.com/dromara/TLog

主頁(yè)長(zhǎng)這樣，濃濃的一股暗黑系。。。

我使用下來(lái)，直白點(diǎn)的說(shuō)，就是TLog為每一行日志自動(dòng)打了前綴，也就是所謂的標(biāo)簽。標(biāo)簽分為系統(tǒng)級(jí)標(biāo)簽和業(yè)務(wù)型標(biāo)簽，其中業(yè)務(wù)型標(biāo)簽開(kāi)發(fā)者可以自定義。畫了張圖便于理解：

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

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

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

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

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

支持的日志框架

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

實(shí)際測(cè)試中，在這3個(gè)框架中，TLog也都能夠正常打印出標(biāo)簽。只是在接入過(guò)程中，官方給出的接入方式有3種

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

接入方式，按照文檔一步步來(lái)就可以了。

支持的RPC框架

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

實(shí)際測(cè)試中，在Spring cloud這塊，TLog還支持了SpringCloud的Gateway。

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

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

業(yè)務(wù)標(biāo)簽

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

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

只要在方法上加一個(gè)標(biāo)簽，那么這個(gè)方法下面所有的日志，包括之后的N個(gè)層級(jí)，都會(huì)自動(dòng)加上你定義的標(biāo)簽

這個(gè)功能在對(duì)日志的排版和查找上，又能增加很多個(gè)標(biāo)記。這個(gè)很贊！

甚至于自定義標(biāo)簽還支持對(duì)信息的邏輯處理，可以自定義類去處理這些信息

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

這個(gè)具體效果，大家可以去試試。總之一個(gè)標(biāo)簽搞定所有的自定義標(biāo)簽。

其他場(chǎng)景的支持

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

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

tlog.enableInvokeTimePrint=true

出來(lái)的效果如下：

異步線程&線程池的支持

如果你的項(xiàng)目有異步線程，對(duì)于標(biāo)簽傳遞的連貫性，也是自動(dòng)支持的，沒(méi)有任何問(wèn)題。

但是對(duì)于線程池場(chǎng)景，TLog并沒(méi)有原生支持。但是提供了一個(gè)輔助類，需要少量的侵入代碼。這點(diǎn)還有待改善。

MQ支持

同樣的，TLog也考慮到了MQ場(chǎng)景標(biāo)簽的傳遞。這個(gè)也需要少量的侵入代碼。如果你什么都不改，則在MQ場(chǎng)景下無(wú)法支持。

性能

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

測(cè)試代碼非常簡(jiǎn)單:

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

不加TLog

加入TLog

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

從這個(gè)性能測(cè)試也側(cè)面反映了，TLog不會(huì)給系統(tǒng)帶來(lái)額外的開(kāi)銷。這點(diǎn)也贊一下。

總結(jié)

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

有道無(wú)術(shù)，術(shù)可成；有術(shù)無(wú)道，止于術(shù)

歡迎大家關(guān)注Java之道公眾號(hào)

好文章，我在看??

總結(jié)

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

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