愛奇藝微服務監控的探索與實踐

作為一執行緒序猿，是否有過類似經歷？新接手一個系統，各介面入口流量是多少，又是哪些業務方在呼叫？系統大量異常報警，如何快速鎖定影響範圍，恢復故障並定位問題？介面呼叫超時，究竟是客戶端問題還是服務端響應慢，還是網路波動來背鍋？

監控的重要性不言而喻，可是接入監控的額外工作又讓人望而卻步？每天編寫程式碼之餘，又要花多少時間定位線上問題？自己負責的系統故障，是否要等呼叫方反饋才知道？本文分享愛奇藝有關微服務監控的實踐和思考。

如文章《愛奇藝影片後臺從"單兵作戰"到"團隊協作"的微服務實踐》 所述，2018年愛奇藝資訊流技術團隊基於Spring Cloud和公司服務雲元件，實現了業務系統的全面微服務化。微服務的拆分，一方面提升了服務負責人的ownership，助力業務快速迭代。另一方面，隨著微服務的增加，監控成本隨之增加，構建簡單有效的微服務監控體系的訴求愈發強烈。本文從以下3個方面展開介紹。

• 背景&初探：介紹建設微服務監控體系的背景，微服務監控體系建設初期的探索和嘗試。

• 演進&實踐：基於早期微服務監控探索和思考，落地微服務微服務監控體系的具體實踐。

• 總結&展望：總結微服務監控建設過程中的實踐和思考，以及工作規劃。

背景&初探

經過一年多的野蠻生長，資訊流團隊微服務發展快速，人均負責5個微服務以上，為了全面瞭解每個微服務執行情況，第一時間感知微服務異常，快速定位線上問題，提高運維效率，微服務建設初期我們嘗試了多種監控方案。

這個階段，我們對微服務監控缺少系統的理論認知和實踐經驗，所以更多是對已有的監控基礎設施和框架低成本的整合和適配。

下面分別從日誌監控，Hystrix監控，Actuator監控，撥測監控5個方面介紹。

日誌監控

基於日誌的監控方案，原理如下圖，業界技術方案成熟（例ELK），公司也提供了通用解決方案（Venus），容易落地。缺點是，日誌監控鏈路較長，延遲時間大，報警可能不夠及時。

Hystrix監控

很長一段時間Hystrix是服務熔斷降級監控的代名詞，Spring Cloud應用中使用hystrix極致易用，從低成本埋點，到配置動態調整，再到原生的視覺化Dashboard，使用成本都很低。缺點是，指標資料原生沒有持久化，二次開發有一定成本。

下圖描述基於Hystrix監控的方案。

Actuator 監控

Actuator端點是Spring Boot應用開發者的最大福利之一，可以零成本瞭解單例項執行情況。缺點是，同服務多例項指標聚合，指標持久化，指標時序視覺化，都需要二次開發。下圖描述Actuator端點監控的方案。

撥測監控

對於面向使用者的服務，使用者所處網路，地域差異性很大，應用本身可用不代表使用者可以正常使用服務，這就需要從使用者角度，對服務可用性進行定時撥測。

下圖描述撥測監控的方案，主要包括微服務例項自發的健康檢查和各撥測點定時撥測。

鏈路監控

鏈路監控既可用於呼叫鏈路分析，快速定位具體問題，又可用於梳理服務拓撲結構和依賴合理性，是微服務監控必不可少的一環。

我們使用公司服務雲提供的日誌收集元件Venus（如前所述）和鏈路跟蹤元件Rover（基於Skywalking+Brave）實現該功能。實現方案如下圖所示。

其中，接入固定成本表示為引入相應監控而產生的一次性固定投入，包括學習調研，二次開發，整合適配等成本。接入邊際成本表示每新增一個微服務或一個監控指標，新產生的開發配置成本。幾種監控方案對比和適用場景如下表所示。

