vivo 服務端監控體系建設實踐

作者：vivo 互聯網服務器團隊 - Chen Ningning

本文根據陳寧寧老師在 “2022 vivo 開發者大會 " 現場演講內容整理而成。公衆號回覆【2022 VDC】獲取互聯網技術分會場議題相關資料。

經過幾年的平臺建設，vivo 監控平臺產品矩陣日趨完善，在 vivo 終端龐大的用戶羣體下，承載業務運行的服務數量衆多，監控服務體系是業務可用性保障的重要一環，監控產品全場景覆蓋生產環境各個環節。從事前發現，事中告警、定位、恢復，事後覆盤總結，監控服務平臺都提供了豐富的工具包。從以前的水平拆分，按場景建設，到後來的垂直劃分，整合統一，降低平臺割裂感。同時從可觀測性、AIOps、雲原生等方向，監控平臺也進行了建設實踐。未來 vivo 監控平臺將會向着全場景、一站式、全鏈路、智能化方向不斷探索前行。

監控服務平臺是自研的、覆蓋全場景的可用性保障系統。經過多年深耕，vivo 監控團隊已經成體系構築起一整套穩定性保障系統，隨着雲原生可觀測技術變革不斷深化，監控團隊如何掌舵前行？下面就平臺的建設歷程、思考、探索，做一下簡單介紹。

一、監控體系建設之道

1.1 監控建設歷程

回顧監控建設歷程，最初採用 Zabbix，與告警中心的組合實現簡易監控。隨着業務的發展在複雜監控場景和數據量不斷增長的情況下，這種簡易的組合就顯的捉襟見肘。所以從 2018 年開始我們開啓了自研之路，最開始我們建設了應用監控、日誌監控、撥測監控解決了很大一部分監控場景沒有覆蓋的問題；2019 年我們建設了基礎監控、自定義監控等，完成了主要監控場景的基本覆蓋；2020 年我們在完善前期監控產品的同時，進一步對周邊產品進行了建設；隨着 AI 技術的不斷成熟，我們從 2021 年開始也進行了轉型升級，先後建設了故障定位平臺、統一告警平臺有了這些平臺後我們發現，要想進一步提升平臺價值，數據和平臺的統一至關重要；所以從 2022 年開始建設了統一監控平臺，也就是將基礎監控、應用監控和自定義監控進行了統一，統一監控包含了統一配置服務和統一檢測服務。從監控的建設歷程來看，我們一路覆蓋了 IaaS、PaaS、DaaS、CaaS 等平臺。我們的職能也從 DevOps 向 AIOps 邁進。

1.2 監控能力矩陣

講了監控的發展歷程，那麼這些監控產品在我們的生產環境中是如何分佈的呢？要想支撐數以萬計的業務運行，需要龐雜的系統支撐，服務器、網絡環境、基礎組件等，都需要監控系統保障它的穩定性。我們將監控的對象分爲五層，在基礎設施層，包含了網絡設備、服務器、存儲硬件等，這一層我們通過 VGW 監控對網絡設備進行監控，VGW 是 Vivo Gateway 的縮寫，類似於 LVS；通過自定義監控，對機房進行監控；系統服務器層，我們定義的監控對象是服務運行依賴的環境，通過主機監控對物理機、虛擬機等監控，當前容器在雲原生技術體系中，已然成爲微服務運行的最佳載體，所以對容器的監控必不可少；系統服務層，包含了各種數據庫產品、大數據組件等，在這一層主要通過自定義監控檢測、告警；業務應用層，主要有應用服務，我們通過應用監控對業務鏈路信息進行監控；客戶體驗層，我們定義了端上的訪問質量，由宙斯平臺實現監控。前面我們講了監控能力矩陣，下面我們具體介紹一下監控的範圍和整個平臺的能力。

1.3 監控對象範圍

