曹東：攜程日誌系統索引構建之路

分享嘉賓：曹東攜程高級軟件開發工程師

編輯整理：桑小晰深交所

出品平臺：DataFunTalk

**導讀：**攜程每天處理數以億級日誌，如何做到實時低延遲、不丟失、查詢高效，具有一定的技術挑戰。本次分享拋磚引玉，將從下面四點切入希望能解開攜程內部落地實踐的面紗：Overview（攜程監控體系整體架構）、Clog（攜程日誌系統）、CAT 和 TSDB。

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（自研）。

Clo****g（攜程日誌系統）

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 代理的方式獲取日誌數據。

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。

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）。

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

猜你喜歡