阿里雲日誌採集平臺（阿里本地生活全域日誌平臺）

2023-10-10 19:57:25 11

1. 背景

程式設計師學習每一門語言都是從列印「hello world」開始的。這個啟蒙式的探索，在向我們傳遞著一個信息：「當你踏進了編程的領域，代碼和日誌將是你最重要的夥伴」。在代碼部分，伴隨著越來越強大的idea插件、快捷鍵，開發同學的編碼效率都得到了較大的提升。在日誌部分，各個團隊也在排查方向進行創新和嘗試。這也是研發效能領域重要的組成部分。

阿里集團本地生活，在支撐多生態公司，多技術棧的背景下，逐漸沉澱了一款跨應用、跨域的日誌排查方案-Xlog。目前也支持了icbu、本地生活、新零售、盒馬、螞蟻、阿里cto、阿里雲、淘特、靈犀互娛等團隊。也獲得了sls開發團隊的點讚。

希望本文可以給正在使用或準備使用sls的同學帶來一些輸入，幫助團隊儘快落地日誌排查方案。其中第一部分重點講了在微服務框架下，日誌排查面臨了怎樣的挑戰，以及我們是如何解決的。第二部從細節角度講了方案設計的幾個難點和攻克策略。第三部分講的是Xlog當前具備的能力。第四部分是在圍繞主要能力，如何進行生態能力建設的。

1.1 Xlog解決的問題

在通過日誌進行問題排查的時候，相信有幾個步驟大家再熟悉不過：1. 登陸跳板機。 2. 切換跳板機。3. 登陸阿里雲平臺sls。 4. 切換阿里雲sls project logstore。循環往復。

舉個例子，下面這張圖顯示了一個長鏈路系統的片段(真實鏈路會複雜更多) ：Application1, Application2, Application3。其中Application1與Application2是同一個域(類似於：一個子團隊)，Application3屬於另外一個域。那本次查詢就涉及到跨應用查詢，跨域查詢兩個場景。

Application1的負責人接手了該問題後，通過跳板機或者sls日誌，發現需要上遊同學幫忙協助排查。這個時候無論是切換跳板機還是sls，亦或聯繫Application2的負責人協助查詢，都需要1min->3min的響應時間。如果是從Application2的負責人尋找Application3的負責人將會更難，因為可能不清楚Application3的sls信息(我們bu就有十萬級別的logstore信息)，又沒有跳板機登陸權限，又不知道Application3的負責人。於是排查時間大幅度增加。環境準備的時間(無效排查時間)甚至遠大於有效排查的時間。

剛才的例子只展示了3個應用的查詢場景，往往真實鏈路要比這個複雜很多很多。所以是不是有一個平臺，可以一鍵式、一站式地查詢出需要的日誌呢？於是致力於解決長鏈路下，跨應用和跨域搜素頻繁切換的Xlog就誕生了！

1.2 Xlog支持的場景

微服務框架下的跨應用查詢，跨域融合背景下的跨域查詢。

如果你們的團隊使用了sls，或者準備將日誌採集到sls；如果你們的希望可以擁有更好的日誌檢索、展示能力；如果你們希望可以跨應用，跨域搜索日誌；

本文為大家介紹 xlog，幫助集團內業務構建更大生態的，簡便易用無侵入，並且隨著越來越多的域接入之後，可以連點成線、併線為面，共同打造一個經濟體，或者更大生態的日誌全鏈路方案。

1.3 Xlog當前體系建設

針對已經採集到sls的應用，我們可以做到對代碼零改造、對部署環境無侵入，並且採集的結構、採集的渠道都是自由的。基本上，只要已經接入了sls的，就可以接入Xlog了。通過對結構的歸一、格式歸一、和跨域能力打通，Xlog支持了排查問題最常使用的幾個場景：應用內跨文件搜索，域內跨應用搜索，跨域搜索。