監控對象涉及網絡、主機、基礎服務等。面對各地機房我們做到了監控全覆蓋，爲滿足各類環境部署訴求，我們可以做到針對不同環境的監控。我們支持多種採集方式，SDK 和 API 採集主要應用在自定義監控場景，Agent 主要採集主機類指標，採集上來的時序數據經過預聚合、統一的數據清洗，然後存儲在 TSDB 數據庫。針對海量數據存儲我們採用了數據降精，寬表多維多指標等方案。我們常用的檢測算法有恆值檢測、突變檢測、同比檢測等，同時還支持了無數據檢測、多指標組合檢測，檢測出現的異常我們會形成一個問題，問題在經過一系列的收斂後發出告警，我們有多種告警通道，支持告警合併、認領、升級等，需要展示的指標數據我們提供了豐富的自定義指標看板，對使用頻率高 固化場景，我們提供了模板化配置方案。有了完備的監控體系，那麼系統的關鍵指標和監控對象體量如何？

1.4 監控系統體量

當前監控服務體系保障着 x 萬 + 的主機實例，x 萬 + 的 DB 實例，每天處理 x 千億條各類指標和日誌，對 x 千 + 的域名做到秒級監控，對 x 萬 + 的容器實例監控，每天從統一告警發出的各類告警達到 x 十萬 + ，對主機實例的監控覆蓋率達到 x %，監控平臺通過不斷的探索實踐，實現了對海量數據計算存儲，當前對核心業務的告警延遲在 x 秒以內，告警召回率大於 x %。

1.5 監控系統面臨挑戰

雖然現階段取得了一些成果，但是目前仍然面臨很多挑戰，主要分爲三大類：

• 部署環境複雜

  對數以萬計的主機和容器，實時採集 計算是一項困難的事情；面對各地機房監控，部署過程中依賴項多，維護工作複雜；對海量數據計算存儲，保障監控服務穩定性、可用性難度大。

• 平臺系統繁多

  當前系統還存在割裂，用戶體驗不強；數據割裂，沒有從底層融合在一起，對於數據組合使用形成挑戰。

• 新技術挑戰

  首先基於容器的監控方案，對傳統監控方案形成挑戰，當前對 Prometheus 指標存儲處在探索階段，暫時沒有標準的解決方案，但是面對快速增長的數據量，新組件的探索試錯成本相對較高。

二、監控服務體系架構

2.1 產品架構

產品架構的能力服務層，我們定義了採集能力、檢測能力、告警能力等；功能層我們對這些能力做了具體實現，我們將監控分爲主機、容器、DB 等 9 類場景，展示層主要由 Dashboard 提供靈活的圖表配置能力，日誌中心負責日誌查詢，移動端可以對告警信息進行認領、屏蔽。

2.2 技術架構

技術架構層分爲採集、計算、存儲、可視化幾大塊，首先在採集層我們通過各種採集方式進行指標採集；上報的數據主要通過 Bees-Bus 進行傳輸，Bees-Bus 是一款公司自研的分佈式、高可用的數據收集系統，指標經過 Bees-Bus 之後寫入 Kafka，隨着 Pulsar 的受關注度與使用量的顯著增加，我們也在這方面進行了一定的探索；計算層我們經歷了 Spark、Flink、KafkaStream 幾個階段的探索，基本實現了計算層技術棧收歸到 KafkaStream；數據主要存儲在 Druid，當前有 190 + 節點的 Druid 集羣。Opentsdb 和 Hive 早期應用在主機監控場景，隨着業務發展其性能已經不能勝任當前的寫入和查詢需求，所以逐步被捨棄。

當前我們選用了 VictoriaMetrics 作爲 Prometheus 的遠端存儲，日誌信息存儲在 ES 中，目前我們有 250 + 的 ES 節點。服務層中各類監控場景的元數據，都由統一元數據服務提供；各類檢測規則、告警規則都由統一配置服務維護，統一告警服務則負責告警的收斂、合併、發送等。Grafana 則主要用作自監控告警。

2.3 交互流程

