vivo 容器集羣監控系統架構與實踐

vivo 互聯網服務器團隊 - YuanPeng

一、概述

從容器技術的推廣以及 Kubernetes 成爲容器調度管理領域的事實標準開始，雲原生的理念和技術架構體系逐漸在生產環境中得到了越來越廣泛的應用實踐。在雲原生的體系下，面對高度的彈性、動態的應用生命週期管理以及微服務化等特點，傳統的監控體系已經難以應對和支撐，因此新一代雲原生監控體系應運而生。

當前，以 Prometheus 爲核心的監控系統已成爲雲原生監控領域的事實標準。Prometheus 作爲新一代雲原生監控系統，擁有強大的查詢能力、便捷的操作、高效的存儲以及便捷的配置操作等特點，但任何一個系統都不是萬能的，面對複雜多樣的生產環境，單一的 Prometheus 系統也無法滿足生產環境的各種監控需求，都需要根據環境的特點來構建適合的監控方法和體系。

本文以 vivo 容器集羣監控實踐經驗爲基礎，探討了雲原生監控體系架構如何構建、遇到的挑戰以及相應的對策。

二、雲原生監控體系

2.1 雲原生監控的特徵和價值

雲原生監控相比於傳統監控，有其特徵和價值，可歸納爲下表：

zcY5aw

2.2 雲原生監控生態簡介

CNCF 生態全景圖中監控相關的項目如下圖（參考 https://landscape.cncf.io/），下面重點介紹幾個項目：

• Prometheus（已畢業）

Prometheus 是一個強大的監控系統，同時也是一個高效的時序數據庫，並且具有完整的圍繞它爲核心的監控體系解決方案。單臺 Prometheus 就能夠高效的處理大量監控數據，並且具備非常友好且強大的 PromQL 語法，可以用來靈活查詢各種監控數據以及告警規則配置。

Prometheus 是繼 Kubernetes 之後的第二個 CNCF “畢業”項目（也是目前監控方向唯一 “畢業” 的項目），開源社區活躍，在 Github 上擁有近 4 萬 Stars。

Prometheus 的 Pull 指標採集方式被廣泛採用，很多應用都直接實現了基於 Prometheus 採集標準的 metric 接口來暴露自身監控指標。即使是沒有實現 metric 接口的應用，大部分在社區裏都能找到相應的 exporter 來間接暴露監控指標。

但 Prometheus 仍然存在一些不足，比如只支持單機部署，Prometheus 自帶時序庫使用的是本地存儲，因此存儲空間受限於單機磁盤容量，在大數據量存儲的情況下，prometheus 的歷史數據查詢性能會有嚴重瓶頸。因此在大規模生產場景下，單一 prometheus 難以存儲長期歷史數據且不具備高可用能力。

• Cortex（孵化中）

Cortex 對 Prometheus 進行了擴展，提供多租戶方式，併爲 Prometheus 提供了對接持久化存儲的能力，支持 Prometheus 實例水平擴展，以及提供多個 Prometheus 數據的統一查詢入口。

• Thanos（孵化中）

Thanos 通過將 Prometheus 監控數據存儲到對象存儲，提供了一種長期歷史監控數據存儲的低成本解決方案。Thanos 通過 Querier 組件給 Prometheus 集羣提供了全局視圖（全局查詢），並能將 Prometheus 的樣本數據壓縮機制應用到對象存儲的歷史數據中，還能通過降採樣功能提升大範圍歷史數據的查詢速度，且不會引起明顯的精度損失。

• Grafana

Grafana 是一個開源的度量分析與可視化套件，主要在監控領域用於時序數據的圖標自定義和展示，UI 非常靈活，有豐富的插件和強大的擴展能力，支持多種不同的數據源（Graphite, InfluxDB, OpenTSDB, Prometheus, Elasticsearch, Druid 等等）。Grafana 還提供可視化的告警定製能力，能夠持續的評估告警指標，發送告警通知。

此外，Grafana 社區提供了大量常用系統 / 組件的監控告警面板配置，可以一鍵在線下載配置，簡單便捷。

• VictoriaMetrics

VictoriaMetrics 是一個高性能、經濟且可擴展的監控解決方案和時序數據庫，可以作爲 Prometheus 的長期遠程存儲方案，支持 PromQL 查詢，並與 Grafana 兼容，可用於替換 Prometheus 作爲 Grafana 的數據源。具有安裝配置簡單、低內存佔用、高壓縮比、高性能以及支持水平擴展等特性。