監控型別	接入固 定成本	接入邊 際成本	時效性	持久化 可追溯	適用場景
日誌監控	極低， 基於現有日誌收集系統	中，日誌埋點、解析有一定成本	秒級，鏈路長，有時延遲較大	日誌持久化，可檢視歷史	時效性要求不高的監控；具體問題排查
Hystrix 監控	低， 需要部署Hystrix Dashboard	低，簡單配置	秒級	需二次開發	依賴介面實時監控；熔斷降級
Actuator 監控	低，需要部署Spring Boot Admin	無，應用內建	秒級	需二次開發	單例項指標檢視
撥測監控	無，基於公司雲撥測服務	低，簡單配置	分鐘級，取決於撥測間隔	有報警歷史	面向使用者服務可用性定時撥測
鏈路監控	中，需要適配各種中介軟體	低，簡單配置	秒級，依賴日誌流	可以	跨系統呼叫鏈路分析

演進&實踐

如上所述，我們在微服務監控建設初期嘗試了多種監控方案，實現了不同場景下的監控需求，也遇到了新的問題。概括起來，有以下幾個：

• 缺少對監控項的統一認知和定義

• 重複性埋點配置工作，監控成本高

• 各種監控方案簡單組合，視覺化分散，報警不統一

• 日誌監控，報警時效性無保障

比如，每新增一個監控指標，需要把接入，埋點，視覺化，報警，從頭來一遍，隨著微服務和指標增加，這種重複性工作嚴重製約了監控體系的推廣落地。特別是metrics監控，指標繁雜，維度多變，應用廣泛。

為此，建設一套監控模型統一，接入成本低，視覺化集中管理，報警時效性高，監控指標全面的微服務監控體系勢在必行。下面著重介紹資訊流監控系統針對metrics監控的實踐。

資訊流Metrics監控在Prometheus基礎上，以構建簡單易用的監控系統為目標，對Spring Cloud框架進行適配整合和定製開發。整體結構如上圖，我們主要做了以下工作。

監控模型

監控指標是監控系統的基本物件，監控哪些指標，如何定義描述這些指標，是首要解決的問題。我們透過引入指標-維度-數值多維度資料模型，對常用監控指標和維度進行梳理和定義，形成對監控物件的統一描述和共識，為後續實現維度靈活聚合、定義統一的視覺化模板和報警模板奠定基礎。

通用指標定義：

指標	說明
QPS	系統每秒處理業務請求量，反應系統的容量
TP指標	TP99、TP95、MEAN等，反應的是系統的時效性
錯誤量	http錯誤響應碼的次數，方法呼叫異常次數等，反應系統的錯誤面
資源使用率	CPU利用率、記憶體利用率、磁碟利用率等，反應系統資源利用面

通用維度定義：

維度	說明
service_name	服務名，例:Order
dc	機房,例：bjdx
instance	服務例項，例：1.1.1.1:2222
url	介面API，例：/order/list
method	方法簽名
status	http 響應碼

定製擴充套件

自動接入&埋點

前期我們嘗試了多種監控方案，發現能夠順利推廣落地的，都有一個共同點，就是服務接入監控的成本很低。最好是不要求應用做任何改動，就可以自動接入，享受監控系統帶來的便利。為此我們做了以下工作：

• 每個服務引入sdk自動完成通用指標（Http請求，JVM指標等）採集，並暴露指標拉取端點

• 每個服務自動註冊到Eureka註冊中心

• Eureka增加Adapter，提供監控系統可識別的介面方法

• 監控系統從註冊中心，自動發現要監控的服務例項列表

• 監控系統定期從服務指標端點拉取監控資料

宣告式方法監控

很多情況下，需要對某些業務方法耗時進行監控，傳統的埋點方式是在方法入口和出口新增監控程式碼，業務程式碼侵入高，開發成本高。

PUSH模式擴充套件

如前所述，Prometheus是用PULL模式獲取應用埋點資料，但是有的場景下PULL模式並不適用（比如短生命週期的任務），因此我們基於Prometheus提供的Pushgateway元件，實現PUSH模式獲取監控埋點資料。

一種應用場景是，實時收集各個服務日誌流中的異常資訊。我們監聽日誌採集的Kafka訊息，Flink實時解析出服務異常名稱，將各個服務產生的異常實時推送到監控系統，並在Grafana上集中展示。基於Pushgateway的異常監控方案及效果圖如下。

集中視覺化

不同的監控系統，往往會提供不同的視覺化方案。分散的視覺化，不利於監控資料的集中展示和全域性問題分析。我們使用Grafana實現所有微服務，所有指標的集中視覺化。

