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

一、概述

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

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

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

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

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

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

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

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

Prometheus（已畢業(yè)）

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

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

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

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

Cortex（孵化中）

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

Thanos（孵化中）

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

Grafana

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

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

VictoriaMetrics

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

AlertManager

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

監(jiān)控需求

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

告警需求

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

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

有各類(lèi)豐富的周、月度、季度統(tǒng)計(jì)報(bào)表需求。

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

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

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

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

主要原因有以下幾點(diǎn)：

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

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

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

我們?cè)O(shè)計(jì)的方案，如下圖，是通過(guò)自研Adapter “分組選舉”方式實(shí)現(xiàn)去重。即每個(gè)Prometheus副本對(duì)應(yīng)一組Adapter，兩組Adapter之間會(huì)進(jìn)行選主，只有選舉為L(zhǎng)eader的那組Adapter才會(huì)轉(zhuǎn)發(fā)數(shù)據(jù)。通過(guò)這種方式既實(shí)現(xiàn)了去重，也借用K8s service來(lái)支持Adapter的負(fù)載均衡。

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

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

我們?cè)谌萜骷罕O(jiān)控實(shí)踐的過(guò)程中，遇到的一些困難和挑戰(zhàn)，總結(jié)如下：

五、未來(lái)展望

監(jiān)控的目標(biāo)是為了更高效可靠的運(yùn)維，準(zhǔn)確及時(shí)的發(fā)現(xiàn)問(wèn)題。更高的目標(biāo)是基于監(jiān)控實(shí)現(xiàn)自動(dòng)化的運(yùn)維，甚至是智能運(yùn)維（AIOPS）。

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

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

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