• AlertManager

AlertManager 是一個告警組件，接收 Prometheus 發來的告警，通過分組、沉默、抑制等策略處理後，通過路由發送給指定的告警接收端。告警可以按照不同的規則發送給不同的接收方，支持多種常見的告警接收端，比如 Email，Slack，或通過 webhook 方式接入企業微信、釘釘等國內 IM 工具。

圖片

2.3 如何搭建一套簡單的雲原生監控系統

上文了解了雲原生監控領域的常用工具後，該如何搭建一套簡單的雲原生監控系統？下圖給出了 Prometheus 社區官方提供的方案：

圖片

（出處：Prometheus 社區）

上述系統展開闡述如下：

• 所有監控組件都是以雲原生的方式部署，即容器化部署、用 Kubernetes 來統一管理。

• Prometheus 負責指標採集和監控數據存儲，並可以通過文件配置或 Kubernetes 服務發現方式來自動發現採集目標。

• 應用可以通過自身的 Metric 接口或相應的 exporter 來讓 Prometheus 拉取監控數據。

• 一些短暫的自定義採集指標，可以通過腳本程序採集並推送給 Pushgateway 組件，來讓 Prometheus 拉取。

• Prometheus 配置好告警規則，將告警數據發送給 Alertmanager，由 Alertmanager 按照一定規則策略處理後路由給告警接收方。

• Grafana 配置 Prometheus 作爲數據源，通過 PromQL 查詢監控數據後，做告警面板展示。

2.4 如何構建能力開放、穩定高效的雲原生監控體系

上文展示了社區官方給出的監控系統搭建方案，但該方案在生產環境應用時存在的主要問題：

• Prometheus 單機無法存儲大量長期歷史數據；

• 不具備高可用能力；

• 不具備橫向擴展能力；

• 缺少多維度的監控統計分析能力。

那麼對於大規模複雜生產環境，如何構建能力開放、穩定高效的雲原生監控體系？

綜合 vivo 自身容器集羣監控實踐經驗、各類雲原生監控相關文檔以及技術大會上各家廠商的技術架構分享，可以總結出適合大規模生產場景的雲原生監控體系架構，下圖展示了體系架構的分層模型。

• 通過雲原生方式部署，底層使用 Kubernetes 作爲統一的控制管理平面。

• 監控層採用 Prometheus 集羣作爲採集方案，Prometheus 集羣通過開源 / 自研高可用方案來保證無單點故障以及提供負載均衡能力，監控指標則通過應用 / 組件的自身 Metric API 或 exporter 來暴露。

• 告警數據發給告警組件按照指定規則進行處理，再由 webhook 轉發給公司的告警中心或其他通知渠道。

• 數據存儲層，採用高可用可擴展的時序數據庫方案來存儲長期監控數據，同時也用合適的數倉系統存儲一份來做更多維度的監控數據統計分析，爲上層做數據分析提供基礎。

• 數據分析處理層，可以對監控數據做進一步的分析處理，提供更多維度的報表，挖掘更多有價值的信息，甚至可以利用機器學習等技術實現故障預測、故障自愈等自動化運維目的。

圖片

三、vivo 容器集羣監控架構

任何系統的架構設計一定是針對生產環境和業務需求的特點，以滿足業務需求和高可用爲前提，在綜合考慮技術難度、研發投入和運維成本等綜合因素後，設計出最符合當前場景的架構方案。因此，在詳解 vivo 容器集羣監控架構設計之前，需要先介紹下背景：

• 生產環境

vivo 目前有多個容器化生產集羣，分佈在若干機房，目前單集羣最大規模在 1000~2000 節點。

• 監控需求

需要滿足生產高可用，監控範圍主要包括容器集羣指標、物理機運行指標和容器（業務）指標，其中業務監控告警還需要通過公司的基礎監控平臺來展示和配置。

• 告警需求

告警需要可視化的配置方式，需要發送給公司的告警中心，並有分級分組等策略規則需求。

• 數據分析需求

有各類豐富的周、月度、季度統計報表需求。

3.1 監控高可用架構設計

結合上文說明的環境和需求特點，vivo 當前監控架構的設計思路：

• 每個生產集羣都有獨立的監控節點用於部署監控組件，Prometheus 按照採集目標服務劃分爲多組，每組 Prometheus 都是雙副本部署保證高可用。

