容器集群監(jiān)控系統(tǒng)架構(gòu)如何對(duì)癥下藥？

　　一、概述

　　在云原生的體系下，面對(duì)高彈性、拆分微服務(wù)以及應(yīng)用動(dòng)態(tài)生命周期等特點(diǎn)，傳統(tǒng)監(jiān)控體系如 cacti 、nagios 、Zabbix 等已經(jīng)逐漸喪失了優(yōu)勢(shì)，難以適用和支撐，對(duì)應(yīng)的新一代云原生監(jiān)控體系應(yīng)運(yùn)而生，Prometheus 為核心的監(jiān)控系統(tǒng)已成為云原生監(jiān)控領(lǐng)域的事實(shí)標(biāo)準(zhǔn)。

　　之前公司有文章介紹過(guò)，Qunar 內(nèi)部的一站式監(jiān)控平臺(tái)，后端存儲(chǔ)是基于 Graphite+Whisper 做的二次開(kāi)發(fā)，前端控制面是基于 Grafana 做的二次開(kāi)發(fā)。而 Grafana 是支持多數(shù)據(jù)源的，其中就包含 Prometheus 數(shù)據(jù)源。所以在容器化落地期間最初計(jì)劃采用的監(jiān)控方案也是 Prometheus ，其本身是個(gè) All in One 的系統(tǒng)，擁有強(qiáng)大的 PromQL ，集采集、處理、存儲(chǔ)、查詢、rule檢測(cè)于一身，非常易于部署和運(yùn)維。但每個(gè)系統(tǒng)都不是完全能夠契合使用需求的，Prometheus 也一樣不是完美的。

　　該文章將以 Qunar 容器監(jiān)控實(shí)踐過(guò)程和經(jīng)驗(yàn)為基礎(chǔ)，講述我們監(jiān)控體系構(gòu)建、遇到的挑戰(zhàn)和相應(yīng)對(duì)策，以及對(duì) VictoriaMetrics 的簡(jiǎn)單介紹與 Qunar 在過(guò)渡至 VictoriaMetrics 后的效果。

　　二、使用Prometheus的相關(guān)問(wèn)題

　　Prometheus 是個(gè) All in One 的系統(tǒng)，集采集、處理、存儲(chǔ)、查詢、rule 檢測(cè)于一身，這樣做易于部署和運(yùn)維，但也意味著喪失了拆分組件所具備的獨(dú)立性和可擴(kuò)展性。實(shí)踐測(cè)試摘錄的幾個(gè)問(wèn)題如下：

　　數(shù)據(jù)采集量大存在瓶頸，目前 Qunar 單集群容器指標(biāo)量級(jí)每分鐘將近 1 億;

　　不支持水平擴(kuò)容;

　　只支持 All in One 單機(jī)部署，不支持集群拆分部署;

　　其本身不適用于作為長(zhǎng)期數(shù)據(jù)存儲(chǔ);

　　占用資源高;

　　查詢效率低，Prometheus 加載數(shù)據(jù)是從磁盤(pán)到內(nèi)存的，不合理查詢或大范圍查詢都會(huì)加劇內(nèi)存占用問(wèn)題，范圍較大的數(shù)據(jù)查詢尤其明顯，甚至觸發(fā) OOM 。

　　如上例舉的幾項(xiàng)問(wèn)題點(diǎn)，其實(shí)對(duì)于大多數(shù)公司來(lái)講都不是問(wèn)題，因?yàn)闆](méi)有那么大的數(shù)據(jù)量和需求。但是對(duì)于我們或一些數(shù)據(jù)規(guī)模較大的公司來(lái)講，每一項(xiàng)都在對(duì)我們的使用環(huán)境說(shuō) No... 我們也對(duì)這些問(wèn)題嘗試了以下解決方案：

　　使用分片，對(duì) Prometheus 進(jìn)行按服務(wù)維度分片進(jìn)行分別采集存儲(chǔ)。默認(rèn)告警策略條件是針對(duì)所有 Targets 的，分片后因每實(shí)例處理的 Targets 不同，數(shù)據(jù)不統(tǒng)一，告警規(guī)則也需要隨著拆分修改。

