對亂糟糟的日誌說再見

前言

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

我問他，公司沒有日誌收集嗎，日誌收集起來看總好過一個節點一個節點日誌查看。他表示，公司有接入一個收費第三方的日誌產品，作了收集。可是僅僅是方便了統一化查看搜索，可是系統自己的日誌缺乏一些關鍵性的要素。比較亂，在不少微服務之間查看調用日誌時定位很難。

概括下來問題有如下幾點：

• 並不是全部的日誌有關鍵性信息，好比訂單號和SKU信息，有些日誌有，有些日誌沒有，致使有些日誌雖然打出了處理步驟日誌，可是並不知道是處理哪個對象。
• 日誌沒有統一規範，致使看起來很是雜亂無章
• 微服務之間同一個請求的調用鏈追查更加痛苦，每每只能根據時間戳去搜索，併發小的時候，經過時間戳還能查到，併發一大，查問題的成本太大了。

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

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

項目特性

受邀請，因此我打算來分析下這款框架。給你們一個直觀的理解。

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

https://gitee.com/dromara/TLog

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

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

TLog最終呈現的每行日誌，就如同上圖所示。其中系統日誌，可以展示的信息目前有5個，上游信息可以讓你知道是誰調用了你的系統，鏈路TraceId則是跨微服務的全局鏈路惟一ID，搜索一個Id，就能獲得全部系統中同一請求的日誌。這個仍是很香的！

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

我的對SpanId的理解是，這個東西可讓你知道系統在某一個調用鏈中的層級，若是加以收集，能夠經過spanId生成一棵調用鏈路樹。其實很但願TLog能實現這個樹的展現，惋惜如今還不支持。

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

這是官網的贅述，事實上我在測試的時候，TLog所提供的日誌就是日誌自己，在多節點微服務當中，日誌仍是分散的。只是在邏輯上給日誌進行必定程度的串聯。可是同時，TLog文檔也建議說，利用其它的方案去作日誌收集。好比ELK，阿里雲日誌，其它收費的日誌產品等等。TLog只是修改日誌，並不生成新的日誌。因此對接其它日誌收集方案，也是徹底沒有任何問題的，對於已經對接日誌收集方案的公司來講，也徹底不須要修改什麼。

支持的日誌框架

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

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

測試下來，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個層級，都會自動加上你定義的標籤

這個功能在對日誌的排版和查找上，又能增長不少個標記。這個很贊！

甚至於自定義標籤還支持對信息的邏輯處理，能夠自定義類去處理這些信息

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

這個具體效果，你們能夠去試試。總之一個標籤搞定全部的自定義標籤。

其餘場景的支持

參數&耗時打印支持：

引入了TLog以後，發現TLog還附帶了不管在哪一種框架之下每一個方法的參數打印和耗時，默認爲關閉，須要的只須要配置下就能夠了：

tlog.enableInvokeTimePrint=true

出來的效果以下：

異步線程&線程池的支持

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

可是對於線程池場景，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在以後可以完善這一部分的功能。

關於我

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