vivo 網際網路伺服器團隊-YuanPeng

一、概述

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

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

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

二、雲原生監控體系

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

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

2.2 雲原生監控生態簡介

CNCF生態全景圖中監控相關的專案如下圖（參考 ），下面重點介紹幾個專案：

• 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社群官方提供的方案：

（出處： ）

上述系統展開闡述如下：

• 所有監控元件都是以雲原生的方式部署，即容器化部署、用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預測分析潛在故障；

• 故障自愈；

• 透過資料分析設定合適的告警閾值；

• 最佳化告警管控策略。

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