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

1

前言

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

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

2

背景

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

維度	ELK Stack	Cat	Pinpoint/SkyWalking
視覺化	弱	一般	一般
報表	豐富	豐富	中
指標	無	有	無
拓撲	無	簡單依賴圖	好
埋點	Logstash/Beats	侵入	無侵入，位元組碼增強
大查詢	弱	弱	弱
社群	好，有中文	好，文件豐富	一般，文件缺，無中文
案例	很多公司	攜程、點評、陸金所、獵聘網	暫無
源頭	ELK	aBay CAL	Google Dapper

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

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

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

圖1整體實踐

3

平臺介紹

總體概覽

• 鏈路採集包括呼叫鏈和服務拓撲，是全鏈路分析的串聯器。

• 指標採集整合到服務鏈路上，使全鏈路具備基礎監控能力。

• 日誌採集的資料來源，也是全鏈路分析的資料來源。

• 深度分析包括離線、線上模組，滿足全鏈路的問題定位需求。

圖2全鏈路分析流程

鏈路採集

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

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

圖3 有向無環圖DAG

呼叫鏈需要先接入，然後透過Agent採集日誌進行深度分析，接入過程保證低損耗（對系統的影響足夠小）、良好的延展性（未來幾年的發展中，完全能把控住），接入方式有兩種：
        ① 程式碼侵入模式
        按照規範，在相關元件手動埋點投遞。
        ② 無侵入模式（保證應用級的透明）
        支援Java、Go、Lua等Agent，原理採用探針技術，對客戶端應用程式沒有任何程式碼入侵，使用方便易於對接。

圖4 鏈路採集架構圖

• 我們的設計

1）鏈路分析基礎能力：

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

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

2）鏈路分析最佳化：

①每次查詢加入條件，解決全表掃描帶來的響應延遲。

② 增加互動能力，老站點上的摺疊之類的操作都不是很方便。

③ Skywalking支援的無侵入Agent不完整，我們對一些框架和版本做了二次開發。

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

• 我們的設計

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

圖5 業務線維度 

圖6 服務維度   

圖7 服務維度切換檢視  

此外，在鏈路的每個節點都加入了監控指標，包括機器效能、業務指標等聚集。在鏈路上同時看到監控，便於直觀分析架構瓶頸。同時支援自定義指標，可對接現有指標（對基礎指標的擴充套件）。當存在異常節點時，除了報警，在視覺化中的顏色也醒目（Warn黃、Error紅），能從全域性維度發現瓶頸點，指導現有服務伸縮或流控降級處理。

圖8 監控指標  

我們將前後端的服務依賴鏈路，總結為邏輯鏈路，並正在加入另外一層物理鏈路，來顯示網路/機房的拓撲。

指標採集

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

• 我們的設計

主要是最佳化流程，統一監控指標，各業務線根據規範投遞資料。進而統一監控報警演算法，比如Success Rate、QPS、RT、P999、抖動報警、異常檢測、容量預估等。

統一監控，讓各業務線看的說的都是一回事，資料準確後，對比更發現問題。此外，也減少各業務線為監控投入的開發成本。

指標的結果，會配合展示在上面講的鏈路上，體驗升級，易於發現整體架構瓶頸。

日誌採集

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

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

• 我們的設計
  

上線初，雖然嘗試了用Spark/Flink這些大資料工具來採集，但OPS太大，依然存在延遲。我們做了一些最佳化，最終方案如下圖示： 

圖9 日誌採集流程

落地項：

① 客戶端日誌，透過Http最終投遞到Kafka。後端日誌，採用Logstash自動採集。

② 當資料收集到Kafka時，根據流量大小，在Kafka提前做好分割槽。這樣在後面Spark流任務中，避免做Reparation，因為這也是耗時操作。

③採用Spark流任務，設定並行度，分為多個任務並行消費Kafka，存入對應的儲存元件。避免一個流存多個儲存元件，總延時成倍減少。

④ Hikv和ES僅存需要的索引，原始日誌存Hbase，儲存之間採用索引關聯資料。

⑤ ES我們用了多數技術最佳化手段後（比如提高index.refresh_interval的時間間隔、禁止refresh並設定 replicas=0、使用ES自動生成的ids、調整欄位mappings、減小單次批次查詢數目<1w、批次大小和批次時間調整），效能依然不到預期目標。最終在機器層面進行了最佳化，老Cpu升級新Cpu，HDD升級SSD，效果明顯（十年前的和新出的法拉利的區別）。

⑥ 大量日誌需儲存空間落地，考慮快取元件的昂貴，在Hikv中採用kv儲存，因為日誌Value多為字串，我們先做pb（XML相比，其序列化之後的資料量約為1/3到1/10，解析速度快約20-100倍），提高序列化效能。然後針對pb做gzip（5倍壓縮），提高壓縮能力。此外，快取元件的引入，對後面講到的深度分析，能從根本上減少ES查詢壓力，保證架構穩定性。

⑦ 儲存根據業務線隔離，不同的業務線存入自己的儲存，效能之間無影響。目前接入的其中一條業務線日誌儲存OPS高峰在每秒幾十萬，Hikv在幾T（壓縮後平均資料長度不到1k），ES每小時資料量在幾百G（總量看儲存多少小時），Hbase一天落地日誌幾十T。日誌採集達到準實時！

深度分析

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

關聯客戶端和使用者反饋系統，配合鏈路資訊和後端日誌，自動發現故障點，離線+實時聚合診斷，最終實現問題準實時定位。 

圖10 環環相扣的診斷

聚合分析思路

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

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

③ 離線聚合提前解決未來查詢或分析產生的效能壓力。也能在TTL過期時，刪除大量無錯的資訊，節省資源。離線聚合結束前，有實時聚合能力，雙管道保證準實時問題定位。
④ 除了時序資料庫產生的指標，我們會將部分需要聚合的指標存入Clickhouse，這樣能支援更多維度的實施聚合，對監控能力作補充，保證日誌採集和深度分析質量。
在日誌都上報的情況下，該思路覆蓋了常規開發操作所能想到的問題。不斷的補充策略會讓深度分析更智慧。

4

整體架構設計分享

圖11 整體架構設計

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

接入收益：

① 統一的指標監控

② 豐富的報警機制

③ 報警的根因定位

④ 資源的擴容分析

⑤ 日誌的自動分析

⑥ 跨機房的呼叫檢測

5

總結

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

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