Prometheus作為新生代的開(kāi)源監(jiān)控系統(tǒng)，慢慢成為了云原生體系的監(jiān)控事實(shí)標(biāo)準(zhǔn)，也證明了其設(shè)計(jì)得到業(yè)界認(rèn)可。但在多集群，大集群等場(chǎng)景下，Prometheus由于沒(méi)有分片能力和多集群支持，還有Prometheus不支持長(zhǎng)期存儲(chǔ)、不能自動(dòng)水平縮、大范圍監(jiān)控指標(biāo)查詢(xún)會(huì)導(dǎo)致Prometheus服務(wù)內(nèi)存突增等。本文從Prometheus的單集群監(jiān)控開(kāi)始，介紹包括Prometheus的基本概念，基于聯(lián)邦架構(gòu)的多集群監(jiān)控，基于Thanos的多集群監(jiān)控等內(nèi)容。

Prometheus工作流程

Prometheus的工作流程核心是，以主動(dòng)拉取pull的方式搜集被監(jiān)控對(duì)象的metrics數(shù)據(jù)（監(jiān)控指標(biāo)數(shù)據(jù)），并將這些metrics數(shù)據(jù)存儲(chǔ)到一個(gè)內(nèi)存TSDB（時(shí)間序列數(shù)據(jù)庫(kù)）中，并定期將內(nèi)存中的指標(biāo)同步到本地硬盤(pán)。

基本架構(gòu)如下圖所示

圖可能有點(diǎn)復(fù)雜，簡(jiǎn)單總結(jié)如下：

從配置文件加載采集配置

周期性得往抓取對(duì)象發(fā)起抓取請(qǐng)求，得到數(shù)據(jù)

將數(shù)據(jù)寫(xiě)入本地盤(pán)或者寫(xiě)往遠(yuǎn)端存儲(chǔ)

alertmanager從監(jiān)控?cái)?shù)據(jù)中發(fā)現(xiàn)異常數(shù)據(jù)做出報(bào)警

如果我們現(xiàn)在有多個(gè)集群，并希望他們的監(jiān)控?cái)?shù)據(jù)存儲(chǔ)到一起，可以進(jìn)行聚合查詢(xún)，用上述部署方案顯然是不夠的，因?yàn)樯鲜龇桨钢械腜rometheus只能識(shí)別出本集群內(nèi)的被監(jiān)控目標(biāo)。另外就是網(wǎng)絡(luò)限制，多個(gè)集群之間的網(wǎng)絡(luò)有可能是不通的，這就使得即使在某個(gè)集群中知道另一個(gè)集群的地址，也沒(méi)法去抓取數(shù)據(jù)，要解決這些問(wèn)題那就得用高可用方案。

Prometheus官方給出的三種高可用方案

HA：即兩套 Prometheus 采集完全一樣的數(shù)據(jù)，外邊掛負(fù)載均衡

HA + 遠(yuǎn)程存儲(chǔ)：Prometheus通過(guò) Remote write 寫(xiě)入到遠(yuǎn)程存儲(chǔ)

聯(lián)邦集群：即 Federation，按照功能進(jìn)行分區(qū)，不同的 Shard 采集不同的數(shù)據(jù)，由 Global 節(jié)點(diǎn)來(lái)統(tǒng)一存放，解決監(jiān)控?cái)?shù)據(jù)規(guī)模的問(wèn)題。

使用官方建議的多副本 + 聯(lián)邦仍然會(huì)遇到一些問(wèn)題，本質(zhì)原因是 Prometheus 的本地存儲(chǔ)沒(méi)有數(shù)據(jù)同步能力，要在保證可用性的前提下再保持?jǐn)?shù)據(jù)一致性是比較困難的，基本的多副本 Proxy 滿(mǎn)足不了要求，比如：

1.Prometheus 集群的后端有 A 和 B 兩個(gè)實(shí)例，A 和 B 之間沒(méi)有數(shù)據(jù)同步。A 宕機(jī)一段時(shí)間，丟失了一部分?jǐn)?shù)據(jù)，如果負(fù)載均衡正常輪詢(xún)，請(qǐng)求打到A 上時(shí)，數(shù)據(jù)就會(huì)異常。

