對亂糟糟的日誌說再見

鉑賽東發表於2021-03-25

前言

最近一個朋友老是和我抱怨：公司系統日誌打的實在是太爛了，有用的資訊很少，沒用的一大堆。就連那有用的資訊，在那麼多節點日誌之間進行追查，也是痛苦的一筆。

我問他，公司沒有日誌收集嗎，日誌收集起來看總好過一個節點一個節點日誌檢視。他表示，公司有接入一個收費第三方的日誌產品，做了收集。但是僅僅是方便了統一化檢視搜尋，但是系統本身的日誌缺少一些關鍵性的要素。比較亂，在很多微服務之間檢視呼叫日誌時定位很難。

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

  • 並非所有的日誌有關鍵性資訊，比如訂單號和SKU資訊，有些日誌有，有些日誌沒有，導致有些日誌雖然打出了處理步驟日誌，但是並不知道是處理哪一個物件。
  • 日誌沒有統一規範，導致看起來非常雜亂無章
  • 微服務之間同一個請求的呼叫鏈追查更加痛苦，往往只能根據時間戳去搜尋，併發小的時候，通過時間戳還能查到，併發一大，查問題的成本太大了。

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

近段時間，在開源社群看到這麼一款開源框架，號稱是輕量級的日誌追蹤神器，10分鐘接入，於是我推薦了給了朋友。過了幾日，他和我表示這個東西非常貼切他現在的痛點，現在已經上生產，初步效果來看，還是非常滿意的。能給他們的日誌定位減少時間成本。

1

專案特性

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

這個框架叫TLog，專案託管在Gitee上

https://gitee.com/dromara/TLog

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

2

我使用下來，直白點的說，就是TLog為每一行日誌自動打了字首，也就是所謂的標籤。標籤分為系統級標籤和業務型標籤，其中業務型標籤開發者可以自定義。畫了張圖便於理解：

3

TLog最終呈現的每行日誌，就如同上圖所示。其中系統日誌，能夠展現的資訊目前有5個，上游資訊能夠讓你知道是誰呼叫了你的系統，鏈路TraceId則是跨微服務的全域性鏈路唯一ID，搜尋一個Id，就能得到所有系統中同一請求的日誌。這個還是很香的！

關於SpanId，官網的解釋是，這是一個代表本次呼叫在整個呼叫鏈路樹中的位置，具體演示借用下官網的圖，解釋的還算清晰：

4

個人對SpanId的理解是，這個東西可以讓你知道系統在某一個呼叫鏈中的層級，如果加以收集，可以通過spanId生成一棵呼叫鏈路樹。其實很希望TLog能實現這個樹的展示，可惜現在還不支援。

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

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

支援的日誌框架

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

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

5

測試下來，javaagent的方式對於有些專案的確不太穩定，有些複雜的專案會出現無效的情況。對於宣稱最穩定的日誌適配方式，測試了一下公司的專案，的確能順利接入。

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

支援的RPC框架

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

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

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

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

業務標籤

除了系統給予的標籤外，我發現TLog另一大特點就是允許開發者自定義標籤。接入也很簡單，舉個例子：

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

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

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

7

甚至於自定義標籤還支援對資訊的邏輯處理，可以自定義類去處理這些資訊

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

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

其他場景的支援

引數&耗時列印支援：

引入了TLog之後，發現TLog還附帶了無論在哪種框架之下每個方法的引數列印和耗時，預設為關閉，需要的只需要配置下就可以了：

tlog.enableInvokeTimePrint=true

出來的效果如下：

6

非同步執行緒&執行緒池的支援

如果你的專案有非同步執行緒，對於標籤傳遞的連貫性，也是自動支援的，沒有任何問題。

但是對於執行緒池場景，TLog並沒有原生支援。但是提供了一個輔助類，需要少量的侵入程式碼。這點還有待改善。

MQ支援

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

效能

對於效能，我對TLog進行了簡單的測試，只在log4j2的環境下進行了測試，測試條件是同步列印出幾w條日誌，在原生環境下的耗時和加入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

列印5w條日誌(秒) 列印10w條日誌(秒)
第1次 6.496249974 15.595447718
第2次 6.185712521 14.295489162
第3次 6.116123718 13.559289437
第4次 6.205771261 12.782565374
第5次 6.727208117 12.884360048
第6次 5.908489157 14.604699842
第7次 6.153151066 13.700609245
第8次 6.603960836 13.048889457
第9次 6.139718196 12.584335736
第10次 6.365920588 12.85222910
平均 6.29 13.60

加入TLog

列印5w條日誌(秒) 列印10w條日誌(秒)
第1次 5.997981416 12.878389572
第2次 6.154590093 14.268328625
第3次 6.228010581 12.385200456
第4次 6.452949788 15.542794904
第5次 6.156225995 12.350440713
第6次 6.121611887 12.543883453
第7次 6.18131273 12.192140225
第8次 6.238254682 12.159684042
第9次 6.403632588 12.308115127
第10次 5.954781153 12.321667925
平均 6.19 12.89

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

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

總結

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

關於我

我是一個開源作者，也是一名內容創作者。「元人部落」是一個堅持做原創的技術科技分享號，會一直分享原創的技術文章，陪你一起成長。

wx

相關文章