《持續交付2.0》的作者喬梁提到：一致性，是研發效能提升必經之路。整個經濟體發展20多年，一致性的全量覆蓋難如登天，但Xlog創新地提出了一種方案，將不一致轉化成一致，無論對查詢還是對其他基於日誌的技術體系建設，都有裡程碑的意義。

2. 方案設計

這個段落將會詳細講述Xlog的設計思想和發展過程，如果是已經接入sls的可以直接跳到2.2；如果當前還未接入sls，可以讀2.1 會有一些創新的思路。

2.1 最初的方案：創新與獨善其身

2019年saas剛成立，很多基礎建設都有待完善，與很多團隊一樣當時我們查詢日誌主要通過兩種方式：

1. 登陸跳板機查詢：使用Traceid->鷹眼->機器ip->登陸跳板機->grep 關鍵字 的查詢鏈路。缺點：每次查詢4-6分鐘，日誌檢索和可視化差，無法跨應用查詢，歷史日誌無法查看。

2. 登陸阿里雲sls web控制臺查詢：登陸sls->關鍵字查詢。缺點：每次查詢1-2分鐘，日誌可視化差，無法跨應用查詢，無法跨域查詢。

基於這樣的背景，我們做了3件事來提升查詢效率：

日誌格式統一: 針對logback中的pattern使用了一套標準。

%d{yyyy-MM-dd HH:mm:ss.SSS} {LOG_LEVEL_PATTERN:-%5p}{LOG_LEVEL_PATTERN:-%5p}{PID:- } --- [%t] [%X{EAGLEEYE_TRACE_ID}] %logger-%L : %m%n

其中：%d{yyyy-MM-dd HH:mm:ss.SSS}：時間精確到毫秒${LOG_LEVEL_PATTERN:-%5p}：日誌級別，DEBUG，INFO，WARN，ERROR等${PID:- }：進程id---：分隔符無特別意義[%t]：線程名[%X{EAGLEEYE_TRACE_ID}]：鷹眼跟蹤id%logger：日誌名稱%m%n：消息體和換行符

一個域內使用相同的日誌格式，事實證明這帶來的收益遠超出預期。對全鏈路的分析，監控，問題排查，甚至對將來的智能排查都帶來極大便利。

sls結構設計與統一：將域內所有應用的採集格式統一成一套結構，和正則方式提欄位，方便採集和配置。在docker的基礎鏡像裡面生命logtail的配置，這樣域內所有應用可以繼承同樣的日誌採集信息。sls採集結構下沉：這裡我們創新的提出了一個概念下沉的理念。並通過這樣的方式可以非常便捷的實現跨應用查詢。如下圖所示，sls結構可以理解為4層：account, project, logstore, logtail。其中logstore這一層很關鍵，關係著關係查詢的維度。常見的方案是使用一個應用對應一個losgtore，這就導致在多個應用查詢的時候，需要頻繁切換logstore。因此我們創新的提出了概念下沉的理念。讓每一個環境對應一個logstore，這樣只需要確定了查詢的環境，就能清楚的知道在哪個logstore中查詢，從而實現跨應用查詢的效果。

這套方案在解決單應用、域內跨應用有著非常好的性能表現，只需要完成一次api的調用。如果你所在的團隊正在準備使用sls，如果sls的數據只用於做排查(監控類的sunfire可以直接讀伺服器本地日誌)我們依然建議採用這樣的方案。可以很好的完成排查的需要。同樣基於這樣幾個條件的解決方案已經沉澱到Xlog中，可以直接接入Xlog，從而享有Xlog全套的能力。

2.2 現在的方案：創新與兼濟天下

剛才的方案在解決自己域的排查問題的時候有著很好的表現。但2020年，saas開始支撐多個生態公司，面臨的場景不再是自己域內的，還需要多個域共同串聯。這時我們面臨著兩大考驗：

接入成本：我們規定了一套sls採集方式和日誌格式，按照這樣的形式可以方便的進行數據的採集和高效的查詢、展示。但是在其他部門進行接入的時候發現，由於已有系統已經配置了監控、報表等模塊，導致日誌格式不能修改。由於有些系統之前已經採集到sls導致採集結構也不能修改。這兩個信息不一致導致接入成本很大。