　　使用 HA ，也就是跑兩個(gè) Prometheus 采集同樣的數(shù)據(jù)，外層通過(guò)負(fù)載均衡器進(jìn)行代理對(duì)其實(shí)行高可用

　　使用Promscale作為其遠(yuǎn)程存儲(chǔ)，保留長(zhǎng)期數(shù)據(jù)注：Promscale是 TimescaleDB 近兩年發(fā)布的一個(gè)基于 TimescaleDB 之上的 Prometheus 長(zhǎng)期存儲(chǔ)。

　　但做了這些處理后，其實(shí)還是留存問(wèn)題，也有局限性和較大隱患：

　　例如 2 個(gè)實(shí)例，1、2 同時(shí)運(yùn)行采集相同數(shù)據(jù)，他們之間是各自采集各自的沒(méi)有數(shù)據(jù)同步機(jī)制，如果某臺(tái)宕機(jī)一段時(shí)間恢復(fù)后，數(shù)據(jù)就是缺失的，那么負(fù)載均衡器輪訓(xùn)到宕機(jī)的這臺(tái)數(shù)據(jù)就會(huì)有問(wèn)題，這意味著使用類似 Nginx 負(fù)載均衡是不能夠滿足使用的。

　　各集群 2w+ Targets，拆分 Prometheus 后可以提升性能，但依然有限，對(duì)資源占用問(wèn)題并未改善。

　　遠(yuǎn)程存儲(chǔ) Promscale 資源占用極大，40k samples/s，一天 30 億，就用掉了將近16 cores/40G 內(nèi)存/150GB 磁盤(pán)。而我們單集群1.50 Mil samples/s，一天就產(chǎn)生 1300 億左右，而且需求數(shù)據(jù)雙副本，這樣的資源需求下如果上了線，僅磁盤(pán)單集群 1 天就要耗費(fèi) 12TB 左右，這樣的代價(jià)我們是表示有些抗拒的……

　　三、接觸 VictoriaMetrics

　　在為調(diào)整后面臨到的這些難點(diǎn)，進(jìn)行進(jìn)一步調(diào)研，結(jié)合 Qunar 自身經(jīng)驗(yàn)和需求參考各類相關(guān)文檔以及各大廠商的架構(gòu)分享時(shí)，我們注意到了 VictoriaMetrics ，并在其官網(wǎng)列出的諸多用戶案例中，發(fā)現(xiàn)知乎使用 VictoriaMetrics 的數(shù)據(jù)分享與我們的數(shù)據(jù)規(guī)模量級(jí)幾乎一致，而且性能與資源表現(xiàn)都相當(dāng)優(yōu)異，非常符合我們期望需求，便開(kāi)始了 VictoriaMetrics 的嘗鮮旅程，也歸結(jié)出適合我們生產(chǎn)場(chǎng)景的云原生監(jiān)控體系架構(gòu)，并在后續(xù)工作中通過(guò)使用測(cè)試完全滿足我們需求，進(jìn)行了全面替換使用。

　　在此，先對(duì) VictoriaMetrics 進(jìn)行介紹，也推薦給大家對(duì) VictoriaMetrics 進(jìn)行了解和使用，后面也會(huì)貼出我們的使用架構(gòu)和效果展示。

　　1、VictoriaMetrics 介紹

　　VictoriaMetrics (后續(xù)簡(jiǎn)稱 VM )是一種快速、經(jīng)濟(jì)高效且可擴(kuò)展的監(jiān)控解決方案和時(shí)間序列數(shù)據(jù)庫(kù)，它可以僅作為 Prometheus 的遠(yuǎn)程寫(xiě)入做長(zhǎng)期存儲(chǔ)，也可以用于完全替換 Prometheus 使用。

　　Prometheus 的 Config、API、PromQL，Exporter、Service discovery 等 VM 基本都能夠兼容支持，如果作為替換方案，替換成本會(huì)非常低。

　　在 DB-Engines - TSDB 的排行中，VM 當(dāng)前排名為 Top 15，并呈上升趨勢(shì)，可見(jiàn)下圖：

　　2、VictoriaMetrics特點(diǎn)

　　可以作為 Prometheus 的長(zhǎng)期數(shù)據(jù)存儲(chǔ)庫(kù)：

