​乾貨 | 愛奇藝全鏈路自動化監控平臺的探索與實踐

網際網路技術普及過程中，資料的監控對每個公司都很重要。近些年，隨著一些優秀監控工具（比如Zabbix、Graphite、Prometheus）的成熟，每個公司都會搭建自己的監控體系，來分析整體業務流量和應對異常報警。但隨著系統複雜性的提高，微服務的成熟，監控又有了新的問題需要解決，如上下文的鏈路關係、跨系統的故障定位等相關問題。

為減輕公司業務線資源和開發的監控壓力，愛奇藝技術產品團隊研發了一套全鏈路自動化監控平臺，可以提供統一的監控標準和基礎的監控能力，增強故障定位和深度分析能力，提升監控準確性和透明性，本文將基於監控一些經驗，和大家分享全鏈路自動化監控平臺。

近些年ELK Stack、Cat、以及Google Dapper等監控工具在機器資料分析實時日誌處理領域，也都在嘗試解決一些新問題，我們對此做了分析，總結來看，ELK Stack重依賴ES，儲存能力和查詢能力較難擴充套件。Cat側重於Java後端。基於Google Dapper的全鏈路監控思想相對成熟，但多數開源實現的介紹缺少深度分析，查詢效能比較差，見下圖：

另一方面看，隨著微服務的成熟，實時監控更加重要，Prometheus等基礎監控解決了基本指標和報警問題，部分全鏈路監控的實現解決鏈路追蹤的問題，但兩者各司其職，是互相的補充，卻未融成統一的全鏈路監控平臺。

基於對這些工具的分析，我們以現有的基礎監控和日誌採集為基礎，融合Google Dapper思想，形成了統一的全鏈路自動化監控平臺，並且可靈活快速接入公司的其他業務。對Google Dapper的改造，我們加入了快取和離線處理的部分，大大提升了查詢效能；加入了深度分析部分，能夠自動診斷使用者具體的報障；在改造鏈路UI展示的基礎上，加入了監控指標，在看服務鏈路的同時能看到監控指標，體驗升級並更易發現效能瓶頸，可指導資源伸縮、可看到容量預警。

下面我們總結出全鏈路監控的四部分：鏈路採集、指標採集、日誌採集、深度分析，並在全鏈路監控平臺中一一落地。

圖1整體實踐

圖2全鏈路分析流程

   鏈路採集,分為呼叫關係鏈和服務拓撲兩部分:

• 呼叫關係鏈：兩個系統之間的呼叫，稱之為Span，每個Span會記錄服務資訊和上下文資訊。串聯Span關係的欄位是Trace id，是每個請求產生的唯一演算法值。呼叫鏈是由多個Span組成的有向無環圖（DAG），表示了一次請求的完整處理過程。圖中的每一個節點代表的是一個Span，圖中的邊表示的是不同服務（或服務內部）的呼叫關係。透過深度分析Span，我們就能得到每個請求的呼叫鏈。

圖3 有向無環圖DAG

圖4 鏈路採集架構圖

• 我們的設計

1）鏈路分析基礎能力：

① 具備呼叫鏈檢索能力，有具體到介面級別的Trace鏈路，可根據Trace id來檢視呼叫關係。   

② 呼叫關係中包含每個節點的響應時間，請求方法和引數、以及自定義的Tag等資訊，方便查詢和最佳化鏈路。

2）鏈路分析最佳化：

• 服務鏈路拓撲 ELK Stack的Kibana沒有服務拓撲能力。業界的Skywalking、Zipkin等，具備了服務拓撲能力但視覺化比較弱，功能單一，而且目前看到的全鏈路實現，均未加入客戶端節點。

• 我們的設計

包裝了客戶端日誌，在鏈路中加上前端節點；在Skywalking基礎上，升級了UI頁面增強互動和視覺；儲存元件從關係型資料庫改為圖資料庫，使得UI有更多的邏輯展示空間和更快的響應速度。最終補全整體鏈路，提供更友好的視覺化（比如我們支援三層展示：首先業務線、業務線內的服務、服務內的呼叫）。