在監控架構的基礎上，我們介紹一下整體交互流程，採集規則由統一元數據服務管理，並主動下發到 VCS-Master，VCS-Master 主要用來任務下發，Agent 執行結果數據接收，任務查詢和配置管理等，Agent 會定期從 VCS-Master 拉取緩存的採集規則，指標經過 Bees-Bus 雙寫到 Kafka，由 ETL 程序對指標數據消費，然後做清洗和計算，最後統一寫入到存儲服務中，統一配置服務下發檢測規則到異常檢測服務，檢測出的異常信息推送到 Kafka，由告警代理服務對異常信息進行富化，處理好的數據推到 Kafka，然後由統一告警服務消費處理。在存儲服務之上，我們做了一層查詢網關，所有的查詢會經過網關代理。

三、可用性體系構建與保障

3.1 可用性體系構建

前面說了監控服務體系整體架構，那麼監控產品如何服務於業務可用性。我們將業務穩定性在時間軸上進行分割，不同的時段有不同的系統保障業務可用性，當前我們主要關注 MTTD 和 MTTR，告警延遲越小發現故障的速度也就越快，系統維修時間越短說明系統恢復速度越快，我們將 MTTR 指標拆解細化然後各個擊破，最終達成可用性保障要求。vivo 監控服務體系提供了，涵蓋在穩定性建設中需要的故障預防、故障發現等全場景工具包，監控平臺提供了產品工具，那麼與運維人員，研發人員是怎樣協作配合的？

3.2 系統可用性保障

當監控對象有問題時，監控系統就會發送告警給運維人員或業務開發，他們通過查看相關指標修復問題。使用過程中運維人員的訴求和疑問，由監控平臺產品和開發協同配合解決，我們通過運營指標，定期梳理出不合理的告警，將對應的檢測規則同步給運維同學，然後制定調整計劃，後期我們計劃結合智能檢測，做到零配置就能檢測出異常指標。通過監控開發、運維人員和業務開發一起協同配合，保障業務的可用性。

3.3 監控系統可用性

除了保障業務可用性外，監控系統自身的可用性保障也是一個重要的課題。爲了保障 Agent 存活，我們構建了多種維活機制，保障端上指標採集正常。數據經過 Bees-Bus 之後，會雙寫到兩個機房，當有一個機房出現故障，會快速切到另一個機房，保障核心業務不受損。數據鏈路的每一層都有自監控。監控平臺通過 Grafana 監控告警。

3.4 複雜場景下依託監控解決問題手段 監控能力矩陣

隨着公司業務發展，業務模型、部署架構越來越複雜，讓故障定位很困難，定位問題成本高。而監控系統在面對複雜、異構、調用關係冗長的系統時就起到了重要作用。在問題發現階段，例如多服務串聯調用，如果某個階段，出現耗時比較大的情況，可以通過應用監控，降低問題排查難度。在告警通知階段，可以通過統一告警對異常統一收斂，然後根據告警策略，通知給運維或者開發。問題定位時，可以利用故障定位服務找到最可能出現問題的服務。解決問題時，類似磁盤打滿這種比較常見的故障，可以通過回調作業快速排障。覆盤改進階段，故障管理平臺可以統一管理，全流程覆盤，使解決過程可追溯。預防演練階段，在服務上線前，可以對服務進行壓力測試，根據指標設置容量。

四、行業變革下的監控探索實踐及未來規劃

4.1 雲原生：Prometheus 監控