　　兼容 PromQL 并提供改進(jìn)增強(qiáng)的 MetricsQL ;

　　可以直接使用 Grafana 的 Prometheus DataSource 進(jìn)行配置，因?yàn)榧嫒?Prometheus API ;

　　高性能 - 查詢效率優(yōu)于 Prometheus ;

　　低內(nèi)存 - 相較 Prometheus 低 5 倍，相較 Promscale 低 28 倍;

　　高壓縮 - 磁盤(pán)空間相較 Prometheus 低 7 倍，相較 Promscale 低 92 倍，詳情可參見(jiàn) Promscale VS VictoriaMetrics ;

　　集群版可水平擴(kuò)展、可數(shù)據(jù)多副本、支持多租戶。

　　3、VictoriaMetrics 架構(gòu)

　　VM 有兩類部署方式，都非常簡(jiǎn)單，如果對(duì) Prometheus 有一定基礎(chǔ)，整個(gè)替換過(guò)程會(huì)非常順滑，這里就不對(duì)安裝進(jìn)行細(xì)述了。

　　VM - Single server - All in One 單點(diǎn)方式，提供 Docker image ，單點(diǎn) VM 可以支撐 100 萬(wàn) Data Points/s。

　　VM - Cluster - 集群版，拆分為了 vmselect、vminsert、vmstorage 3個(gè)服務(wù)，提供 Operate ，支持水平擴(kuò)展;低于百萬(wàn)指標(biāo)/s建議用單點(diǎn)方式，更易于安裝使用和維護(hù)。

　　Qunar 單集群 Total Data points 17萬(wàn)億，采用的是 VMCluster 方案。

　　另外對(duì)于指標(biāo)采集和告警，需要單獨(dú)以下組件：

　　可選，可按自身需求選擇是否使用如下組件替代現(xiàn)有方案。

　　如果只是將 VM 作為 Prometheus 的遠(yuǎn)程存儲(chǔ)來(lái)使用的話，這兩個(gè)組件可忽略，僅部署 VM - Single 或 VM - Cluster ，并在 Prometheus 配置 remoteWrite 指向 VM 地址即可。

　　VMagent

　　VMalert

　　vmcluster 架構(gòu)圖

　　vm-single 特別簡(jiǎn)單不做贅述，這里說(shuō)下 vm-cluster，vmcluster 由以下 3 個(gè)服務(wù)組成：

　　vmstorage 負(fù)責(zé)提供數(shù)據(jù)存儲(chǔ)服務(wù);

　　vminsert 是數(shù)據(jù)存儲(chǔ) vmstorage 的代理，使用一致性hash算法將數(shù)據(jù)寫(xiě)入分片;

　　vmselect 負(fù)責(zé)數(shù)據(jù)查詢，根據(jù)輸入的查詢條件從vmstorage 中查詢數(shù)據(jù)。vmselece、vminsert為無(wú)狀態(tài)服務(wù)，vmstorage是有狀態(tài)的，每個(gè)服務(wù)都可以獨(dú)立擴(kuò)展。

　　vmstorage 使用的是 shared nothing 架構(gòu)，節(jié)點(diǎn)之間各自獨(dú)立互無(wú)感知、不需要通信和共享數(shù)據(jù)，由此也提升了集群的可用性，降低運(yùn)維、擴(kuò)容難度。

　　如下為官網(wǎng)提供的 vmcluster 的架構(gòu)圖：

　　vmagent

　　vmagent 是一個(gè)輕量的指標(biāo)收集器，可以收集不同來(lái)源處的指標(biāo)，并將指標(biāo)存儲(chǔ)在vm或者其他支持 remote_write 協(xié)議的 Prometheus 兼容的存儲(chǔ)系統(tǒng)。

　　建議通過(guò)VM Operate進(jìn)行管理，它可以識(shí)別原Prometheus創(chuàng)建的 ServiceMonitor、PodMonitor 等資源對(duì)象，不需要做任何改動(dòng)直接使用。

　　vmagent具備如下特點(diǎn)(摘要)：

　　可以直接替代 prometheus 從各種 exporter 進(jìn)行指標(biāo)抓取;

