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

愛奇藝技術產品團隊發表於2020-07-15

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

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


如文章《愛奇藝影片後臺從"單兵作戰"到"團隊協作"的微服務實踐》 所述,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方法簽名
statushttp 響應碼

定製擴充套件

自動接入&埋點

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

每個服務引入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賦能數字化運維落地也是我們努力的方向。

來自 “ ITPUB部落格 ” ,連結:http://blog.itpub.net/69945252/viewspace-2704730/,如需轉載,請註明出處,否則將追究法律責任。

相關文章