作者 ｜ vivo 互聯(lián)網(wǎng)服務器團隊-YuanPeng

一、概述

從容器技術(shù)的推廣以及 Kubernetes成為容器調(diào)度管理領(lǐng)域的事實標準開始，云原生的理念和技術(shù)架構(gòu)體系逐漸在生產(chǎn)環(huán)境中得到了越來越廣泛的應用實踐。在云原生的體系下，面對高度的彈性、動態(tài)的應用生命周期管理以及微服務化等特點，傳統(tǒng)的監(jiān)控體系已經(jīng)難以應對和支撐，因此新一代云原生監(jiān)控體系應運而生。

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

本文以vivo容器集群監(jiān)控實踐經(jīng)驗為基礎(chǔ)，探討了云原生監(jiān)控體系架構(gòu)如何構(gòu)建、遇到的挑戰(zhàn)以及相應的對策。

二、云原生監(jiān)控體系

2.1 云原生監(jiān)控的特征和價值

云原生監(jiān)控相比于傳統(tǒng)監(jiān)控，有其特征和價值，可歸納為下表：

2.2 云原生監(jiān)控生態(tài)簡介

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

Prometheus（已畢業(yè)）

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

Prometheus是繼Kubernetes之后的第二個CNCF “畢業(yè)”項目（也是目前監(jiān)控方向唯一“畢業(yè)”的項目），開源社區(qū)活躍，在Github上擁有近4萬Stars。

Prometheus的Pull指標采集方式被廣泛采用，很多應用都直接實現(xiàn)了基于Prometheus采集標準的metric接口來暴露自身監(jiān)控指標。即使是沒有實現(xiàn)metric接口的應用，大部分在社區(qū)里都能找到相應的exporter來間接暴露監(jiān)控指標。

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

Cortex（孵化中）

Cortex對Prometheus進行了擴展，提供多租戶方式，并為Prometheus提供了對接持久化存儲的能力，支持Prometheus實例水平擴展，以及提供多個Prometheus數(shù)據(jù)的統(tǒng)一查詢?nèi)肟凇?/p>

Thanos（孵化中）

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

Grafana

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

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

VictoriaMetrics

VictoriaMetrics是一個高性能、經(jīng)濟且可擴展的監(jiān)控解決方案和時序數(shù)據(jù)庫，可以作為Prometheus的長期遠程存儲方案，支持PromQL查詢，并與Grafana兼容，可用于替換Prometheus作為Grafana的數(shù)據(jù)源。具有安裝配置簡單、低內(nèi)存占用、高壓縮比、高性能以及支持水平擴展等特性。

AlertManager

AlertManager是一個告警組件，接收Prometheus發(fā)來的告警，通過分組、沉默、抑制等策略處理后，通過路由發(fā)送給指定的告警接收端。告警可以按照不同的規(guī)則發(fā)送給不同的接收方，支持多種常見的告警接收端，比如Email，Slack，或通過webhook方式接入企業(yè)微信、釘釘?shù)葒鴥?nèi)IM工具。

2.3 如何搭建一套簡單的云原生監(jiān)控系統(tǒng)

上文了解了云原生監(jiān)控領(lǐng)域的常用工具后，該如何搭建一套簡單的云原生監(jiān)控系統(tǒng)？下圖給出了Prometheus社區(qū)官方提供的方案：

（出處：Prometheus社區(qū)）

上述系統(tǒng)展開闡述如下：

• 所有監(jiān)控組件都是以云原生的方式部署，即容器化部署、用Kubernetes來統(tǒng)一管理。
• Prometheus負責指標采集和監(jiān)控數(shù)據(jù)存儲，并可以通過文件配置或Kubernetes服務發(fā)現(xiàn)方式來自動發(fā)現(xiàn)采集目標。
• 應用可以通過自身的Metric接口或相應的exporter來讓Prometheus拉取監(jiān)控數(shù)據(jù)。
• 一些短暫的自定義采集指標，可以通過腳本程序采集并推送給Pushgateway組件，來讓Prometheus拉取。
• Prometheus配置好告警規(guī)則，將告警數(shù)據(jù)發(fā)送給Alertmanager，由Alertmanager按照一定規(guī)則策略處理后路由給告警接收方。
• Grafana配置Prometheus作為數(shù)據(jù)源，通過PromQL查詢監(jiān)控數(shù)據(jù)后，做告警面板展示。

