騰訊SNG全鏈路日誌監控平臺之構建挑戰

做者丨吳樹生：騰訊高級工程師，負責SNG大數據監控平臺建設。近十年監控系統開發經驗，具備構建基於大數據平臺的海量高可用分佈式監控系統研發經驗。

導語：當前SNG全鏈路日誌監控平臺每日數據存儲量10TB，可作到1/10的壓縮比，峯值流量30GB/s。在構建這樣一個平臺時，究竟遇到了什麼技術困難，以及是如何解決的，請看原文。

背景

全鏈路日誌監控在如今盛行的微服務和分佈式環境下，能有效地提升問題定位分析效率，成爲開發和運維利器。當前已有開源解決方案和成熟的廠商提供。

好比Twitter的zipkin基於Google的Dapper論文設計開發了分佈式跟蹤系統，用於採集各處理節點間的日誌和耗時信息，幫助用戶排查請求鏈路的異常環節。

在有統一RPC中間件框架的業務部門容易接入zipkin。但騰訊SNG全鏈路日誌監控平臺（後成全鏈路）面對的實際業務場景更爲複雜，全鏈路日誌監控實現遇到更多的挑戰，全鏈路技術選型經歷了從開源組件到自研的變化。

當前SNG全鏈路日誌監控平臺已接入空間和視頻雲業務日誌數據。每日數據存儲量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值與文件路徑的映射關係寫入ElasticSearch。

查詢數據提供兩類能力：

第一類是按主key查詢。查詢方式是對待查詢key計算hash值，從ES中檢索出文件路徑後送入查詢模塊過濾查找；

第二類查詢能力是非主key的關鍵字查找。根據業務場景，提供的查詢策略是查詢到含關鍵字的日誌便可。該策略的出發點是平衡查詢性能，避免檢索全量文本。也就是第一次查詢1000個文件，若是有查詢結果則中止後續的查詢。若是無查詢結果返回，則遞增查找2000個文件，直到查詢10萬個文件終止。

爲知足多樣的業務場景。咱們在數據處理模塊抽象了ETL能力，作到插件化擴展和可配置實現。並提供統一的任務管理和集羣管理能力。

總結

全鏈路日誌監控的開發過程有如下經驗可借鑑：

• 使用成熟的開源組件構建初級業務功能；

• 在業務運行過程當中，經過修改開源組件或自研提高系統處理能力和穩定性，下降運營成本和提高運維效率；

• 採用無狀態化和路由負載均衡能力實現標準化；

• 抽象提煉功能模型，創建平臺化能力，知足多樣業務需求。