跨域場景：在系統日趨複雜的情況下，跨域場景也越來越多。拿本地生活的業務場景舉例。在入淘的大背景下，部分系統完成淘系遷移，仍有部分系統在螞蟻域；兩個域的打通需要經過網關。在口碑和餓了麼深度融合的情況下，互相調用也需要經過網關。目前也在和收購的isv打通，同樣需要經過網關。由於各個公司採用的鏈路追蹤方案不通，導致traceid等信息不一致，無法全鏈路排查。所以如何解決跨域場景日誌搜索成為第二大問題。

因此，在之前的方案上，我們把Xlog進行了升級，重新定義了目標：

核心能力：應用->跨應用->跨域->全域多場景日誌排查。從只能查一個應用的日誌，到可以在域內查一條鏈路的日誌開啟真正全鏈路日誌排查的大門。接入成本方面： 十分鐘接入。通過代碼邏輯降低對現有日誌格式和採集方式的改動。支持logtail、produce、sdk等多種採集方式。侵入性方面：零侵入，對應用代碼無侵入，直接與sls交互，實現解耦。自定義方面：支持查詢界面自定義，展示結果界面自定義。

2.2.1 模型設計

由於調用sls api查詢日誌的單元是logstore，我們可以將多種多樣的採集結構拆結為一下3種單元的組合（當然絕大多數域可能就是其中一種結構）。

1. 一個環境對應一個logstore，（比如：在這個域內，所有應用在日常環境的日誌都在一個logstore中）。如下圖所展示的域A。

2. 一個應用對應一個logstore，（比如A應用日常環境對應logstore1， A應用預發環境對應logstore2， B應用日常環境對應logstore3）。如下圖所展示的域B。

3. 一個文件對應一個logstore，（比如A應用的a文件在日常環境對應logstore1，A應用的b文件在日常環境對應logstore2）。如下圖所展示的域C。

有了這樣的原子結構，只需要在xlog上配置的時候，創建好一個域、環境、應用、文件=> logstore的映射關係即可。這樣就可以在域內進行應用粒度、文件粒度的查詢。

同樣在不經過網關跨域場景可以通過組合兩個域的logstore 完成跨域的查詢。如上圖所示：在域A中指定兩個應用，可以轉換成logstore加過濾條件。在域B中指定兩個應用，可以轉換成兩個logstore。在域C中指定兩個應用可以先尋找應用下的文件，然後找到文件對應的logstore 集合。至此就有了需要在阿里雲sls查詢日誌的所有logstore。將查詢結果進行組合和排序就可得到最終的結果。同理，如果想進行跨域的搜索，只需要將多個域的logstore進行拼接。然後進行查詢即可。

2.2.2 性能優化

通過2.2.1模型設計的講述，無論是環境類型的、應用類型的還是文件類型的sls結構，以及單應用、多應用、多個域的查詢都可以轉換成一組logstore，然後遍歷執行logstore。但是這樣就會引入新的問題，如果logstore很多，如何才能提效。舉個例子，在對接某團隊日誌的時候發現，他們的logstore有3000個，每個環境有1000個應用。假設每次查詢需要150ms，1000個應用需要執行150s(2.5分鐘)。試想如果不指定應用在全域搜索一次日誌都需要2.5分鐘，那將是多大的成本。針對這樣的問題，我們進行了性能方面的優化。主要採用了以下幾個方式，如下圖所示：

Logstore連結池預加載：將logstore進行去重和連結，減少每次查詢創建連結的時間。針對活躍度不高的logstore進行降級，惰性加載。多線程並發：針對多個logstore的場景進行並發查詢，減少查詢時間。算法優先隊列：針對查詢人員進行親疏算法優化，精簡logstore查詢數量，從而減少開銷。前端組合排序：後端只做查詢操作，排序和查找等操作均在前端完成，減少後端並發壓力。