　　相較 prometheus 更少的資源占用;

　　當(dāng)抓目標(biāo)數(shù)量較大時(shí)，可以分布到多個(gè) vmagent 實(shí)例中并設(shè)置多份抓取提供采集高可用性;

　　支持不可靠遠(yuǎn)端存儲(chǔ)，數(shù)據(jù)恢復(fù)方面相比 Prometheus 的 Wal ，VM 通過(guò)可配置 -remoteWrite.tmpDataPath 參數(shù)在遠(yuǎn)程存儲(chǔ)不可用時(shí)將數(shù)據(jù)寫(xiě)入到磁盤(pán)，在遠(yuǎn)程存儲(chǔ)恢復(fù)后，再將寫(xiě)入磁盤(pán)的指標(biāo)發(fā)送到遠(yuǎn)程存儲(chǔ)，在大規(guī)模指標(biāo)采集場(chǎng)景下，該方式更友好;

　　支持基于 prometheus relabeling 的模式添加、移除、修改 labels，可以在數(shù)據(jù)發(fā)送到遠(yuǎn)端存儲(chǔ)之前進(jìn)行數(shù)據(jù)的過(guò)濾;

　　支持從 Kafka 讀寫(xiě)數(shù)據(jù)。

　　vmalert

　　前面說(shuō)到 vmagent 可用于替代 Prometheus 進(jìn)行數(shù)據(jù)采集，那么 vmalert 即為用于替代 Prometheus 規(guī)則運(yùn)算，之前我們都是在 prometheus 中配置報(bào)警規(guī)則評(píng)估后發(fā)送到 alertmanager，在 VM 中即可使用 vmalert 來(lái)處理報(bào)警。

　　vmalert 會(huì)針對(duì) -datasource.url 地址執(zhí)行配置的報(bào)警或記錄規(guī)則，然后可以將報(bào)警發(fā)送給 -notifier.url 配置的 Alertmanager 地址，記錄規(guī)則結(jié)果會(huì)通過(guò)遠(yuǎn)程寫(xiě)入的協(xié)議進(jìn)行保存，所以需要配置 -remoteWrite.url 。

　　建議通過(guò)VM Operate進(jìn)行管理，它可以識(shí)別原Prometheus創(chuàng)建的 PrometheusRule、Probe 資源對(duì)象，不需要做任何改動(dòng)直接使用。

　　vmalert具備如下特點(diǎn)：

　　與 VictoriaMetrics TSDB 集成

　　VictoriaMetrics MetricsQL 支持和表達(dá)式驗(yàn)證

　　Prometheus 告警規(guī)則格式支持

　　自 Alertmanager v0.16.0 開(kāi)始與 Alertmanager 集成

　　在重啟時(shí)可以保持報(bào)警狀態(tài)

　　支持記錄和報(bào)警規(guī)則重放

　　輕量級(jí)，且沒(méi)有額外的依賴

　　Qunar 的 VictoriaMetrics 架構(gòu)

　　按照官網(wǎng)建議數(shù)據(jù)量低于 100w/s 采用 VM 單機(jī)版， 數(shù)據(jù)量高于 100w/s 采用 VM 集群版，根據(jù) Qunar 的指標(biāo)數(shù)據(jù)量級(jí)，以及對(duì)可擴(kuò)展性的需求等，選擇使用了 VM 集群版。

　　采集方面使用 vmagent 并按照服務(wù)維度劃分采集目標(biāo)分為多組，且每組雙副本部署以保障高可用。各集群互不相關(guān)和影響，通過(guò)添加env、Cluster labels進(jìn)行環(huán)境和集群標(biāo)識(shí)。

　　數(shù)據(jù)存儲(chǔ)使用 VMcluster，每個(gè)集群部署一套，并通過(guò) label 和 tolerations 與 podAntiAffinity 控制 VMcluster 的節(jié)點(diǎn)獨(dú)立、vmstorage 同節(jié)點(diǎn)互斥。同一集群的 vmagent 均將數(shù)據(jù) remoteWrite 到同集群 VM 中，并將 VM 配置為多副本存儲(chǔ)，保障存儲(chǔ)高可用。

