作者 ｜ vivo 互聯網服務器團隊-YuanPeng

一、概述

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

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

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

二、云原生監控體系

2.1 云原生監控的特征和價值

云原生監控相比于傳統監控，有其特征和價值，可歸納為下表：

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繼續傳輸數據，確保了“雙副本高可用+去重”方案的有效性。

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

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

五、未來展望

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

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

• Prometheus自動化分片及采集Target自動負載均衡；
• AI預測分析潛在故障；
• 故障自愈；
• 通過數據分析設定合適的告警閾值；
• 優化告警管控策略。

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