如上圖所示，當用戶通過前端選擇對應的操作域，以及查詢條件之後。後端分析獲取需要查詢的logstore列表（圖中A,B,C,D,E所示）。再通過分析用戶的親密應用來進行排序和篩選，從而得到優先級隊列（圖中B,A,C）。針對優先級隊列使用已經創建好的連結池進行並發查詢，從而得到一組日誌結果。最後由前端完成排序和組裝，並渲染出來，完成一個周期。本文主要講解其中線程池並發和算法優化模塊。

2.2.3 線程池並發

相較於傳統的線程池並發執行沒有太大差異。將需要查詢的logstore，按照順序插入到線程池隊列。通過該手段可以在單次查詢logstore數量較小(小於核心線程數)的時候，有效的降低查詢時間。針對數量較大的場景，由算法優化進行支持。

針對查詢後的補償操作，也使用異步的處理方式，減少查詢耗時。

結構後處理：在環境結構的域中，配置過程無需配置應用和文件。這些數據來源於每次查詢之後，不斷將缺失的數據自動填充進結構的處理操作。針對這些不影響當次查詢結果的操作，作為後處理添加到異步線程池中。算法後處理，在處理人員親疏關係和應用親疏關係的評分邏輯中，使用的是不斷訓練的方式。該部分也不影響當次查詢的結果，也放到異步線程池中。

2.2.4 算法優化

針對滿足條件的logstore較多(超過核心線程數)的場景，通過線程池並發進行查詢也不能較快的拿到結果。經過日誌快排一年數據的積累和分析，我們發現即便是沒有指定應用和搜索條件，也可以通過查詢人員的操作習慣或者關注應用習慣，定位到最有可能的logstore序列。

舉個例子，在商家saas中心，應用數量有500個左右。同學A負責的系統是 Application1，查詢次數較多的應用還有Application11，Application12。除此之外，與Application1處於緊密上下遊關係的應用是Application2，Application3。如果是這樣，我們可以認為同學A，對應用Application1，Application11，Application12，Application2，Application3的關注度會高於其他應用。針對這幾個應用，可以進行優先查詢。從而將的500個查詢任務降低成5個。

結合日常生活中的狀況，每個開發同學關注的應用數量大概率會控制在30個以內。

通過以上的分析，我們建立了兩套親疏關係網絡用於定位查詢批次和梯隊。

人員親疏關係

當用戶每次調用的時候，都可以將查詢條件，查詢結果和用戶進行分析和關係創建。由於查詢條件中可以指定應用，也可以不指定應用。

如果是指定應用的，說明用戶明確查詢該應用內容。將該用戶和該應用的親密度加5分。

如果沒有指定應用，根據關鍵字查詢，可以分析查詢出的結果。將查詢結果的各條日誌對應的應用提取出來，然後加1分（由於不是明確指定的，而是根據關鍵字輻射到的）。

至此，經過多次的用戶操作，就可以獲取到用戶與各個應用的親密度。當遇到多logstore查詢的場景，可以根據用戶篩選出與之親密度最高的15個應用。作為第一批查詢對象。

應用親疏關係

應用之間也存在著親密度關係。親密度越高的應用，被關聯搜索出來的概率就越大。舉個例子，center與prod 兩個應用在系統設計上就有這緊密的關聯關係。如果用戶A的親屬關係中包含應用center，那麼在其查詢日誌的時候就有較大概率輻射到應用prod。基於這樣的思路，就可以通過分析每次查詢日誌的結果進行關係矩陣的創建。

在每次獲取通過關鍵字查詢的日誌結果之後，將涉及到的應用進行兩兩親密度加1。相當於在一個鏈路上的應用親密度都加1。方便以後查詢時不會因為人員親密度喪失應用親密度的信息，導致鏈路失真。