2.4 如何構(gòu)建能力開放、穩(wěn)定高效的云原生監(jiān)控體系

上文展示了社區(qū)官方給出的監(jiān)控系統(tǒng)搭建方案，但該方案在生產(chǎn)環(huán)境應用時存在的主要問題：

• Prometheus單機無法存儲大量長期歷史數(shù)據(jù)；
• 不具備高可用能力；
• 不具備橫向擴展能力；
• 缺少多維度的監(jiān)控統(tǒng)計分析能力。

那么對于大規(guī)模復雜生產(chǎn)環(huán)境，如何構(gòu)建能力開放、穩(wěn)定高效的云原生監(jiān)控體系？

綜合vivo自身容器集群監(jiān)控實踐經(jīng)驗、各類云原生監(jiān)控相關(guān)文檔以及技術(shù)大會上各家廠商的技術(shù)架構(gòu)分享，可以總結(jié)出適合大規(guī)模生產(chǎn)場景的云原生監(jiān)控體系架構(gòu)，下圖展示了體系架構(gòu)的分層模型。

• 通過云原生方式部署，底層使用Kubernetes作為統(tǒng)一的控制管理平面。
• 監(jiān)控層采用Prometheus集群作為采集方案，Prometheus集群通過開源/自研高可用方案來保證無單點故障以及提供負載均衡能力，監(jiān)控指標則通過應用/組件的自身Metric API或exporter來暴露。
• 告警數(shù)據(jù)發(fā)給告警組件按照指定規(guī)則進行處理，再由webhook轉(zhuǎn)發(fā)給公司的告警中心或其他通知渠道。
• 數(shù)據(jù)存儲層，采用高可用可擴展的時序數(shù)據(jù)庫方案來存儲長期監(jiān)控數(shù)據(jù)，同時也用合適的數(shù)倉系統(tǒng)存儲一份來做更多維度的監(jiān)控數(shù)據(jù)統(tǒng)計分析，為上層做數(shù)據(jù)分析提供基礎(chǔ)。
• 數(shù)據(jù)分析處理層，可以對監(jiān)控數(shù)據(jù)做進一步的分析處理，提供更多維度的報表，挖掘更多有價值的信息，甚至可以利用機器學習等技術(shù)實現(xiàn)故障預測、故障自愈等自動化運維目的。

三、vivo容器集群監(jiān)控架構(gòu)

任何系統(tǒng)的架構(gòu)設(shè)計一定是針對生產(chǎn)環(huán)境和業(yè)務需求的特點，以滿足業(yè)務需求和高可用為前提，在綜合考慮技術(shù)難度、研發(fā)投入和運維成本等綜合因素后，設(shè)計出最符合當前場景的架構(gòu)方案。因此，在詳解vivo容器集群監(jiān)控架構(gòu)設(shè)計之前，需要先介紹下背景：

生產(chǎn)環(huán)境

vivo目前有多個容器化生產(chǎn)集群，分布在若干機房，目前單集群最大規(guī)模在1000~2000節(jié)點。

監(jiān)控需求

需要滿足生產(chǎn)高可用，監(jiān)控范圍主要包括容器集群指標、物理機運行指標和容器（業(yè)務）指標，其中業(yè)務監(jiān)控告警還需要通過公司的基礎(chǔ)監(jiān)控平臺來展示和配置。

告警需求

告警需要可視化的配置方式，需要發(fā)送給公司的告警中心，并有分級分組等策略規(guī)則需求。

數(shù)據(jù)分析需求

有各類豐富的周、月度、季度統(tǒng)計報表需求。

3.1 監(jiān)控高可用架構(gòu)設(shè)計

結(jié)合上文說明的環(huán)境和需求特點，vivo當前監(jiān)控架構(gòu)的設(shè)計思路：

