本文主要介紹騰訊 SNG 開發全鏈路日志監控平臺所經歷的挑戰及解決方案。

[[214785]]

背景

全鏈路日志監控在現在盛行的微服務和分布式環境下，能有效地提高問題定位分析效率，成為開發和運維利器。

當前已有開源解決方案和成熟的廠商提供，比如 Twitter 的 zipkin，基于 Google 的 Dapper 論文設計開發了分布式跟蹤系統，用于采集各處理節點間的日志和耗時信息，幫助用戶排查請求鏈路的異常環節。

在有統一 RPC 中間件框架的業務部門比較容易接入 zipkin，但織云全鏈路日志監控平臺（后成全鏈路）面對的實際業務場景更為復雜。

全鏈路日志監控實現遇到了更多的挑戰，全鏈路技術選型經歷了從開源組件到自研的變化。

當前織云全鏈路日志監控平臺已接入空間和視頻云業務日志數據，每日數據存儲量 10TB，可做到 1/10 的壓縮比，峰值流量 30GB/s。

我們先分享一個案例場景：

2017 年 8 月 31 日 21:40~21:50，X 業務模塊指標異常，成功率由 99.988% 降為 97.325%，如下圖所示：

收到成功率異常告警后，在多維監控系統上通過畫像下鉆發現是空間點播業務的 iPhone 客戶端成功率下降，返回碼為-310110004。如下圖：

通過大盤多維數據分析發現異常原因后，因涉及 APP 問題，還需要進一步分析用戶出現異常的上下文。

因而需要查看出現異常的用戶在異常時間點的全鏈路日志數據。在全鏈路視圖上，可以展示查詢出來符合異常條件的用戶日志和操作過程。

以上是從面到點的異常分析案例。

使用場景

全鏈路日志監控的使用場景主要有三大類：

• 個例分析，主要有處理用戶投訴和從面到點的異常分析。
• 開發調試，主要用于開發過程中查看關聯模塊的日志和作為測試提單線索。
• 監控告警，主要是從日志數據中提取維度，統計為多維數據用于異常檢測和原因分析。

遇到的挑戰

在構建織云全鏈路日志監控平臺時，織云監控模塊經歷了從傳統監控和質量統計到大數據多維監控平臺的轉型。我們踩過了大數據套件的坑，也遇到過業務場景的挑戰。

業務多樣性挑戰

QQ 體系內有豐富多樣的業務，例如：手 Q、空間、直播、點播、會員等。

這些業務產生不同樣式的日志格式，并且沒有一致的 RPC 中間件框架。這個背景決定系統需要支持靈活的日志格式和多種采集方式。

海量數據挑戰

同時在線超 2 億用戶上報的狀態數據，日存儲量超 10T，帶寬超過 30GB/s，需要穩定和高效的數據處理、高性能和低成本的數據存儲服務。

在使用開源組件完成原型開發后，逐漸遇到性能瓶頸和穩定性挑戰，驅使我們通過自研逐漸替換開源組件。

應對挑戰

日志多樣化

日志的價值除提供查詢檢索外，還可做統計分析和異常檢測告警。為此我們將日志數據規范化后分流到多維監控平臺，復用監控平臺已有的能力。

基于前面積累的監控平臺開發經驗，我們在織云全鏈路日志監控平臺設計時取長補短，通過自研日志存儲平臺解決開源存儲組件遇到的成本、性能和穩定性瓶頸。

織云全鏈路日志監控平臺提供了 4 種數據格式支持，分別是：

• 分隔符
• 正則解析
• json 格式
• api 上報

分隔符、正則解析和 json 格式用于非侵入式的數據采集，靈活性好。但是服務端的日志解析性能較低，分隔符的數據解析只能做到 4W/s 的處理性能。

而 api 方式則能達到 10W/s 處理性能，對于內部業務，我們推薦采用統一的日志組件，并嵌入 api 上報數據。

系統自動容災和擴縮容

對于海量的日志監控系統設計，***步是將模塊做無狀態化設計。比如系統的接入模塊、解析模塊和處理模塊，這類無需狀態同步的模塊，可單獨部署提供服務。