上面大致概括了一下，我們是如何訓練親疏關係矩陣的，下面講一下如何通過這個矩陣進行查詢算法優化的。如下圖，左上角是我們記錄的人-應用，應用-應用的親疏關係矩陣。具體來講，用戶和應用A、應用B、應用C等關係，我們會用一個分數度量他們的親疏關係，主要可以描述人對應用的關注度。在應用-應用之間，我們記錄了彼此的耦合度。右上角是查詢條件，根據查詢條件以及各個域的採集結構，可以快速的計算出需要查詢的logstore的列表。但並不是所有的logstore都需要查詢，這裡會將親疏關係矩陣和logstore的列表取交集，然後排序進行搜索。如下圖所示，針對交集命中的應用，會先按照人-應用的親疏關係進行計算，選出分值比較高的。然後不足30個閾值的使用應用-應用的親疏關係進行補充。這裡就涉及到一個比較邏輯，會按照人和應用的比例分值*應用與應用比例的分值，類似於哈夫曼編碼中的路徑權重的意思。最後得到需要查詢的30個logstore的列表。

2.2.5 跨域映射

進行全鏈路的排查，跨域是必須面對的挑戰。在實現原理上講，跨域有兩種場景：經過網關、沒有經過網關。

不經過網關的場景，如：淘系不同域的互相調用。這個場景其實本質上與域內搜索沒有太大區別，這裡不多介紹。經過網關的場景，如：淘系與螞蟻系互相調用，由於每個域使用的鏈路追蹤方案不同，無法使用一個traceId將整個鏈路串聯起來。這裡主要講一下這種場景的處理方式。

如上圖所示，展示了域1，域2，域3，域4的調用鏈路。其中域1調用域2，域3調用域4不經過網關，traceId不發生改變。在域2調用域3的時候需要經過網關，並且traceId發生改變。

我們可以將查詢方式分為兩種。1. 關鍵字查詢，比如輸入訂單號。這種其實並不受鏈路追蹤方案影響，也不受網關影響。所以還是在各個域根據關鍵字查詢即可。2. 通過traceId查詢。這種首先需要通過網關信息獲取到映射關係。也就是traceId1->traceId2。然後分別用這兩個traceId到各自的域中進行搜索即可。

3. 現有能力

通過對原有飛雲日誌快排功能的完善，以及接入成本的改良。Xlog 已經完成主要功能的開發和實現。連結：Xlog.

跨域查詢操作：

多場景覆蓋：通過對用戶使用習慣的分析，目前支持了單個應用、域內跨應用、跨域。按照文件，日誌等級，關鍵字，時間等搜索。同時支持用戶操作習慣保存。多模式支持：對阿里雲sls採集結構進行支持，只要可以拆解為以上三種模式的採集方式都可以支持，如果極特殊情況可聯繫御田進行定製化。零成本接入：對於已經接入sls的系統，無需改動sls配置，只需在Xlog上進行配置即可。對於sls採集日誌保存時間，採集方式，預算等分發到各個業務團隊，可根據自己實際情況進行調整。自定義界面：針對不同的域，可能對一些關鍵欄位的敏感度不同。比如有些需要使用traceid，有些需要使用requestid，遊戲需要使用messageid，針對這種場景，支持自定義搜索框，和展示日誌的時候對關鍵欄位高亮。性能保障：通過以上多種手段的性能優化，目前性能指標如下：單個應用查詢150ms。32個應用400ms。超過50個應用，進行算法優化，時間在500ms。4. 生態建設

本章節記錄了，在此體系上進行的日誌層面的優化和建設。大部分思想和策略是可以復用的，希望可以給相同訴求的同學帶來幫助。

4.1 成本優化

Xlog體系搭建完成之後，如何降低成本成為了新的挑戰。經過以下方式的落地，成本降低80%。這裡也把主要的幾個操作列舉出來，希望可以給相同在使用sls的用戶一些幫助。

域外日誌直接上傳到域內：

阿里雲對內部帳號相對於外部帳號是有額外的優惠的。所以如果有彈外部署的部門，可以考慮把日誌直接上傳到域內的帳號，或者把帳號申請成為域內帳號。

單應用優化：

