前言
最近一個朋友老是和我抱怨：公司系統日誌打得實在是太爛了，有用的資訊很少，沒用的一大堆。就連那有用的資訊，在那麼多節點日誌之間進行追查，也是痛苦的一筆。
我問他，公司沒有日誌收集嗎，日誌收集起來看總好過一個節點一個節點日誌檢視。他表示，公司有接入一個收費第三方的日誌產品，做了收集。但是僅僅是方便了統一化檢視搜尋，但是系統本身的日誌缺少一些關鍵性的要素。比較亂，在很多微服務之間檢視呼叫日誌時定位很難。
歸納下來問題有以下幾點：
並非所有的日誌有關鍵性資訊，比如訂單號和SKU資訊，有些日誌有，有些日誌沒有，導致有些日誌雖然打出了處理步驟日誌，但是並不知道是處理哪一個物件。
日誌沒有統一規範，導致看起來非常雜亂無章
微服務之間同一個請求的呼叫鏈追查更加痛苦，往往只能根據時間戳去搜索，併發小的時候，透過時間戳還能查到，併發一大，查問題的成本太大了。
我給他推薦了一些分散式追蹤框架，skywalking，pinpoint。他看過之後表示，很完善，但是搭建和推行成本有點大。還涉及到儲存成本 ，公司已經購買了第三方的日誌服務。對接起來還是有點麻煩的。恐怕上面不同意這麼折騰。
近段時間，在開源社群看到這麼一款開源框架，號稱是輕量級的日誌追蹤神器，10分鐘接入，於是我推薦了給了朋友。過了幾日，他和我表示這個東西非常貼切他現在的痛點，現在已經上生產，初步效果來看，還是非常滿意的。能給他們的日誌定位減少時間成本。
專案特性
受邀請，所以我打算來分析下這款框架。給大家一個直觀的理解。
這個框架叫TLog，專案託管在Gitee上
gitee.com/dromara/TLo…
主頁長這樣，濃濃的一股暗黑系。。。
我使用下來，直白點地說，就是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
加入TLog
測試結果有點出乎意料，加了TLog後10次平均下來反而比不加要快第一點。但是我推測應該是測試環境和樣本數量太少的問題，並不是說加反而比不加要快。只能說，如果進行100次，1000次測試。2者應該是差不多的。
從這個效能測試也側面反映了，TLog不會給系統帶來額外的開銷。這點也贊一下。
總結
這次評測這款開源框架TLog總體上還算是個日誌框架，但是集成了分散式追蹤，日誌標籤和其他一些小功能還算是一個蠻有特色的Java開源專案，從結構上來說，它非常小巧，而且效能也非常優越。從實用性上來說，它解決了在中小公司快速定位日誌的痛點。缺點是不收集日誌，無法做更有效的日誌挖掘，但是這也是TLog號稱10分鐘接入的原因。從客觀上來分析，這有利也有弊。希望TLog在之後能夠完善這一部分的功能。
作者：鉑賽東
連結：https：//juejin。cn/post/6942404493732495396