當前行業正迎來快速變革，我們在雲原生、AIOps、可觀性等方向均進行了探索實踐。未來我們也想緊跟行業熱點，繼續深挖產品價值。隨着 Kubernetes 成爲容器編排領域的事實標準，Prometheus 因爲對容器監控良好的適配，使其成爲雲原生時代，容器監控的事實標準。下面我們介紹一下整體架構，我們將容器監控分爲容器集羣監控和容器業務監控，首先對於容器集羣監控，每個生產集羣都有獨立的監控節點，用於部署監控組件，Prometheus 按照採集目標服務劃分爲多組，數據存儲採用 VictoriaMetrics，我們簡稱 VM，同一機房的 Prometheus 集羣，均將監控數據 Remote-Write 到 VM 中，VM 配置爲多副本存儲。通過撥測監控，實現對 Prometheus 自監控，保障 Prometheus 異常時能收到告警信息。容器業務監控方面，Agent 部署在宿主機，並從 Cadvisor 拉取指標數據，上報到 Bees-Bus，Bees-Bus 將數據雙寫到兩個 Kafka 集羣，統一檢測服務異步檢測指標數據，業務監控指標數據採用 VM 做遠端存儲，Dashboard 通過 Promql 語句查詢展示指標數據。

4.2 AIOps：故障定位

當前業界對 AIOps 的探索，大部分在一些細分場景，我們也在故障定位這個方向進行了探索。分析過程中首先通過 CMDB 節點樹，選定需要分析的項目節點，然後選擇需要分析的時段，就可以按組件和服務下鑽分析，通過計算得出每個下游服務的波動方差，再利用 K-Means 聚類，過濾掉波動較小的聚類，找到可能出現異常的服務或組件。分析過程會形成一張原因鏈路圖，方便用戶快速找到異常服務，分析結果會推薦給用戶，告知用戶最可能出現異常的原因。詳情查看功能可以看到被調用的下游服務、接口名、耗時等信息。

4.3 可觀測性：可用性大盤

由於 CNCF 在雲原生的定義中提到了 Observerbility，所以近兩年可觀性，成了技術圈很火熱的關鍵詞。當前業界基於 Metrics、Logs、Traces 對可觀測性形成了一定共識。谷歌也給出了可觀測的核心價值就是快速排障。我們認爲指標、日誌、追蹤是實現可觀測性的基礎，在此基礎上將三者有機融合，針對不同的場景將他們串聯在一起，實現方便快捷的查找故障根因，綜上我們建設了可用性大盤，它能查看服務的健康狀況，通過下鑽，可以看到上下游服務依賴關係、域名健康狀況、後端服務分佈等。通過串聯跳轉等方式可以看到對應服務的日誌和指標信息。

4.4 場景串聯

未來我們希望在場景串聯、可觀測性、服務能力化進一步探索，深挖產品價值。場景串聯上：

• 首先我們希望告警能夠與故障定位平臺串聯，幫助用戶快速找到故障根因，縮短排查時間 ；

• 告警記錄能夠一鍵轉爲事件，減少數據鏈路中人爲操作的環節，保障數據的真實性；

• 我們希望能與 CMDB 等平臺打通，將數據價值最大化。 

4.5 統一可觀測

現在，vivo 監控服務體系的可觀測產品沒有完全融合在一起，所以後續我們希望構建統一可觀測平臺：

• 在一元場景中，可以單獨查看指標、日誌、追蹤信息；

• 在轉化場景中，能夠通過日誌獲得指標數據，對日誌的聚合和轉化得到追蹤，利用調用鏈的分析，獲得調用範圍內的指標。通過指標、日誌、追蹤多個維度找到故障的源頭；

• 在二元場景，我們希望日誌和指標、日誌和追蹤、追蹤和指標能夠相互結合，聚合分析。

4.6 能力服務化

目前監控有很多服務，在公司構建混合雲平臺的大背景下，監控系統的服務應該具備以能力化的方式提供出去。未來我們希望指標、圖表、告警等，以 API 或者獨立服務的方式提供能力，例如在 CICD 服務部署過程中，就可以通過監控提供的圖表能力，看到服務部署時關鍵指標變化情況，而不需要跳轉到監控服務查看指標信息。

最後，我們希望監控能更好的保障業務可用性，在此基礎上，我們也希望通過監控系統提升業務服務質量。

本文由 Readfog 進行 AMP 轉碼，版權歸原作者所有。
來源：https://mp.weixin.qq.com/s/03i9N9uuvfxiUVBMg5TTug