• 數據存儲採用 VictoriaMetrics，每個機房部署一套 VictoriaMetrics 集羣，同一機房內集羣的 Prometheus 均將監控數據 remote-write 到 VM 中，VM 配置爲多副本存儲，保證存儲高可用。

• Grafana 對接 Mysql 集羣，Grafana 自身做到無狀態，實現 Grafana 多副本部署。Grafana 使用 VictoriaMetrics 作爲數據源。

• 通過撥測監控實現 Prometheus 自身的監控告警，在 Prometheus 異常時能及時收到告警信息。

• 集羣層面的告警使用 Grafana 的可視化告警配置，通過自研 webhook 將告警轉發給公司告警中心，自研 webhook 還實現了分級分組等告警處理策略。

• 容器層面（業務）的監控數據則通過自研 Adapter 轉發給 Kafka，進而存儲到公司基礎監控做業務監控展示和告警配置，同時也存儲一份到 Druid 做更多維度的統計報表。

圖片

前文介紹了社區的 Cortex 和 Thanos 高可用監控方案，這兩個方案在業界均有生產級的實踐經驗，但爲什麼我們選擇用 Prometheus 雙副本 + VictoriaMetrics 的方案？

主要原因有以下幾點：

• Cortex 在網上能找到的相關實踐文檔較少。

• Thanos 需要使用對象存儲，實際部署時發現 Thanos 的配置比較複雜，參數調優可能比較困難，另外 Thanos 需要在 Prometheus Pod 裏部署其 SideCar 組件，而我們 Prometheus 部署採用的是 Operator 自動部署方式，嵌入 SideCar 比較麻煩。另外，在實測中對 Thanos 組件進行監控時發現，Thanos 因爲 Compact 和傳輸 Prometheus 數據存儲文件等原因，時常出現 CPU 和網絡的尖峯。綜合考慮後認爲 Thanos 的後期維護成本較高，因此沒有采用。

• VictoriaMetrics 部署配置比較簡單，有很高的存儲、查詢和壓縮性能，支持數據去重，不依賴外部系統，只需要通過 Prometheus 配置 remote-write 寫入監控數據即可，並且與 Grafana 完全兼容。既滿足我們長期歷史數據存儲和高可用需求，同時維護成本很低。從我們對 VictoriaMetrics 自身組件的監控觀察來看，運行數據平穩，並且自生產使用以來，一直穩定運行無故障。

3.2 監控數據轉發層組件高可用設計

由於 Prometheus 採用雙副本部署高可用方案，數據存儲如何去重是需要設計時就考慮的。VictoriaMetrics 本身支持存儲時去重，因此 VictoriaMetrics 這一側的數據去重得到天然解決。但監控數據通過 Kafka 轉發給基礎監控平臺和 OLAP 這一側的去重該如何實現？

我們設計的方案，如下圖，是通過自研 Adapter “分組選舉” 方式實現去重。即每個 Prometheus 副本對應一組 Adapter，兩組 Adapter 之間會進行選主，只有選舉爲 Leader 的那組 Adapter 纔會轉發數據。通過這種方式既實現了去重，也借用 K8s service 來支持 Adapter 的負載均衡。

此外，Adapter 具備感知 Prometheus 故障的能力，當 Leader Prometheus 發生故障時，Leader Adapter 會感知到並自動放棄 Leader 身份，從而切換到另一組 Adapter 繼續傳輸數據，確保了 “雙副本高可用 + 去重” 方案的有效性。

圖片

四、 容器監控實踐的挑戰和對策

我們在容器集羣監控實踐的過程中，遇到的一些困難和挑戰，總結如下：

NwsQR5

五、未來展望

監控的目標是爲了更高效可靠的運維，準確及時的發現問題。更高的目標是基於監控實現自動化的運維，甚至是智能運維（AIOPS）。

基於目前對容器集羣監控的經驗總結，未來在監控架構上可以做的提升點包括：

• Prometheus 自動化分片及採集 Target 自動負載均衡；

• AI 預測分析潛在故障；

• 故障自愈；

• 通過數據分析設定合適的告警閾值；

• 優化告警管控策略。

沒有一種架構設計是一勞永逸的，必須要隨着生產環境和需求的變化，以及技術的發展來持續演進。我們在雲原生監控這條路上，需要繼續不忘初心，砥礪前行。

vivo 互聯網技術 分享 vivo 互聯網技術乾貨與沙龍活動，推薦最新行業動態與熱門會議。

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