曹東:攜程日誌系統索引構建之路
分享嘉賓:曹東 攜程 高級軟件開發工程師
編輯整理:桑小晰 深交所
出品平臺:DataFunTalk
導讀: 攜程每天處理數以億級日誌,如何做到實時低延遲、不丟失、查詢高效,具有一定的技術挑戰。本次分享拋磚引玉,將從下面四點切入希望能解開攜程內部落地實踐的面紗:Overview(攜程監控體系整體架構)、Clog(攜程日誌系統)、CAT 和 TSDB。
01 Overview(攜程監控體系整體架構)
此圖爲攜程甚至是業界較爲通用的廣義日誌監控系統整體架構。數據採集主要使用 Agent 和 SDK(支持多種語言和協議)兩種模式,而 SDK 支持廠商頗爲豐富:CAT、Clog、Promethues、Opentelemetry 等。客戶端將採集到的日誌傳輸至 Collector 中聚合與簡單預處理。隨後,Collector 根據元信息與數據特徵分發至 Kafka 的不同 topic queue 中,從而起到數據隔離與系統解耦的效果。
廣義日誌從數據模型上可被分爲 Log、Metric 和 Trace 三類,這也是業界監控的三大基石。Log 通常是一條一條的,用於提供系統 / 進程最精細化的信息。例如某個事件、訪問記錄等;Metric 通常是可聚合的指標,例如某個站點每分鐘訪問次數;Trace 則主要是跨進程、跨線程的調用鏈信息,用於全鏈路追蹤。不同數據類型進入不同的通道(ETL、Analyzer 等)進行處理,最終持久化在 HIVE 等離線數倉工具用於大數據分析,或 TSDB 進行時序聚合,或 ES+HDFS 構建檢索系統。攜程可視化 UI 主要使用 Grafana(開源)和 BAT(自研)。
02 Clog(攜程日誌系統)
Clog 是一個應用日誌不落本地磁盤,實時傳輸的日誌系統,每天處理約 2PB 的日誌數據,機器規模約 40 臺物理機(32C128G)。下圖(右)爲日誌檢索的 UI,用戶可以使用任意分詞搜索,也可以指定 Tag 或者標題等進行檢索。
1. Clog 系統的特點
日誌系統通常需要處理的數據量大,系統設計時應在保證數據不丟失的條件下儘可能保證吞吐量。因此,Clog 系統具有以下特性:
①寫多查少
決定了系統應該具有高吞吐,以及支持多條件組合的豐富查詢功能。
②高性能寫
爲了提升寫入性能,減少延遲,我們主要從內存緩存和磁盤 IO 兩個方向入手。考慮到成本,我們採用 HDD 而非 SSD。HDD 性能依賴磁盤轉速和機械臂的尋址速度,而隨機寫將引發多次尋址從而吞吐上不來。因此,我們在內存中維護 Mem Block,當一個 Block 滿或定時超時後,順序寫入磁盤。
索引上,對每一條日誌建立一個索引(稠密索引)是可行的,缺點是索引空間開銷大,優點是 O(1) 查詢速度;Kafka 是稀疏索引的代表,優點在於節省索引空間,缺點是 O(logn) 查詢速度。考慮到日誌系統寫多查少的使用特點,且查詢多爲用戶 UI 界面操作,對延遲敏感度不高,因此,稀疏索引的優勢更爲明顯。
③條件組合查
結合具體的使用場景, 此係統最終的架構如上圖(右)所示。數據進入 Log Indexer 時,首先會進入 Mem Block 中,Block 含有幾個元信息字段:appid(用於確定此 Block 屬於哪一個應用)、time(時間偏移量)、size(該 Block 大小)。當 Block 裝滿或者到了固定的刷新時間,順序寫入磁盤。磁盤數據由後臺線程定時進行 Upload,包括日誌數據和索引數據。日誌數據存儲於 HDFS 中;索引數據存儲於 ES 中。一個 Block 對應一條到 HDFS 文件位置的索引,而爲了支持條件檢索,我們將日誌中抽取的條件(例如應用、機器、時間、日誌的 title,tag 等)構建到 ES 的倒排索引中。
查詢時,Engine 會根據查詢條件到 ES 中匹配(可能會匹配到多條索引)。根據這些索引可以追蹤到它們是由哪個 Indexer 標記,然後詢問對應的 Indexer 機器是否可以提供數據。由於 Indexer 異步 Upload 到 HDFS,因此 Engine 不直接訪問 HDFS,而是通過 Indexer 代理的方式獲取日誌數據。
03 CAT
Tracing,攜程使用 CAT。由 140 臺物理機(32C128G)每天處理近 2PB 的數據。
1. CAT 系統的特點
①寫多查少
CAT 系統的特點與日誌系統相似,都具有寫多查少的特性。
②Traceid 點查
Traceid 用於精準的單點查詢某個 trace 瀑布流數據(上圖左)。它的來源方式很多,比如通過日誌 tag 得到,從報錯信息中採集,或者根據 CAT 系統提供的樣本中採樣得來。
2.CAT 系統的存儲
①HDFS
CAT 系統使用 HDFS 文件系統來存儲 trace 數據。
②文件數限制
使用 HDFS 系統時,有出現存儲文件數量過多導致性能急速下降的問題。
③索引
CAT 系統的索引也涉及到稠密與稀疏的選擇。
3. 最初使用的 CAT 系統(V5 版本)
V5 存儲方案由數據和索引兩部分組成。若干條數據打包成一個 Block 寫入 Data 文件中。V5 採用稠密索引,即每條數據計算一條索引,佔 6 字節,由 Block 在 Data 文件的 Position(4 字節)和數據寫入 Block 的位置(2 字節)組成,索引 ID 和 CAT 的 message index 一一對應。
-
寫入流程:數據寫入 Block 中,當 Block 達到 64KB(2 字節索引)後,刷入 Data 文件;根據 CAT message index 計算出 Index 文件偏移量(index*6),寫入 6 字節索引數據(BlockAdd,BlockOffset)。
-
讀取流程:根據 CAT 的 message index 計算出 Index 文件偏移量(index*6),從 Index 文件中解析出索引數據。利用索引便能從 Data 文件中快速獲取對應 Block 中指定 ID 的數據。
-
數據文件名和索引文件名使用同樣的編碼格式:由 appId(客戶端應用)、appIp(客戶端機器 ip)和 catIp(Cat Server 的 ip) 組成。此種文件名編碼方式產生的文件數是笛卡爾乘積(appId,appIp,catIp)* 保留小時數時間。尤其在容器化場景下,應用 ip 不固定,將導致 HDFS 文件數目過渡膨脹,HDFS 的 IO 性能急速下降。
4. V6 版本的 CAT 系統
V6 旨在解決由 V5 存儲方案引入 HDFS 文件膨脹後性能急速下降的問題。
攜程應用總量和 CAT 服務端 IP 集合基本穩定,因此,我們去掉了 V5 文件名編碼中的 Ip 維度,便能起到控制 HDFS 中文件數目的效果。
由於客戶端 ip 從文件名編碼中移除,意味着同一個應用的多個 ip 的索引數據將使用同一個 Index 文件,亦意味着 V5 中 CAT message index 與索引 ID 一一對應的條件不再成立,因此需要一個二級索引機制。
索引文件由多組 4096 個 Segment 組成,一組 Segment 中第一個 Segment 被稱爲 Header,每個 Segment 包含 4096 條索引,每個索引佔 8 個字節(5 字節 BlockAdd,3 字節 BlockOffset,相比 V5 的 6 字節變大主要是爲了擴大 Block 大小)。Header 的引入是爲了解決某個客戶端數據索引定位的問題,其存儲了 ip 與 Segment 的映射關係。
-
SegmentIndex:由 CAT message index 除 4096 得到;
-
SegmentOffset:由 CAT message index 模 4096 得到;
-
SegmentID:HeaderSegmentOffset / 8 + 4096 * 第幾個 Header;
-
SegmentAdd:Index 文件中的物理偏移量。SegmentID * 4096 * 8。
-
索引寫入流程:計算 SegmentIndex 和 SegmentOffset,如果當前 ip 的 SegmentIndex 是新的(內存映射表是否存在判斷),向 Header 中寫入一條記錄;如果 Header 已滿,則在新 Segment(segment 數量已達到 4096 倍數)開始寫入新的 Header。根據 SegmentID 和 SegmentOffset 找到具體位置,寫入 BlockAdd 和 BlockOffset。
-
索引讀取流程:計算 SegmentIndex 和 SegmentOffset,根據 SegmentIndex 從內存映射表中得到 SegmentID。根據 SegmentID 計算 SegmentAdd,最終由 SegmentAdd + SegmentOffset 處讀取 BlockAdd 和 BlockOffset。
04 TSDB
Metric 作爲聚合指標數據,一般用於閾值告警通知。在 Promethues 出現前,攜程借鑑了 OpenTSDB 的思路實現了一套內部的 TSDB。該系統將所有數據和索引存儲到 HBase 數據庫,我們通過將 Tag 編碼到 HBase 的 rowkey 中,來實現快速檢索。後來,我們相關技術向 VictorialMetrics 時序數據庫和 ClickHouse 列存數據庫遷移。目前的 VictorialMetrics 系統規模是 200 臺物理機(40C256G,4T SSD)。當基數(Tag 維度組合)較多時,VictorialMetrics 的性能會急劇下降,這是因爲 Metric 到 ID 的映射關係緩存在內存中,當 Miss 後,將從索引文件中讀取,大量文件解碼將導致 CPU 持續高位,影響性能,因此內存決定了 VM 支持的基數有限。對於高基數的數據,我們引入了 ClickHouse,當前規模 600 臺物理機(32C128G)。
05 Q&A
Q:日誌的分詞器用的是什麼?
A:我們的倒排索引使用的是 ES,我們的日誌有一部分是支持倒排索引給出的維度的檢索的,包括應用、機器、時間、等預設的固定維度。如果是用戶 info 某一不帶有任何標記的句子時,考慮到句子可能會很長(存儲索引會很龐大),我們只截取前 128 個字節進行分詞,並以 message 的方式放入倒排中進行檢索。128 字節之後的內容不支持精確檢索,因此當查詢到多條結果時,需要用戶在瀏覽器中自行過濾。
Q:日誌 ETL 使用的是什麼框架?
A:ETL 使用的是內部自研的框架,主要用於做格式 Format 和預聚合。
Q:ClickHouse 用做日誌存儲的優點是什麼?
A:我們的日誌包括比較雜亂的普通日誌(例如:今天是個好天氣)和較爲規整的業務日誌(例如:包含多維度信息的訂單日誌)。ClickHouse 主要用於存儲業務日誌,它會提前爲這些業務日誌中的維度建立列,當然它也用於存儲高基數據。ClickHouse 的優缺點取決於需要使用的場景。例如,ClickHouse 維度的列是固定的,當其維度增多時,性能會明顯下降。相比之下,Clog 的限制就比較小,並且它支持分詞功能。
今天的分享就到這裏,謝謝大家。
分享嘉賓:
本文由 Readfog 進行 AMP 轉碼,版權歸原作者所有。
來源:https://mp.weixin.qq.com/s/5a8uRYas-kakXX7soDj7ZQ