　　部署 Promxy 添加所有集群，查詢?nèi)肟诰�通過(guò) Promxy 進(jìn)行查詢。

　　Watcher 中的 Prometheus 數(shù)據(jù)源配置為 Promxy 地址，將 Promxy 作為數(shù)據(jù)源

　　告警方面使用了 vmalert，并在 Qunar 告警中心架構(gòu)上，Watcher 團(tuán)隊(duì)自研添加了 Rule Manager、Prometheus Manager 兩個(gè)模塊。

　　Rule Manager 表示的是 rule 同步模塊，將規(guī)則同步至我們 Watcher Dashboard ，用于用戶查看和自定義修改，便于一站式管理。同時(shí)也繼續(xù)沿用原有告警實(shí)例信息同步 icinga daemon 邏輯。

　　Prometheus Manager 模塊主要是實(shí)現(xiàn)了 reciever 接口，接收 alertmanager 的 hook ，然后更改 icinga 的報(bào)警狀態(tài)。

　　最后對(duì)于 vmalert 本身狀態(tài)，則是采用撥測(cè)監(jiān)控實(shí)現(xiàn)。于此以最小改動(dòng)代價(jià)融入至 Qunar 現(xiàn)有告警中心。

　　建議使用 vm-operate 進(jìn)行部署和管理，它實(shí)現(xiàn)了如下幾項(xiàng) CRD：

　　VMCluster：定義 VM 集群

　　VMAgent：定義 vmagent 實(shí)例

　　VMServiceScrape：定義從 Service 支持的 Pod 中抓取指標(biāo)配置

　　VMPodScrape：定義從 Pod 中抓取指標(biāo)配置

　　VMRule：定義報(bào)警和記錄規(guī)則

　　VMProbe：使用 blackbox exporter 為目標(biāo)定義探測(cè)配置

　　同時(shí)默認(rèn)也可以識(shí)別 prometheus-perate 實(shí)現(xiàn)的 Servicemonitor 、 PodMonitor 、PrometheusRule 、Probe 這些 CRD ，開(kāi)箱即用平滑接替 Prometheus 。

　　完全替換后的表現(xiàn)

　　Qunar 容器化已將全環(huán)境集群的原 Prometheus 方案全部使用 VM 解決方案進(jìn)行替換，所有的應(yīng)用都是使用 VM-Operate 完成部署和管理的。

　　替換后其中某集群的數(shù)據(jù)表現(xiàn)如下：

　　后續(xù)準(zhǔn)備做的幾個(gè)優(yōu)化

　　VM 開(kāi)源版本不支持 downsampling ，僅企業(yè)版中有。對(duì)于時(shí)間范圍較大的查詢，時(shí)序結(jié)果會(huì)特別多處理較慢，后續(xù)計(jì)劃嘗試使用 vmalert 通過(guò) recordRule 來(lái)進(jìn)行稀釋，達(dá)到 downsampling 的效果;

　　其實(shí)很多應(yīng)用如 Etcd、Node-exporter 暴露出來(lái)的指標(biāo)里有些是我們并不關(guān)注的，后續(xù)也計(jì)劃進(jìn)行指標(biāo)治理，排除無(wú)用指標(biāo)來(lái)降低監(jiān)控資源開(kāi)銷。

　　總結(jié)

　　本文介紹了 Victoriametrics 的優(yōu)勢(shì)以及 Prometheus 不足之處，在 Qunar 替換掉的原因以及替換后的效果展示。也分享了 Qunar 對(duì) VM 的使用方式和架構(gòu)。

　　使用 VM 替代 Prometheus 是個(gè)很好的選擇，其它有類似需求的場(chǎng)景或組織也可以嘗試 VM 。如果要用最直接的話來(lái)形容 VM ，可以稱其為 Prometheus 企業(yè)版，Prometheus Plus 。

　　最后，任何系統(tǒng)、架構(gòu)都并非一勞永逸，都要隨著場(chǎng)景、需求變化而變化;也并沒(méi)有哪種系統(tǒng)、架構(gòu)可以完全契合所有場(chǎng)景需求，都需要根據(jù)自身場(chǎng)景實(shí)際情況，本著實(shí)用至上的原則進(jìn)行設(shè)計(jì)規(guī)劃。