但對這類無狀態業務模塊，需要增加剔除異常鏈路機制。也就是數據處理鏈路中如果中間一個節點異常，則該節點往后的其他節點提供的服務是無效的，需要中斷當前的鏈路，異常鏈路剔除機制有多種，如通過 zk 的心跳機制剔除。

為避免依賴過多的組件，我們做了一個帶狀態的心跳機制。上游節點 A 定時向下游節點 B 發送心跳探測請求，時間間隔為 6s，B 回復心跳請求時帶上自身的服務可用狀態和鏈路狀態。

上游節點 A 收到 B 心跳帶上的不可用狀態后，如果 A 下游無其他可用節點，則 A 的下游鏈路狀態也置為不可用狀態，心跳狀態依次傳遞，最終自動禁用整條鏈路。

有狀態的服務通常是存儲類服務，這類服務通過主備機制做容災。如果同一時間只允許一個 master 提供服務則可采用 zk 的選舉機制實現主備切換。

做到系統自動容災和擴縮容的第二步是實現通過路由機制實現名字服務和負載均衡。

使用開源組件 zookeeper 能快速實現名字服務功能，要求在服務端實現注冊邏輯，在客戶端實現路由重載邏輯。

數據通道的容災

我們采用兩種機制：

• 雙寫方式，對于數據質量要求高的監控數據，采用雙寫方式實現。這種方式要求后端有足夠的資源應對峰值請求，提供的能力是低延時和高效的數據處理能力。
• 消息隊列，對于日志數據采用具備數據容災能力的消息隊列實現。使用過的選型方案有 kafka 和 rabbitmq+mongodb。

采用消息隊列能應對高吞吐量的日志數據，并帶有削峰作用，其副作用是在高峰期數據延時大，不能滿足實時監控告警需求。

采用消息隊列還需要注意規避消息積壓導致的隊列異常問題，例如使用 kafka 集群，如果消息量累積量超過磁盤容量，會造成整個隊列吞吐量下降，影響數據質量。

我們后來采用 rabbitmq+mongodb 方案：數據在接入層按 1 萬條或累積 30s 形成一個數據塊，將數據庫隨機寫入由多個 mongodb 實例構成的集群。再將 mongodb 的 ip 和 key 寫入 rabbitmq 中。

后端處理集群從 rabbitmq 獲取待消費的信息后，從對應的 mongodb 節點讀取數據并刪除。通過定時統計 rabbitmq 和 mongodb 的消息積壓量，如何超過閾值則實施自動清理策略。

查詢

日志的存儲方案為應對高效和低成本查詢，我們采用自研的方式實現。全鏈路上報的數據按用戶 ID 或請求 ID 作為主 key 進行 hash 分片。

分片后的數據在緩存模塊累積 1min 或 1M 大小，然后寫入文件服務器集群；文件寫入集群后，將 hash 值與文件路徑的映射關系寫入 Elastic Search。

查詢數據提供兩類能力：

• 按主 key 查詢。查詢方式是對待查詢 key 計算 hash 值，從 ES 中檢索出文件路徑后送入查詢模塊過濾查找。
• 非主 key 的關鍵字查找。根據業務場景，提供的查詢策略是查詢到含關鍵字的日志即可，該策略的出發點是平衡查詢性能，避免檢索全量文本。

也就是***次查詢 1000 個文件，如果有查詢結果則停止后續的查詢；如果無查詢結果返回，則遞增查找 2000 個文件，直到查詢 10 萬個文件終止。

為滿足多樣的業務場景，我們在數據處理模塊抽象了 ETL 能力，做到插件化擴展和可配置實現，并提供統一的任務管理和集群管理能力。

總結

全鏈路日志監控的開發過程有以下經驗可借鑒：

• 使用成熟的開源組件構建初級業務功能。
• 在業務運行過程中，通過修改開源組件或自研提升系統處理能力和穩定性，降低運營成本和提升運維效率。
• 采用無狀態化和路由負載均衡能力實現標準化。
• 抽象提煉功能模型，建立平臺化能力，滿足多樣業務需求。