• 每個生產(chǎn)集群都有獨立的監(jiān)控節(jié)點用于部署監(jiān)控組件，Prometheus按照采集目標服務劃分為多組，每組Prometheus都是雙副本部署保證高可用。
• 數(shù)據(jù)存儲采用VictoriaMetrics，每個機房部署一套VictoriaMetrics集群，同一機房內(nèi)集群的Prometheus均將監(jiān)控數(shù)據(jù)remote-write到VM中，VM配置為多副本存儲，保證存儲高可用。
• Grafana對接Mysql集群，Grafana自身做到無狀態(tài)，實現(xiàn)Grafana多副本部署。Grafana使用VictoriaMetrics作為數(shù)據(jù)源。
• 通過撥測監(jiān)控實現(xiàn)Prometheus自身的監(jiān)控告警，在Prometheus異常時能及時收到告警信息。
• 集群層面的告警使用Grafana的可視化告警配置，通過自研webhook將告警轉(zhuǎn)發(fā)給公司告警中心，自研webhook還實現(xiàn)了分級分組等告警處理策略。
• 容器層面（業(yè)務）的監(jiān)控數(shù)據(jù)則通過自研Adapter轉(zhuǎn)發(fā)給Kafka，進而存儲到公司基礎(chǔ)監(jiān)控做業(yè)務監(jiān)控展示和告警配置，同時也存儲一份到Druid做更多維度的統(tǒng)計報表。

前文介紹了社區(qū)的Cortex和Thanos高可用監(jiān)控方案，這兩個方案在業(yè)界均有生產(chǎn)級的實踐經(jīng)驗，但為什么我們選擇用Prometheus雙副本+VictoriaMetrics的方案？

主要原因有以下幾點：

• Cortex在網(wǎng)上能找到的相關(guān)實踐文檔較少。
• Thanos需要使用對象存儲，實際部署時發(fā)現(xiàn)Thanos的配置比較復雜，參數(shù)調(diào)優(yōu)可能比較困難，另外Thanos需要在Prometheus Pod里部署其SideCar組件，而我們Prometheus部署采用的是Operator自動部署方式，嵌入SideCar比較麻煩。另外，在實測中對Thanos組件進行監(jiān)控時發(fā)現(xiàn)，Thanos因為Compact和傳輸Prometheus數(shù)據(jù)存儲文件等原因，時常出現(xiàn)CPU和網(wǎng)絡(luò)的尖峰。綜合考慮后認為Thanos的后期維護成本較高，因此沒有采用。
• VictoriaMetrics部署配置比較簡單，有很高的存儲、查詢和壓縮性能，支持數(shù)據(jù)去重，不依賴外部系統(tǒng)，只需要通過Prometheus配置remote-write寫入監(jiān)控數(shù)據(jù)即可，并且與Grafana完全兼容。既滿足我們長期歷史數(shù)據(jù)存儲和高可用需求，同時維護成本很低。從我們對VictoriaMetrics自身組件的監(jiān)控觀察來看，運行數(shù)據(jù)平穩(wěn)，并且自生產(chǎn)使用以來，一直穩(wěn)定運行無故障。

3.2 監(jiān)控數(shù)據(jù)轉(zhuǎn)發(fā)層組件高可用設(shè)計

由于Prometheus采用雙副本部署高可用方案，數(shù)據(jù)存儲如何去重是需要設(shè)計時就考慮的。VictoriaMetrics本身支持存儲時去重，因此VictoriaMetrics這一側(cè)的數(shù)據(jù)去重得到天然解決。但監(jiān)控數(shù)據(jù)通過Kafka轉(zhuǎn)發(fā)給基礎(chǔ)監(jiān)控平臺和OLAP這一側(cè)的去重該如何實現(xiàn)？

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

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

四、 容器監(jiān)控實踐的挑戰(zhàn)和對策

我們在容器集群監(jiān)控實踐的過程中，遇到的一些困難和挑戰(zhàn)，總結(jié)如下：

五、未來展望

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

基于目前對容器集群監(jiān)控的經(jīng)驗總結(jié)，未來在監(jiān)控架構(gòu)上可以做的提升點包括：

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

沒有一種架構(gòu)設(shè)計是一勞永逸的，必須要隨著生產(chǎn)環(huán)境和需求的變化，以及技術(shù)的發(fā)展來持續(xù)演進。我們在云原生監(jiān)控這條路上，需要繼續(xù)不忘初心，砥礪前行。