2.如果A和B的啟動(dòng)時(shí)間不同，時(shí)鐘不同，那么采集同樣的數(shù)據(jù)時(shí)間戳也不同，就多副本的數(shù)據(jù)不相同

3.就算用了遠(yuǎn)程存儲(chǔ)，A 和 B 不能推送到同一個(gè) TSDB，如果每人推送自己的 TSDB，數(shù)據(jù)查詢(xún)走哪邊就是問(wèn)題

4.官方建議數(shù)據(jù)做 Shard，然后通過(guò) Federation 來(lái)實(shí)現(xiàn)高可用，但是邊緣節(jié)點(diǎn)和 Global 節(jié)點(diǎn)依然是單點(diǎn)，需要自行決定是否每一層都要使用雙節(jié)點(diǎn)重復(fù)采集進(jìn)行保活。也就是仍然會(huì)有單機(jī)瓶頸。

實(shí)際需求

1.長(zhǎng)期存儲(chǔ)：1 個(gè)月左右的數(shù)據(jù)存儲(chǔ)，每天可能新增幾十G，希望存儲(chǔ)的維護(hù)成本足夠小，有容災(zāi)和遷移。最好是存放在云上的 TSDB 或者對(duì)象存儲(chǔ)、文件存儲(chǔ)上。

2.無(wú)限拓展：我們有上百集群，幾千節(jié)點(diǎn)，上萬(wàn)個(gè)服務(wù)，單機(jī) Prometheus 無(wú)法滿(mǎn)足，且為了隔離性，最好按功能做 Shard，如 Node機(jī)器監(jiān)控與 K8S POD 資源等業(yè)務(wù)監(jiān)控分開(kāi)、主機(jī)監(jiān)控與日志監(jiān)控也分開(kāi)，者按業(yè)務(wù)類(lèi)型分開(kāi)。

3.全局視圖：按類(lèi)型分開(kāi)之后，雖然數(shù)據(jù)分散了，但監(jiān)控視圖需要整合在一起，一個(gè)Grafana 里n個(gè)面板就可以看到所有地域+集群的監(jiān)控?cái)?shù)據(jù)，操作更方便，不用多個(gè)Grafana的Dashboard 切來(lái)切去。

4.無(wú)侵入性：不會(huì)因?yàn)樵黾颖O(jiān)控業(yè)務(wù)而重新加載Prometheus配置，因?yàn)橹匦录虞dPrometheus配置對(duì)Prometheus穩(wěn)定是有風(fēng)險(xiǎn)的。

高可用架構(gòu)

按照實(shí)例進(jìn)行功能分區(qū)

從圖中看出，新增一臺(tái)機(jī)器上報(bào)的metrics只需在zookeeper注冊(cè)上報(bào)信息，prometheus自動(dòng)發(fā)現(xiàn)新增的metrics，不需要重啟prometheus或者重新加載prometheus配置。

數(shù)據(jù)上報(bào)和查詢(xún)

數(shù)據(jù)上報(bào)和查詢(xún)

Prometheus會(huì)以固定頻率去請(qǐng)求每個(gè)服務(wù)所提供的http url來(lái)獲取數(shù)據(jù)，每2小時(shí)為一個(gè)時(shí)間單位，首先會(huì)存儲(chǔ)到內(nèi)存中，當(dāng)?shù)竭_(dá)2小時(shí)后，會(huì)自動(dòng)寫(xiě)入磁盤(pán)中，prometheus采用的存儲(chǔ)方式稱(chēng)為“時(shí)間分片”，每個(gè)block都是一個(gè)獨(dú)立的數(shù)據(jù)庫(kù)。

thanos sidecar監(jiān)控prometheus本地block的chunks文件，當(dāng)chunks文件有增加時(shí)thanos sidecar會(huì)將chunks數(shù)據(jù)通過(guò)grpc上傳到thanos store，thanos store將接收到的數(shù)據(jù)落入S3云存儲(chǔ)。