其實列印日誌的時候，往往沒有考慮到成本原因，很多都是隨手就打了。因此我們給每個應用按照交易量進行了域值設計，超過指標的需要進行優化。

存儲時間優化：

優化存儲時間是最簡單，最直接的一個方式。我們將線下(日常和預發)的日誌存儲降低到了1天，線上的降低到了3天->7天。然後再配合使用歸檔能力，進行成本的優化。

索引優化 ：

索引優化相對來說比較複雜，但是也是效果最明顯的。經過分析，我們大部分成本開銷分布在索引、存儲、投遞。其中索引佔了70%左右。優化索引的操作，其實就是將索引所佔的日誌比例降低。比如說只支持前多少字節的一個查詢能力，後面的詳情部分是附屬的詳細信息。由於我們域內有統一的日誌格式，所以在域內的日誌中只留了traceid的索引，同時對摘要日誌保持了全索引。所以後續的查詢方式變成先通過摘要日誌查詢traceid，再通過traceid查詳情。

4.2 歸檔能力

在搭建整個架構的同時，我們也考慮了成本的因素。在降低成本的時候，我們把存儲時間進行了縮短。但是縮短存儲時間，必然會導致歷史問題的排查能力缺失。所以我們也提出歸檔能力的建設。

在sls的logstore中，可以配置數據投遞：https://help.aliyun.com/document_detail/371924.html。這一步操作其實是講sls中的信息，存儲到oss。通俗的講，就是把資料庫的表格，用文件的形式保存下來，刪掉索引的能力。在投遞過程中會進行加密，目前Xlog支持了在界面上進行下載歸檔的日誌，然後在本地進行搜索。

後續可以按需將oss數據重新導入到sls，參考：https://help.aliyun.com/document_detail/147923.html。

4.3 異常日誌掃描

藉助於之前的架構，其實可以很清晰的知道每條日誌的內容部分是哪裡，也可以精準的查詢出記錄了error日誌的文件內容。所以每10分鐘巡檢一次，將每個應用中的異常日誌聚合起來，就可以獲取到這段時間異常信息的數量。然後在於之前的比較就可以知道，是不是有新增的錯誤，暴增的錯誤等等。

如上圖所示，拿到所有異常日誌後，會按照一個規則進行md5的計算。堆棧類的和異常日誌類的，針對兩類的算法不同，但是本質目標是一樣的就是取其中最有可能重讀的段落計算md5，然後進行聚類。聚類完成之後，就可以獲取差異，進行比較，從而判斷是不是新增或者暴增。

5. 規劃

目前Xlog的基礎組件和功能已經實現完畢。在各個應用和域的接入中，整個鏈路將會越來越全。接下來將向全鏈路，可視化排查、智能排查和問題發現方面進行補充。

異常定位輔助：在可視化鏈路上，將含有異常的應用標紅，方便快速查到錯誤日誌。線上典型問題聚合：日誌巡檢。線下錯誤捕獲護航：在業務測試的時候經常不會實時的查看日誌中的錯誤信息，開啟護航模式，將艦艇應用錯誤，一旦線下執行過程中出現，將會推送。信息查詢：與釘釘打通，用於快捷查詢。釘釘@機器人，發送關鍵字，釘釘將最近執行結果返回。智能排查：@釘釘輸入traceid，訂單號等，返回檢測到的異常應用和異常棧。業務流程編排核對：允許應用日誌流程編排，根據關鍵字串聯的鏈路流程日誌需要滿足一定規則。用此規則進- 核對。=>針對實時性要求不高，僅對流程進行驗證。發布門禁：線下用例回放無業務異常，線上安全生產無業務異常=> 允許發布6. 使用與共建

參考很多其他團隊的採集結構、日誌形式、查詢方式、展示樣式的要求，在接入成本上降低和自定義方面進行了提升。針對已經滿足條件的團隊，可以方便的接入。

針對還有一些特殊，或者定製化的需求，Xlog進行了拓展模塊的預留，方便共建。