自從團隊自研全鏈路日誌系統上線後，一直想分享一下本人對日誌系統的一些感受與心得，今天正好是周未，仔細回想了一下有關日誌的點滴，因爲涉及到全鏈路日誌的概念，由於我打算從非全鏈路日誌（普通）到全鏈路的演化路線做一次分析，就打日誌關係的一次業務問題做一些簡單的案例剖析。請搬個小凳子，開場了。
非鏈路日誌（普通日誌）
如果沒有鏈路的概念，那恭喜，您正在使用普通的日誌。普通的日誌沒有鏈路標識，不同請求的日誌可能穿插在一起，查看的時候不太好串起來，分析日誌有點點眼花繚亂。尤其是出現線上問題的時候，面對一團無序的日誌，心急如焚。如果站點業務機有10臺，定位日誌的範圍，也成爲一個不太愉快的時候。若是多線程的服務日誌，日誌穿插得眼花繚亂。非鏈路日誌（普通日誌）在實時排查問題的過程中，存在的最大問題就是定位分析問題，簡單的示例如下圖，日誌穿插在一起，不易分析同一個請求的情況。
我收到一個請求，參數是
我收到一個請求，參數是
我收到一個請求，參數是
我收到一個請求，參數是
我收到一個請求，參數是
用戶賬號BBB未認證
單鏈路日誌
當我看到有同事使用GUID將日誌請求串在一起的時候，我就這應該算是單鏈路日誌了。站點的單次請求或服務的業務操作日誌能夠很好的被標識出來，在分析日誌的時候，需要搜索同GUID的日誌，請能定位到一個請求或作業的日誌，不用提心其他日誌的干擾。單鏈路日誌對於分析單個站點或單個服務的日誌情況，還是很有幫忙。我們已經能從日誌中挑出日誌，專注於重點日誌。
請求3fba452e-d9c9-45ee-96cb-19280fa59673 我收到一個請求，參數是
請求b3a45dec-7667-4822-b7b9-7db1eec11a8b 我收到一個請求，參數是
請求3e2f3851-9491-4f97-a47c-53d1001278ba 我收到一個請求，參數是
請求6180a2f7-d9bf-4612-9d23-c5e6d46a079d 我收到一個請求，參數是
請求26a9d771-f2f3-47fa-b810-d3071a1d98ca 我收到一個請求，參數是
請求3fba452e-d9c9-45ee-96cb-19280fa59673 用戶賬號BBB未認證
全鏈路日誌
全鏈路日誌在單鏈路日誌的基礎上進行跨站點，跨服務邏輯的日誌追蹤。分我們排查問題的時候，往往是一個完整業務排查，不單是涉及一個站點的，可能需要順藤摸瓜，一點一點回溯。單鏈路日誌 對此就無能爲力了。所以引身出了全鏈路日誌，我們需要爲每個完整的請求分配一個追蹤id，稱之爲TraceId，這個追蹤id將在業務站點間流轉，將業務日誌串起來。當我們查看日誌的時候，可以完整得看到業務日誌的流轉明細。同樣的道理，服務日誌在入口處，也將分配一個完整的TraceId，標識出完整的日誌。
站點A
TaceId 2ad28f58-858c-47c0-8875-e2e9db4ff24b 請求3fba452e-d9c9-45ee-96cb-19280fa59673 我收到一個請求，參數是
TaceId 2ad28f58-858c-47c0-8875-e2e9db4ff24b 請求3fba452e-d9c9-45ee-96cb-19280fa59673 用戶賬號BBB未認證
站點B
TaceId 2ad28f58-858c-47c0-8875-e2e9db4ff24b 請求3fba452e-d9c9-45ee-96cb-19280fa59673 用戶賬號檢查
針對於全鏈路日誌，我們應該採用TraceId將跨站點的日誌打上標記，對服務內部的日誌轉流也同樣的道理。通過GUID標記好的日誌，可以通過日誌收集系統，FileBeat抓取到Kafka，LogStash從Kafka消費送到ES，我們DIY一個全鏈路日誌查詢系統，在出一線上問題的時候，快速的定位出完整的業務日誌，高效的排查問題。今天本想分享如果打業務日誌，寫着寫着就變主題了，下次再找機會分析打業務日誌的經驗。關於日誌收集系統的搭建，也是另外分享。
首發地址
http://www.jishudao.com/2020/06/07/trace_log/
QQ交流羣:32561678(備註暗號：CSDN)
公衆號