grafana向thanos query發(fā)起查詢(xún)請(qǐng)求，thanos query從各個(gè)thanos sidecar拉取本地?cái)?shù)據(jù)，并且通過(guò)thanos store從S3云存儲(chǔ)上拉取歷史數(shù)據(jù)，最后數(shù)據(jù)在thanos query進(jìn)行匯總和去重返回給grafana。

如何保證架構(gòu)穩(wěn)定性

從數(shù)據(jù)上報(bào)和查詢(xún)流程圖中可以看到數(shù)據(jù)拉取和數(shù)據(jù)查詢(xún)是分開(kāi)的，prometheus只負(fù)責(zé)部分機(jī)器的數(shù)據(jù)拉取，當(dāng)grafana有歷史查詢(xún)的需求的時(shí)候（比如查詢(xún)?nèi)齻€(gè)月或者半年的數(shù)據(jù)），thanos query聚合后的數(shù)據(jù)存儲(chǔ)在內(nèi)存返回給grafana，當(dāng)數(shù)據(jù)比較大時(shí)，thanos query服務(wù)器內(nèi)存會(huì)寫(xiě)滿(mǎn)導(dǎo)致服務(wù)不可用，但是prometheus還在以固定頻率拉取metrics數(shù)據(jù)，這時(shí)候只需要重新恢復(fù)thanos query服務(wù)即可，不會(huì)對(duì)metrics數(shù)據(jù)連續(xù)性有任何影響。

名詞解釋

Sidecar

Sidecar作為一個(gè)單獨(dú)的進(jìn)程和已有的Prometheus實(shí)例運(yùn)行在一個(gè)server上，互不影響。Sidecar可以視為一個(gè)Proxy組件，所有對(duì)Prometheus的訪(fǎng)問(wèn)都通過(guò)Sidecar來(lái)代理進(jìn)行。通過(guò)Sidecar還可以將采集到的數(shù)據(jù)直接備份到云端對(duì)象存儲(chǔ)服務(wù)器。

Query

所有的Sidecar與Query直連，同時(shí)Query實(shí)現(xiàn)了一套Prometheus官方的HTTP API從而保證對(duì)外提供與Prometheus一致的數(shù)據(jù)源接口，Grafana可以通過(guò)同一個(gè)查詢(xún)接口請(qǐng)求不同集群的數(shù)據(jù)，Query負(fù)責(zé)找到對(duì)應(yīng)的集群并通過(guò)Sidecar獲取數(shù)據(jù)。Query本身也是水平可擴(kuò)展的，因而可以實(shí)現(xiàn)高可部署，而且Query可以實(shí)現(xiàn)對(duì)高可部署的Prometheus的數(shù)據(jù)進(jìn)行合并從而保證多次查詢(xún)結(jié)果的一致性，從而解決全局視圖和高可用的問(wèn)題。

Store

Store實(shí)現(xiàn)了一套和Sidecar完全一致的API提供給Query用于查詢(xún)Sidecar備份到云端對(duì)象存儲(chǔ)的數(shù)據(jù)。因?yàn)镾idecar在完成數(shù)據(jù)備份后，Prometheus會(huì)清理掉本地?cái)?shù)據(jù)保證本地空間可用。所以當(dāng)監(jiān)控人員需要調(diào)取歷史數(shù)據(jù)時(shí)只能去對(duì)象存儲(chǔ)空間獲取，而Store就提供了這樣一個(gè)接口。

Comactor