每個微服務使用統一的監控模板，集中展示各服務入口流量、內部方法、JVM等相關指標。Dashboard模板主要包含以下模組：

• 維度篩選模組

• JVM和系統指標模組

• 入口流量機房分佈&狀態碼&QPS&響應延時模組

• 方法監控指標模組

統一報警

基於前邊定義的通用指標和維度，對所有指標配置預設的報警規則，同時支援自定義報警規則和閾值。基於Grafana Web hook將報警通知傳送給Alert Manager，Alert Manager對報警進行相同合併、重複過濾、並格式化為統一報警模板後，投遞到愛奇藝統一報警平臺，業務owner透過統一報警平臺完成報警訂閱。統一報警方案及報警樣例如下圖。

以上所述，愛奇藝資訊流監控整體方案總結如下。

自下至上包括4層：

• 監控物件既包括常駐程式微服務，也包括短生命週期的非常駐程式。

• 指標獲取方式既可以基於Prometheus實時拉取，也可以基於Venus日誌收集，前者用於指標實時獲取，保證監控報警時效性，後者記錄詳細日誌，用於具體問題排查和鏈路分析。

• 監控維度從4個維度監控應用：

1. Metrics監控宏觀上檢測系統QPS，響應耗時，錯誤率和資源利用率；

2. 撥測監控從使用者角度監控服務可用性；

3. 鏈路監控提供單個請求完整生命週期的跟蹤路徑，專門應對微服務架構帶來的分散式呼叫複雜性；

4. 日誌查詢提供應用監控最精細化的資訊，用於具體問題排障。

• 集中管理，集中視覺化和統一報警管理，在最上面一層，便於排查問題時全面快速獲取應用所有監控報警資訊。另外，微服務監控的統一認知和必要的流程規範，貫穿監控系統落地始終。

監控系統落地1年多，新增服務基本實現零成本100%接入自動埋點、集中視覺化和統一報警，業務owner不需要為接入監控做額外工作，就可以享受監控帶來的各種便利；系統異常發生後，可以做到秒級收到報警，藉助微服務監控大盤，配合鏈路監控和日誌查詢，分鐘級確認異常影響範圍並定位問題，大大減少故障恢復時間，提升運維效率；目前該方案也在多個其他團隊推廣落地。

總結&規劃

本文介紹了愛奇藝資訊流團隊微服務監控的探索和實踐，涵蓋了日誌監控，Hystrix監控，撥測監控，鏈路監控，Prometheus監控等，從最初的多種監控方案相容幷包，到基於多維度資料模型和集中視覺化的定製開發。不能簡單說，後面的監控方案比前期的好，而是在微服務監控不同發展階段，監控體系建設投入和收益的折中選擇。下面是微服務監控探索過程中一些心得。

1. 簡單有效。簡單有效是評測監控系統好壞的最高準則，埋點是否簡單甚至可省去，是否存在重複性的配置工作，都會影響監控方案能否最終落地推廣。好的監控方案一定是，沒有故障時，開發人員無感知，出現故障時，想看的指標都能拿到。

2. 整合定製。業界和公司提供了固定場景下的監控框架和方案，基於這些成熟的方案和基礎設施，會大大減少監控系統建設投入；另一方面，必要的定製開發封裝，會進一步推動自動化監控落地。

3. 集中管理。考慮監控指標的多樣性（系統，應用，業務等），不同監控方案關注點不同，指標埋點，收集，獲取未必僅用一套，但是視覺化應該儘可能集中，方便統一管理和全域性分析。

4. 流程規範。微服務監控不是一個人或少數幾個人的事，也不應該微服務上線後才被關注，它需要每位微服務owner，從編碼，甚至設計階段，就要考慮監控指標和維度。為了減少監控帶來的額外負擔，保障落地效果，必要的流程規範和分享培訓是必要的。

以上是監控實踐的階段性探索實踐總結，未來還有很多方面需要持續的最佳化和改進，例如靈活的報警規則，恰如其分的報警，更低成本的埋點、視覺化，服務質量評測報告等。另外，依託大資料分析和人工智慧能力，系統異常檢測，根因分析，智慧合併，故障預測和自恢復技術愈發成熟，推動AI賦能數字化運維落地也是我們努力的方向。