圖5 業務線維度 

圖6 服務維度   

圖7 服務維度切換檢視  

圖8 監控指標  

在指標採集方面：指標採集的技術，如今Graphite、Prometheus配合時序資料庫的監控體系，都能做到。問題在於每個業務線都有自己的一套監控，比如同樣計算成功率，因為儲存或者效能等方面的影響，演算法有差異（有的是根據總成功數/總請求數，有的在每臺機器的每分鐘的成功率聚合的基礎上彙總做算數平均或者加權平均）。因此監控統一，整體架構的資料分析才可描述。

• 我們的設計

• 在日誌採集方面，分為兩個階段：

1. ELK Stack的日誌監控階段，採用的是Logstash/Beats+Kafka+ES，優點是採集靈活，缺點是ES儲存能力和查詢能力弱。
2. 全鏈路監控方面，比如蘑菇街的實現，採用的是Logstash+Kafka+ES+Hadoop，優點是解決了ES儲存能力問題，缺點是未解決查詢能力問題。

• 我們的設計
  

圖9 日誌採集流程

• 深度分析在報警方面，普遍的問題，比如OPS、RT、Success Rate、P999，僅能反應服務整體質量。但具體到使用者的個人APP問題，傳統方式都是開發手動排查，需要良好的架構技術和豐富的業務經驗，排查週期長且結果模糊。這是業界存在的痛點。
• 我們的設計

圖10 環環相扣的診斷

① 對接客戶端錯誤和客服系統使用者反饋，將粒度細到單條記錄作為分析的起點，再根據鏈路關係，離線聚合該起點對應所有後續鏈路服務的日誌。其中，我們聚合的索引是Device id，因為有的服務無法獲得該引數，我們最佳化了Trace id演算法(包含Device id)。首先在服務請求的開始，會全量自動生成Trace id，保證後方服務都有Trace id，從而後方服務能從中提取到Device id。

② 所有的節點日誌，進行多維度最優診斷，直到發現錯誤點或遍歷結束。配合Easy Rule在不同的場景制定專門的診斷策略，靈活可擴充。策略之外，我們有對使用者的行為分析，用來展示使用者在一段時間內的請求和行為。

圖11 整體架構設計

目前在打通客戶端和後臺鏈路的基礎上，相容不同系統架構和後臺服務實現，各個流程自動化，單條業務線採集OPS高峰在每秒幾十萬，Hikv資料量在幾T（壓縮後平均資料長度不到1k），ES每小時資料量在幾百G左右（總量看儲存多少小時），Hbase一天落地日誌量幾十T。鏈路、指標、日誌採集和深度分析均達到準時。

① 統一的指標監控

② 豐富的報警機制

③ 報警的根因定位

④ 資源的擴容分析

⑤ 日誌的自動分析

⑥ 跨機房的呼叫檢測

自愛奇藝全鏈路自動化監控平臺上線以來，填補移動端在鏈路監控上的空白，擴大了可監控的範圍，提高了問題定位效率，從鏈路的角度保障移動端的整體服務質量。透過統一技術規範，目前全鏈路是公司微服務參考架構的一部分。透過自動識別依賴關係，使鏈路視覺化，能夠分鐘級的聚合指標和報警，及時發現故障點和其中的依賴。透過基於規則引擎的自動化分析，解決錯誤日誌儲存時間短導致無法定位的問題，錯誤日誌查詢效率提升50%以上，提高了客訴響應速度。並且呼叫鏈路的分析，精準輔助發現鏈路效能瓶頸進行最佳化，提升整體架構質量。

未來，我們會在當前基礎上，加入全鏈路壓測（普通壓測基本是單系統壓測）的功能，使系統具備線上壓測和模擬壓測的能力，提前感知系統負載能力，使系統的資源伸縮智慧化，以應對假期或者熱劇等突發流量。