由于我們有數(shù)據(jù)長(zhǎng)期存儲(chǔ)的能力，也就可以實(shí)現(xiàn)查詢(xún)較大時(shí)間范圍的監(jiān)控?cái)?shù)據(jù)，當(dāng)時(shí)間范圍很大時(shí)，查詢(xún)的數(shù)據(jù)量也會(huì)很大，這會(huì)導(dǎo)致查詢(xún)速度非常慢。通常在查看較大時(shí)間范圍的監(jiān)控?cái)?shù)據(jù)時(shí)，我們并不需要那么詳細(xì)的數(shù)據(jù)，只需要看到大致就行。Thanos Compact 這個(gè)組件應(yīng)運(yùn)而生，它讀取對(duì)象存儲(chǔ)的數(shù)據(jù)，對(duì)其進(jìn)行壓縮以及降采樣再上傳到對(duì)象存儲(chǔ)，這樣在查詢(xún)大時(shí)間范圍數(shù)據(jù)時(shí)就可以只讀取壓縮和降采樣后的數(shù)據(jù)，極大地減少了查詢(xún)的數(shù)據(jù)量，從而加速查詢(xún)。

解決的問(wèn)題

可靠性

thanos sidecar 會(huì)記錄已經(jīng)拉取過(guò)的prometheus chunk文件，在prometheus新生成chunk文件的時(shí)候thanos sidecar會(huì)通過(guò)thanos store同步chunk數(shù)據(jù)到S3云存儲(chǔ)，實(shí)現(xiàn)了metrics數(shù)據(jù)無(wú)限期保留，保證了數(shù)據(jù)的可靠性。

穩(wěn)定性

Prometheus數(shù)據(jù)拉取和數(shù)據(jù)查詢(xún)拆分，不會(huì)因?yàn)榇蟛樵?xún)導(dǎo)致Prometheus內(nèi)存暴增后服務(wù)掛掉，影響數(shù)據(jù)拉取，出現(xiàn)metrics數(shù)據(jù)斷層。

可維護(hù)性

運(yùn)維和開(kāi)發(fā)人員不用修改prometheus配置，所有操作通過(guò)業(yè)務(wù)控制臺(tái)維護(hù)zookeeper數(shù)據(jù)完成。

可伸縮性

一臺(tái)Prometheus node節(jié)點(diǎn)只拉取幾十臺(tái)服務(wù)器的metrics數(shù)據(jù)，隨著業(yè)務(wù)規(guī)模的變化靈活調(diào)整Prometheus node節(jié)點(diǎn)的數(shù)量。

目前開(kāi)源社區(qū)和市面上有很多Prometheus高可用方案，但是都不能完全滿(mǎn)足需求，隨著我們的集群規(guī)模越來(lái)越大，監(jiān)控?cái)?shù)據(jù)的種類(lèi)和數(shù)量也越來(lái)越多。更多prometheus相關(guān)技術(shù)資料，請(qǐng)持續(xù)關(guān)注尊龍時(shí)凱社區(qū)和prometheus技術(shù)分享。

• 

  Prometheus技術(shù)分享——prometheus自定義告警規(guī)則解析和配置

  2022/11/08 6994

  對(duì)于運(yùn)維監(jiān)控而言，除了監(jiān)控展示以外，另一個(gè)重要的需求無(wú)疑就是告警了。良好的告警可以幫助運(yùn)維人員及時(shí)的發(fā)現(xiàn)問(wèn)題，處理問(wèn)題并防范于未然，是運(yùn)維工作中不...

  View details

• 

  Prometheus技術(shù)分享——prometheus的函數(shù)與計(jì)算公式詳解

  2022/12/28 7851

  prometheus的函數(shù)與計(jì)算公式詳解

  View details

• 

  Prometheus技術(shù)分享——Prometheus特點(diǎn)，組件，局限探討

  2022/11/11 6531

  這一期尊龍時(shí)凱君主要跟大家來(lái)探討新一代的開(kāi)源監(jiān)控prometheus，我們知道 zabbix 在監(jiān)控界占有不可撼動(dòng)的地位，功能強(qiáng)大。但是對(duì)容器監(jiān)控顯得力不從心。為解決監(jiān)...

  View details

• 

  尊龍時(shí)凱監(jiān)控 x Prometheus：解鎖高效運(yùn)維新技能

  2024/10/16 4203

  尊龍時(shí)凱監(jiān)控對(duì)接Prometheus

  View details