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有更多的邏輯展示空間和更快的響應速度。最終補全整體鏈路，提供更友好的可視化（比如我們支持三層展示：首先業務線、業務線內的服務、服務內的調用）。
此外，在鏈路的每個節點都加入了監控指標，包括機器性能、業務指標等聚集。在鏈路上同時看到監控，便於直觀分析架構瓶頸。同時支持自定義指標，可對接現有指標（對基礎指標的擴展）。當存在異常節點時，除了報警，在可視化中的顏色也醒目（Warn黃、Error紅），能從全局維度發現瓶頸點，指導現有服務伸縮或流控降級處理。
圖8 監控指標
我們將前後端的服務依賴鏈路，總結爲邏輯鏈路，並正在加入另外一層物理鏈路，來顯示網絡/機房的拓撲。
指標採集
在指標採集方面：指標採集的技術，如今Graphite、Prometheus配合時序數據庫的監控體系，都能做到。問題在於每個業務線都有自己的一套監控，比如同樣計算成功率，因爲存儲或者性能等方面的影響，算法有差異（有的是根據總成功數/總請求數，有的在每臺機器的每分鐘的成功率聚合的基礎上彙總做算數平均或者加權平均）。因此監控統一，整體架構的數據分析纔可描述。
我們的設計
主要是優化流程，統一監控指標，各業務線根據規範投遞數據。進而統一監控報警算法，比如Success Rate、QPS、RT、P999、抖動報警、異常檢測、容量預估等。
統一監控，讓各業務線看的說的都是一回事，數據準確後，對比更發現問題。此外，也減少各業務線爲監控投入的開發成本。
指標的結果，會配合展示在上面講的鏈路上，體驗升級，易於發現整體架構瓶頸。
日誌採集
在日誌採集方面，分爲兩個階段：
ELK Stack的日誌監控階段，採用的是Logstash/Beats+Kafka+ES，優點是採集靈活，缺點是ES存儲能力和查詢能力弱。
全鏈路監控方面，比如蘑菇街的實現，採用的是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%以上，提高了客訴響應速度。並且調用鏈路的分析，精準輔助發現鏈路性能瓶頸進行優化，提升整體架構質量。
未來，我們會在當前基礎上，加入全鏈路壓測（普通壓測基本是單系統壓測）的功能，使系統具備線上壓測和模擬壓測的能力，提前感知系統負載能力，使系統的資源伸縮智能化，以應對假期或者熱劇等突發流量。
掃一掃下方二維碼，更多精彩內容陪伴你！
