作者：淡唯（啃唯）、陽(yáng)其凱（逸陵）

引言

Prometheus 作為目前最主流的可觀(guān)測(cè)開(kāi)源項(xiàng)目之一，已經(jīng)成為云原生監(jiān)控的事實(shí)標(biāo)準(zhǔn)，被眾多企業(yè)廣泛應(yīng)用。在使用 Prometheus 的時(shí)候，我們經(jīng)常會(huì)遇到全局視圖的需求，但是數(shù)據(jù)確分散在不同的 Prometheus 實(shí)例中，遇到這種情況該怎么解決呢？本文列舉了社區(qū)一般解決方案，同時(shí)給出了阿里云的全局視圖解決方案，最后給出了某客戶(hù)基于阿里云 Prometheus 的實(shí)踐案例，希望能給您帶來(lái)啟發(fā)與幫助。

背景

在使用阿里云 Promtheus 時(shí)，由于地域的限制、業(yè)務(wù)原因或者其他原因，經(jīng)常會(huì)遇到 Prometheus 多實(shí)例的場(chǎng)景。如下圖所示，某用戶(hù)在杭州區(qū)域有多個(gè) Prometheus “通用”實(shí)例。在多實(shí)例的背景下，我們經(jīng)常會(huì)遇到一些問(wèn)題。

2.1.?問(wèn)題 1-單一 Grafana 大盤(pán)數(shù)據(jù)源

我們知道 Grafana 大盤(pán)是觀(guān)測(cè) Prometheus 數(shù)據(jù)最常規(guī)、最普遍的方式。通常情況下，每觀(guān)測(cè)一個(gè) Prometheus 集群就需要?jiǎng)?chuàng)建一個(gè)數(shù)據(jù)源，假設(shè)我有 100 個(gè) Prometheus 集群，就需要?jiǎng)?chuàng)建 100 個(gè)數(shù)據(jù)源。聽(tīng)著是個(gè)很麻煩的事情，如果你還能接受，那么繼續(xù)往下看。

在編輯 Grafana panel 并填寫(xiě) PromQL 時(shí)我們可以選擇數(shù)據(jù)源，但是為了保證數(shù)據(jù)查詢(xún)和展示的一致性與簡(jiǎn)潔性，Grafana 僅允許一個(gè) panel 使用一個(gè)數(shù)據(jù)源。

如果我們需要在一個(gè)大盤(pán)內(nèi)同時(shí)繪制多個(gè)數(shù)據(jù)源的 panel，那么使用以上 100 個(gè)數(shù)據(jù)源時(shí)就會(huì)產(chǎn)生 100 個(gè) panel，并且需要編輯 100 次 panel 并編寫(xiě) 100 次 PromQL，非常不利于運(yùn)維。理想狀態(tài)下應(yīng)該是合并為一個(gè) panel，并且每個(gè)數(shù)據(jù)源一個(gè)時(shí)間線(xiàn)，不僅方便指標(biāo)監(jiān)控，更是大大減少大盤(pán)的維護(hù)動(dòng)作。

2.2.?問(wèn)題 2-實(shí)例間數(shù)據(jù)計(jì)算與查詢(xún)

當(dāng)不同的業(yè)務(wù)使用了不同的 Prometheus 實(shí)例，但這些實(shí)例都有在上報(bào)著相同的指標(biāo)，我們希望將這些數(shù)據(jù)做聚合（sum）、增長(zhǎng)率（rate）等運(yùn)算，由于存在著實(shí)例間的存儲(chǔ)隔離，這樣的操作是不允許的。同時(shí)我們并不希望把這些數(shù)據(jù)都上報(bào)到同一個(gè)實(shí)例中，因?yàn)楦鶕?jù)業(yè)務(wù)場(chǎng)景，可能這些數(shù)據(jù)來(lái)自不同的 ACK 集群、ECS、Flink 實(shí)例等，甚至數(shù)據(jù)來(lái)源不是同一個(gè)地區(qū)，因此保持實(shí)例級(jí)別的隔離是有必要的。

社區(qū)解決方案

所以，針對(duì)多 Prometheus 實(shí)例存在的上述問(wèn)題，社區(qū)是如何解決的呢？

3.1.?Federation 方案

Prometheus Federation 機(jī)制是 Promehteus 本身提供的一種集群化的擴(kuò)展能力,但是也可以用于解決數(shù)據(jù)的中心化查詢(xún)問(wèn)題。當(dāng)我們要監(jiān)控的服務(wù)很多的時(shí)候，我們會(huì)部署很多的 Prometheus 節(jié)點(diǎn)分別 Pull 這些服務(wù)暴露的 Metrics，Federation 機(jī)制可以將這些分別部署的 Prometheus 節(jié)點(diǎn)所獲得的指標(biāo)聚合起來(lái)，存放在一個(gè)中心點(diǎn)的 Prometheus。如下圖所示為常見(jiàn)的 Federation 架構(gòu)：

邊緣節(jié)點(diǎn)每一個(gè) Prometheus 實(shí)例都會(huì)包含一個(gè)/federate 的接口，用于獲取一組指定的時(shí)間序列的監(jiān)控?cái)?shù)據(jù)，Global 節(jié)點(diǎn)只需要配置一個(gè)采集任務(wù)，用于從邊緣節(jié)點(diǎn)獲取監(jiān)控?cái)?shù)據(jù)即可。為了更好的理解 Federation 機(jī)制，下面給出了 Global Prometheus 的配置文件的配置。

scrape_configs:- job_name: 'federate'scrape_interval: 10shonor_labels: truemetrics_path: '/federate'# 根據(jù)實(shí)際業(yè)務(wù)情況進(jìn)行Pull metrics，通過(guò)match參數(shù)，配置要拉取的Metricsparams:'match[]':- '{job="Prometheus"}'- '{job="node"}'static_configs:# 其他 Prometheus 節(jié)點(diǎn)- targets:- 'Prometheus-follower-1:9090'- 'Prometheus-follower-2:9090'

3.2.?Thanos 方案

對(duì)于開(kāi)源的 Prometheus 版本，我們可以使用 Thanos 實(shí)現(xiàn)聚合查詢(xún)，如下為 Thanos 的 Sidecar 部署模式：

這張圖中包含了 Thanos 的幾個(gè)核心組件（但并不包括所有組件）：

• Thanos Sidecar：連接 Prometheus，將其數(shù)據(jù)提供給 Thanos Query 查詢(xún)，并且將其上傳到對(duì)象存儲(chǔ)以供長(zhǎng)期存儲(chǔ)。
• Thanos Query：實(shí)現(xiàn)了 Prometheus API，提供全局查詢(xún)視圖將來(lái) StoreAPI 提供的數(shù)據(jù)進(jìn)行聚合最終返回給查詢(xún)數(shù)據(jù)的 client（如 Grafana）。
• Thanos Store Gateway：將對(duì)象存儲(chǔ)的數(shù)據(jù)暴露給 Thanos Query 去查詢(xún)。
• Thanos Compact：將對(duì)象存儲(chǔ)中的數(shù)據(jù)進(jìn)行壓縮和降低采樣率，加速大時(shí)間區(qū)間監(jiān)控?cái)?shù)據(jù)查詢(xún)的速度。
• Thanos Ruler：對(duì)監(jiān)控?cái)?shù)據(jù)進(jìn)行評(píng)估和告警，還可以計(jì)算出新的監(jiān)控?cái)?shù)據(jù)，將這些新數(shù)據(jù)提供給 Thanos Query 查詢(xún)并且/或者上傳到對(duì)象存儲(chǔ)，以供長(zhǎng)期存儲(chǔ)。
• Thanos Receiver：從 Prometheus 的遠(yuǎn)程寫(xiě)入 WAL 接收數(shù)據(jù)，將其公開(kāi)和/或上傳到云存儲(chǔ)。

那 Thanos 如何實(shí)現(xiàn) global 查詢(xún)的呢？

Thanos Query 實(shí)現(xiàn)了 Prometheus 的 HTTP API，這樣查詢(xún) Prometheus 監(jiān)控?cái)?shù)據(jù)的 client 就不直接查詢(xún) Prometheus 本身了，而是去查詢(xún) Thanos Query，Thanos Query 再去下游多個(gè)存儲(chǔ)了數(shù)據(jù)的地方查數(shù)據(jù)，最后將這些數(shù)據(jù)聚合去重后返回給 client，從而實(shí)現(xiàn)了 global 查詢(xún)。而為了實(shí)現(xiàn) Thanos Query 去查下游分散的數(shù)據(jù)，Thanos 為此抽象了?Store API?的內(nèi)部 gRPC 接口，其它一些組件通過(guò)這個(gè)接口來(lái)暴露數(shù)據(jù)給 Thanos Query。

在上述的架構(gòu)中單個(gè)的 Prometheus 會(huì)將采集的數(shù)據(jù)存到本機(jī)磁盤(pán)上，每個(gè) Prometheus 附帶部署一個(gè) Sidecar，這個(gè) Sidecar 實(shí)現(xiàn) Thanos Store API，由于 Prometheus 本地磁盤(pán)有限，所以對(duì)于長(zhǎng)時(shí)間周期的存在通過(guò) Sidecar 的 Thanos Store API 會(huì)將數(shù)據(jù)存儲(chǔ)在對(duì)象存儲(chǔ)；無(wú)論對(duì)于單個(gè) Prometheus 上的數(shù)據(jù)查詢(xún)還是對(duì)象存儲(chǔ)的查詢(xún)都是基于“Store API”，如下對(duì)查詢(xún)進(jìn)行進(jìn)一步的抽象。

3.3.?Prometheus?Remote?Write 方案

Remote Write 也是解決 Prometheus 多實(shí)例全局查詢(xún)的有效解決方案，其基本思想與 Prometheus Federation 機(jī)制非常類(lèi)似，將分別部署的 Prometheus 節(jié)點(diǎn)所獲得的指標(biāo)利用 Remote Write 機(jī)制存放在一個(gè)中心點(diǎn)的 Prometheus 或者第三方存儲(chǔ)中。

用戶(hù)在 Prometheus 配置文件中指定 Remote Write 的 URL 地址，一旦設(shè)置了該配置項(xiàng)，Prometheus 將采集到的樣本數(shù)據(jù)通過(guò) HTTP 的形式發(fā)送給適配器 (Adaptor)，而用戶(hù)則可以在適配器中對(duì)接外部任意的服務(wù)。外部服務(wù)可以是開(kāi)源 Prometheus，也可以是真正的存儲(chǔ)系統(tǒng)，也可以是公有云的存儲(chǔ)服務(wù)。

如下為樣例，修改 Prometheus.yml 添加 Remote Storage 相關(guān)的配置內(nèi)容。

remote_write:- url: "http://*****:9090/api/v1/write"

阿里云解決方案

4.1.?阿里云 Prometheus 全局聚合實(shí)例解決方案

4.1.1.?阿里云 Prometheus 全局聚合實(shí)例方案介紹

阿里云推出了“Prometheus 全局聚合實(shí)例”，其目標(biāo)是實(shí)現(xiàn)跨多個(gè)阿里云 Prometheus 實(shí)例的數(shù)據(jù)聚合，在查詢(xún)數(shù)據(jù)時(shí)同時(shí)從多個(gè)實(shí)例中讀取數(shù)據(jù)，其原理為 “查詢(xún)時(shí)指標(biāo)聚合”。

使用阿里云全局聚合實(shí)例（以下簡(jiǎn)稱(chēng) Gloabal View）可以保證單個(gè)阿里云 Prometheus 實(shí)例間的數(shù)據(jù)隔離，即每個(gè) Prometheus 實(shí)例后端擁有獨(dú)立的存儲(chǔ)，不是通過(guò)合并數(shù)據(jù)到一個(gè)中央存儲(chǔ)，而是在查詢(xún)時(shí)動(dòng)態(tài)地從各個(gè)實(shí)例的存儲(chǔ)中檢索需要的數(shù)據(jù)。這樣，當(dāng)用戶(hù)或者前端應(yīng)用程序發(fā)起查詢(xún)請(qǐng)求時(shí)，Global View 會(huì)并行地對(duì)所有相關(guān) Prometheus 實(shí)例進(jìn)行查詢(xún)，并將結(jié)果匯總，提供一個(gè)統(tǒng)一的視圖。

4.1.2.?對(duì)比分析

下面針對(duì)開(kāi)源 Prometheus Federation 以及 Thanos 方案以及阿里云全局聚合實(shí)例方案進(jìn)行簡(jiǎn)單的匯總說(shuō)明。

1）Prometheus?Federation

雖然 Prometheus Federation 能解決全局聚合查詢(xún)，但是還存在一些問(wèn)題。

• 邊緣節(jié)點(diǎn)和 Global 節(jié)點(diǎn)依然是單點(diǎn)，需要自行決定是否每一層都要使用雙節(jié)點(diǎn)重復(fù)采集進(jìn)行?；?#xff0c;也就是仍然會(huì)有單機(jī)瓶頸。
• 對(duì)歷史數(shù)據(jù)的存儲(chǔ)問(wèn)題仍舊未得到解決，必須依賴(lài)第三方存儲(chǔ)，切缺少對(duì)歷史數(shù)據(jù)的降準(zhǔn)采樣能力。
• 整體運(yùn)維成本比較高。
• 可擴(kuò)展性較差，添加或移除 Prometheus 實(shí)例需要修改配置文件。

2）Thanos?Federation

• 架構(gòu)比較復(fù)雜，運(yùn)維成本較高。
• 仍存在 Prometheus 副本的單點(diǎn)問(wèn)題。
• 時(shí)間線(xiàn)發(fā)散的情況下，支持的上限不夠，不提供維度發(fā)散場(chǎng)景優(yōu)化。
• 不支持降采樣，長(zhǎng)周期查詢(xún)性能不高。
• 不支持算子下推，大數(shù)據(jù)量的請(qǐng)求性能有限，并且處理開(kāi)銷(xiāo)大。

3）阿里云全局聚合實(shí)例

• Prometheus 實(shí)例托管、免運(yùn)維。
• 支持圖形化界面進(jìn)行多實(shí)例的管理，靈活性強(qiáng)、可擴(kuò)展性高。這種模式允許系統(tǒng)輕松地添加或移除阿里云 Prometheus 實(shí)例，而不需要重新配置整個(gè)存儲(chǔ)系統(tǒng)。
• 不占用額外的存儲(chǔ)空間。由于沒(méi)有將數(shù)據(jù)復(fù)制到集中的存儲(chǔ)中，這種方法可以節(jié)約存儲(chǔ)空間，每個(gè) Prometheus 實(shí)例只需要維護(hù)自己的數(shù)據(jù)集。在不額外配置存儲(chǔ)的情況下，查詢(xún)到的數(shù)據(jù)僅是臨時(shí)用于展示，真正的數(shù)據(jù)持久化仍然歸于被聚合的實(shí)例。
• 隔離性：每個(gè)實(shí)例的自治性能夠提高系統(tǒng)的容錯(cuò)性，因?yàn)閱蝹€(gè)實(shí)例的問(wèn)題不會(huì)直接影響到其他實(shí)例。
• 支持跨 region 實(shí)例以及跨賬號(hào)實(shí)例聚合，滿(mǎn)足企業(yè)個(gè)性化的需求。

但是需要注意的是 Thanos Federation 與阿里云全局聚合實(shí)例都是非合并數(shù)據(jù)的方式實(shí)現(xiàn)全局查詢(xún)。由于需要在查詢(xún)時(shí)從多個(gè)數(shù)據(jù)源檢索數(shù)據(jù)，這可能會(huì)導(dǎo)致查詢(xún)性能下降，特別是當(dāng)查詢(xún)涉及大量不需要的數(shù)據(jù)時(shí)，需要等待多個(gè)數(shù)據(jù)源篩選出需要的數(shù)據(jù)，等待這些數(shù)據(jù)處理的過(guò)程可能導(dǎo)致查詢(xún)超時(shí)或長(zhǎng)時(shí)間等待。

4.1.3.?阿里云 Prometheus 全局聚合實(shí)例實(shí)踐

阿里云 Prometheus 極大簡(jiǎn)化了用戶(hù)的操作，無(wú)需手動(dòng)部署 Prometheus 擴(kuò)展組件，用戶(hù)通過(guò)控制臺(tái)操作便可實(shí)現(xiàn)全局視圖的功能。在創(chuàng)建 Prometheus 實(shí)例時(shí)選擇“全局聚合實(shí)例”，勾選需要聚合的實(shí)例，并選擇查詢(xún)前端所在的地區(qū)（影響查詢(xún)域名的生成），點(diǎn)擊“保存”后即可。

進(jìn)入創(chuàng)建好的全局聚合實(shí)例，點(diǎn)擊任意大盤(pán)，可以看到該實(shí)例已經(jīng)能查詢(xún)到剛剛聚合的其他實(shí)例數(shù)據(jù)。實(shí)現(xiàn)了我們?cè)?Grafana 一個(gè)數(shù)據(jù)源查詢(xún)多個(gè)實(shí)例數(shù)據(jù)的需求。

4.2.?阿里云 Prometheus?Remote?Write 解決方案

4.2.1.?阿里云 Prometheus?Remote?Write 解決方案

阿里云 Prometheus remote write 的能力是阿里云 Prometheus 數(shù)據(jù)投遞的原子能力。Prometheus 數(shù)據(jù)投遞的原理為 “存儲(chǔ)時(shí)的指標(biāo)聚合” ，其目標(biāo)是將跨多個(gè) Prometheus 實(shí)例的數(shù)據(jù)通過(guò) ETL 服務(wù)提取出來(lái)，再寫(xiě)入某個(gè)聚合實(shí)例的存儲(chǔ)中。

通過(guò)這種方式，相同的 Prometheus 數(shù)據(jù)可以同時(shí)存儲(chǔ)在不同的實(shí)例中：

1. 在被聚合的 Prometheus 實(shí)例中，存儲(chǔ)著該實(shí)例所有的原始數(shù)據(jù)，包括期望被聚合查詢(xún)的實(shí)例以及其他數(shù)據(jù)。用于原業(yè)務(wù)場(chǎng)景中單實(shí)例的查詢(xún)。

2. 在中央/聚合 Prometheus 中，存儲(chǔ)著其他“被聚合實(shí)例”的“期望被聚合的數(shù)據(jù)”，在統(tǒng)一管理的場(chǎng)景下，可以通過(guò)該實(shí)例獲取全局視圖的查詢(xún)，執(zhí)行跨實(shí)例數(shù)據(jù)的搜索。

4.2.2.?阿里云 Prometheus?Remote?Write?VS?社區(qū) Prometheus?Remote?Write

1）Prometheus?Remote?Write

開(kāi)源 Remote Write 的形式最大的弊端在于對(duì) Prometheus Agent 的影響，在 Agent 設(shè)置 Remote Write 會(huì)增加 Agent 的資源消耗，影響數(shù)據(jù)采集的性能，而這一點(diǎn)往往是致命的。

2）阿里云 Prometheus?Remote?Write

阿里云 Prometheus Remote Write 的優(yōu)勢(shì)還是非常明顯的。

• 查詢(xún)性能高：因?yàn)橹淮鎯?chǔ)了必要的聚合數(shù)據(jù)，聚合 Prometheus 實(shí)例的查詢(xún)響應(yīng)時(shí)間更短，極大地提升了用戶(hù)體驗(yàn)。此外，在查詢(xún)時(shí)本質(zhì)上只是對(duì)一個(gè) Prometheus 實(shí)例進(jìn)行操作，而非多個(gè)實(shí)例，讀寫(xiě)的性能、計(jì)算的性能更高。
• 數(shù)據(jù)質(zhì)量高：經(jīng)過(guò)篩選后的數(shù)據(jù)更加干凈，沒(méi)有不必要的?“臟數(shù)據(jù)”，這有助于進(jìn)行更加精準(zhǔn)和有效的數(shù)據(jù)分析。
• 提供豐富的 ETL 能力:?在寫(xiě)入聚合實(shí)例之前提供豐富的處理能力，如過(guò)濾篩選、指標(biāo)富化等。
• 圖形化配置，操作簡(jiǎn)單便捷。

同時(shí)當(dāng)然也有一些劣勢(shì)，大家需要綜合權(quán)衡取舍。

• 費(fèi)用問(wèn)題：由于需要額外的 Prometheus 實(shí)例來(lái)作為聚合和全局查詢(xún)的存儲(chǔ)點(diǎn)，這意味著需要額外的 TSDB 后端存儲(chǔ)需要被聚合的數(shù)據(jù)，這些獨(dú)立的存儲(chǔ)空間是需要計(jì)費(fèi)的。
• 網(wǎng)絡(luò)消耗：在數(shù)據(jù)投遞過(guò)程中，跨網(wǎng)絡(luò)的數(shù)據(jù)傳輸會(huì)增加帶寬占用，特別是在跨數(shù)據(jù)中心或?qū)拵в邢薜沫h(huán)境中，所以需要進(jìn)行合理的評(píng)估。

4.2.3.?阿里云 Prometheus?Remote?Write 使用

1. 在左側(cè)導(dǎo)航欄，選擇?Prometheus 監(jiān)控?>?數(shù)據(jù)投遞（beta） ，進(jìn)入可觀(guān)測(cè)監(jiān)控 Prometheus 版的數(shù)據(jù)投遞頁(yè)面。

2. 在數(shù)據(jù)投遞頁(yè)面的頂部菜單欄，選擇地域，然后單擊新建任務(wù)。

3. 在對(duì)話(huà)框中輸入任務(wù)名稱(chēng)和任務(wù)描述后，單擊確定。

4. 在任務(wù)編輯頁(yè)面，配置數(shù)據(jù)源和投遞目標(biāo)。

5. 配置 Prometheus Remote Write 地址以及認(rèn)證方式。

6. 配置網(wǎng)絡(luò)。

4.3.?阿里云解決方案總結(jié)與選擇

阿里云提供了全局聚合實(shí)例以及數(shù)據(jù)投遞-Remote Write解決方案各有優(yōu)劣。

Prometheus 全局聚合實(shí)例的設(shè)計(jì)理念是在保持 Prometheus 實(shí)例的存儲(chǔ)獨(dú)立性的同時(shí)，提供一個(gè)統(tǒng)一的接口對(duì)多個(gè)實(shí)例進(jìn)行查詢(xún)來(lái)實(shí)現(xiàn)全局視圖。該方案的核心理念為“查詢(xún)時(shí)指標(biāo)聚合”，也就是說(shuō)數(shù)據(jù)原封不動(dòng)地存儲(chǔ)在多個(gè)實(shí)例中，當(dāng)統(tǒng)一查詢(xún)時(shí)才將多個(gè)實(shí)例的數(shù)據(jù)獲取并聚合。這種方法有其明顯的優(yōu)點(diǎn)，如節(jié)省存儲(chǔ)空間，但也存在一些挑戰(zhàn)，對(duì)于實(shí)例數(shù)量較多、數(shù)據(jù)量大的場(chǎng)景查詢(xún)性能會(huì)受較大影響。

Prometheus 數(shù)據(jù)投遞-Remote Write 的設(shè)計(jì)理念是將查詢(xún)的流量轉(zhuǎn)化為數(shù)據(jù)寫(xiě)入的流量，它消耗了額外的存儲(chǔ)空間提供多實(shí)例聚合數(shù)據(jù)的方案，它通過(guò)在寫(xiě)入之前篩選數(shù)據(jù)，使得中心實(shí)例精簡(jiǎn)地存儲(chǔ)著聚合數(shù)據(jù)。該方案的核心理念為“存儲(chǔ)時(shí)指標(biāo)聚合”，此時(shí)多個(gè)實(shí)例的數(shù)據(jù)副本將存儲(chǔ)在統(tǒng)一中心化實(shí)例中，對(duì)多個(gè)實(shí)例的查詢(xún)將轉(zhuǎn)化為單實(shí)例查詢(xún)，大大提升了查詢(xún)速率與數(shù)據(jù)質(zhì)量。

案例分析

5.1.?某客戶(hù)運(yùn)維平臺(tái)可觀(guān)測(cè)現(xiàn)狀

5.1.1.?介紹

下圖所示為某客戶(hù)的內(nèi)部運(yùn)維平臺(tái)，這里暫且稱(chēng)為“A 運(yùn)維平臺(tái)”，客戶(hù)公司利用 A 運(yùn)維平臺(tái)進(jìn)行公司內(nèi)部 K8s 集群的生命周期管理。在 A 運(yùn)維平臺(tái)中，只能針對(duì)單個(gè)集群進(jìn)行相關(guān)監(jiān)控?cái)?shù)據(jù)的查看，當(dāng)有多個(gè)集群有問(wèn)題需要排查時(shí)，只能一個(gè)一個(gè)處理。

同樣的，在使用 Grafana 時(shí)，當(dāng)前大盤(pán)只能查看某個(gè)集群的具體數(shù)據(jù)，無(wú)法對(duì)多個(gè)集群同時(shí)監(jiān)控。

此時(shí) SRE 團(tuán)隊(duì)無(wú)法對(duì)所有集群狀態(tài)有全局的視角，難以準(zhǔn)確獲取該產(chǎn)品的健康狀態(tài)。 在平時(shí)的運(yùn)維工作中，大多依賴(lài)告警提示某個(gè)集群處于非健康狀態(tài)。目前 A 運(yùn)維平臺(tái)托管了上百個(gè)集群，全部依賴(lài)告警會(huì)有消息過(guò)多的風(fēng)險(xiǎn)，導(dǎo)致等級(jí)較高的故障無(wú)法快速定位。

5.1.2.?訴求

當(dāng)前在“A 運(yùn)維平臺(tái)”的運(yùn)維管理面臨一個(gè)挑戰(zhàn)：缺少對(duì)所有地區(qū)集群狀態(tài)的一目了然的全局視圖?！癆 運(yùn)維平臺(tái)”的目標(biāo)是配置單一的 Grafana 大盤(pán)，通過(guò)引入單一的數(shù)據(jù)源，實(shí)現(xiàn)對(duì)個(gè)產(chǎn)品線(xiàn)整所有租戶(hù)集群運(yùn)行狀況的實(shí)時(shí)監(jiān)控這應(yīng)。包括關(guān)鍵指標(biāo)的可視化，例如集群的整體狀態(tài)（包括集群的數(shù)量、各節(jié)點(diǎn)和 Pod 的數(shù)量、全網(wǎng)集群的? CPU 使用情況等），以及\APIServer 的 SLO（服務(wù)水平目標(biāo)）狀態(tài)（諸如全網(wǎng)非 500 響應(yīng)的動(dòng)詞比例、50X 錯(cuò)誤的詳細(xì)信息、請(qǐng)求成功率等）。

通過(guò)這個(gè)精心設(shè)計(jì)的大盤(pán)，運(yùn)維團(tuán)隊(duì)可以迅速鎖定任何處于非健康狀態(tài)的集群，快速概覽業(yè)務(wù)量，并對(duì)潛在問(wèn)題進(jìn)行快速調(diào)查，大幅提升運(yùn)維效率和響應(yīng)速度。這樣的集成不僅優(yōu)化了監(jiān)控流程，也為運(yùn)維團(tuán)隊(duì)提供了一個(gè)強(qiáng)大的工具，以確保系統(tǒng)的穩(wěn)定性和服務(wù)的連續(xù)性。

5.1.3.?難點(diǎn)

跨大洲數(shù)據(jù)傳輸： “A 運(yùn)維平臺(tái)”的場(chǎng)景涉及到全球所有區(qū)域，SRE 團(tuán)隊(duì)在運(yùn)維時(shí)希望能在杭州區(qū)域的大盤(pán)查看全球所有區(qū)域的實(shí)例數(shù)據(jù)，這就涉及到了跨大洲的數(shù)據(jù)傳輸。當(dāng)在 Grafana 進(jìn)行跨大洲的實(shí)例查詢(xún)時(shí)，因?yàn)榫W(wǎng)絡(luò)傳輸?shù)难舆t存在，經(jīng)常性地出現(xiàn)查詢(xún)超時(shí)的問(wèn)題。

請(qǐng)注意： 當(dāng)您使用 Promethues 配置數(shù)據(jù)跨境時(shí)。您同意并確認(rèn)，您完全擁有該份業(yè)務(wù)數(shù)據(jù)的所有處置權(quán)限，對(duì)數(shù)據(jù)傳輸?shù)男袨槿珯?quán)負(fù)責(zé)。您應(yīng)確保您的數(shù)據(jù)傳輸符合所有適用法律，包括提供充分的數(shù)據(jù)安全保護(hù)技術(shù)和策略，履行獲得個(gè)人充分明示同意、完成數(shù)據(jù)出境安全評(píng)估和申報(bào)等法定義務(wù)，且你承諾您的業(yè)務(wù)數(shù)據(jù)不含任何所適用法律限制、禁止傳輸或披露的內(nèi)容。如您未遵守前述聲明與保證，您將承擔(dān)對(duì)應(yīng)的法律后果，導(dǎo)致阿里云和或其他關(guān)聯(lián)公司遭受任何損失的，您應(yīng)承擔(dān)賠償責(zé)任。

單實(shí)例數(shù)據(jù)量過(guò)大： 并非所有的數(shù)據(jù)都需要全區(qū)域全實(shí)例聚合查詢(xún)，全球視角的運(yùn)維一般只關(guān)心某幾個(gè)表示集群狀態(tài)的指標(biāo)；或是針對(duì)某些指標(biāo)，只關(guān)心幾個(gè)特定的 label（namespace）。隨著被“A 運(yùn)維平臺(tái)”托管的集群增加、租戶(hù)增加，上報(bào)指標(biāo)的 label 越來(lái)越多樣化，可能涉及到指標(biāo)緯度發(fā)散的問(wèn)題。目前針對(duì)指標(biāo)緯度發(fā)散的問(wèn)題業(yè)界仍沒(méi)有統(tǒng)一的解決方案，此時(shí)查詢(xún)會(huì)大量消耗 TSDB 的內(nèi)存。在單 Prometheus 實(shí)例的場(chǎng)景下對(duì)這類(lèi)發(fā)散指標(biāo)查詢(xún)時(shí)就已經(jīng)給 TSDB 實(shí)例很大的壓力，當(dāng)一次性獲取“A 運(yùn)維平臺(tái)”所有 Prometheus 實(shí)例數(shù)據(jù)時(shí)給服務(wù)器的壓力過(guò)大。

超大空間跨度的查詢(xún)： 需要對(duì)某幾個(gè)指標(biāo)，把當(dāng)前區(qū)域/全球的所有實(shí)例數(shù)據(jù)求和等計(jì)算。在問(wèn)題 2 單實(shí)例數(shù)據(jù)量的基礎(chǔ)上，推廣至“A 運(yùn)維平臺(tái)”?上百個(gè) Prometheus 實(shí)例，此時(shí)所有實(shí)例涉及到的數(shù)據(jù)量更加龐大。當(dāng) TSDB 進(jìn)行查詢(xún)、篩選、計(jì)算操作時(shí)，會(huì)占用大量的內(nèi)存，一般的計(jì)算資源配額無(wú)法滿(mǎn)足。

5.2.?通過(guò)數(shù)據(jù)投遞實(shí)現(xiàn)中心化數(shù)據(jù)查詢(xún)

5.2.1.?方案選型

是選擇全局聚合實(shí)例還是數(shù)據(jù)投遞？在“A 運(yùn)維平臺(tái)”的場(chǎng)景下，針對(duì)以上討論的需求以及難點(diǎn)，選擇數(shù)據(jù)投遞是更好的方案。有如下原因：

1）傳輸延遲容忍度

當(dāng)使用數(shù)據(jù)投遞時(shí)，鏈路能承受更大的網(wǎng)絡(luò)延遲。

• 當(dāng)使用全局聚合實(shí)例查詢(xún)時(shí)：

  • 每次請(qǐng)求都會(huì)產(chǎn)生多個(gè)跨大洲的網(wǎng)絡(luò)延遲。在測(cè)試過(guò)程中，跨大洲網(wǎng)絡(luò)傳輸延遲在 500ms～700ms 間，在特殊時(shí)段、網(wǎng)絡(luò)波動(dòng)等情況下延遲甚至能達(dá)到 1min+，極易造成查詢(xún)超時(shí)。
  • “A 運(yùn)維平臺(tái)”實(shí)例部署在全球各個(gè)地區(qū)，當(dāng)其中 99% 的數(shù)據(jù)都成功查詢(xún)，某個(gè)地區(qū)由于網(wǎng)絡(luò)波動(dòng)導(dǎo)致查詢(xún)超時(shí)，那么其他 99% 成功查詢(xún)到的數(shù)據(jù)也就不可用了，對(duì)數(shù)據(jù)齊全度要求很高。
  • 在查詢(xún)時(shí)客戶(hù)的 PromQL、時(shí)間跨度是不固定的，導(dǎo)致查詢(xún)的數(shù)據(jù)量是任意的。當(dāng)查詢(xún)數(shù)據(jù)量過(guò)大，數(shù)據(jù)可能會(huì)分到多個(gè) HTTP 包傳輸（受限于網(wǎng)絡(luò)提供商），此時(shí)網(wǎng)絡(luò)延遲很大。

• 當(dāng)使用數(shù)據(jù)投遞時(shí)：

  • 數(shù)據(jù)投遞的數(shù)據(jù)網(wǎng)絡(luò)傳輸不會(huì)隨著用戶(hù)查詢(xún)量改變，而是將各 Prometheus 實(shí)例采集到的數(shù)據(jù)實(shí)時(shí)的投遞至中心化 Prometheus 實(shí)例中，此時(shí)數(shù)據(jù)包不超過(guò) 1MB 大小，網(wǎng)絡(luò)延遲維持在固定的范圍。
  • 聚合數(shù)據(jù)都保存在中心化 Prometheus 實(shí)例中，因此只需保證對(duì)該實(shí)例的查詢(xún)不出錯(cuò)即可，無(wú)需考慮查詢(xún)齊全度的問(wèn)題。
  • 即使經(jīng)過(guò)了超大的跨大洲網(wǎng)絡(luò)傳輸，我們?nèi)匀荒芡ㄟ^(guò)攢批、重試等方式保證數(shù)據(jù)成功寫(xiě)入了中心 Prometheus 實(shí)例。盡管中心實(shí)例中的最新數(shù)據(jù)與當(dāng)前時(shí)間有分鐘級(jí)的延遲，查詢(xún)成功率有了保證。

2）節(jié)省計(jì)算資源

執(zhí)行 PromQL 查詢(xún)時(shí)，指標(biāo)的時(shí)間線(xiàn)數(shù)量決定了查詢(xún)所需的 CPU、內(nèi)存資源。也就是說(shuō)指標(biāo)的 label 越多樣，所消耗的資源就越多。

• 當(dāng)使用全局聚合實(shí)例查詢(xún)時(shí)：

  • 被聚合的實(shí)例存儲(chǔ)著所有的原始數(shù)據(jù)，查詢(xún)的資源消耗較大。由于 TSDB 的特性，即使進(jìn)行了 label 的篩選，仍有可能將該時(shí)間段的全量數(shù)據(jù)加載到內(nèi)存中。在“A 運(yùn)維平臺(tái)”的場(chǎng)景中，由于每次查詢(xún)都涉及到海量數(shù)據(jù)，因此對(duì)內(nèi)存的消耗是非常大的，往往會(huì)觸發(fā)查詢(xún)限流。
  • 在測(cè)試的過(guò)程中，查詢(xún)時(shí)間跨度為 1 小時(shí)，需要等待 30 秒后才能返回結(jié)果。

• 當(dāng)使用數(shù)據(jù)投遞時(shí)：

  • 被查詢(xún)的實(shí)例僅有一個(gè)，并且該實(shí)例存儲(chǔ)的數(shù)據(jù)經(jīng)過(guò)前置篩選，是我們所關(guān)心的需要聚合的相關(guān)數(shù)據(jù)。假設(shè)我們要在杭州地區(qū)查詢(xún)?nèi)蛏习賯€(gè)實(shí)例的數(shù)據(jù)，此時(shí)底層相當(dāng)于只查詢(xún)當(dāng)前杭州地區(qū)的某個(gè)實(shí)例，效率很高。
  • 在測(cè)試的過(guò)程中，查詢(xún)時(shí)間跨度為 1 小時(shí)，只需等待 1 秒就能返回結(jié)果。

總的來(lái)說(shuō)，當(dāng)我們選擇多實(shí)例數(shù)據(jù)統(tǒng)一管理的方案時(shí)，除了考慮是否需要額外的存儲(chǔ)空間，針對(duì)業(yè)務(wù)場(chǎng)景來(lái)說(shuō)查詢(xún)成功率是更重要的參考指標(biāo)。

在“A 運(yùn)維平臺(tái)”的場(chǎng)景下，因?yàn)樯婕暗搅丝绱笾?、海量?shí)例、海量數(shù)據(jù)，因此查詢(xún)時(shí)再進(jìn)行指標(biāo)聚合容易產(chǎn)生網(wǎng)絡(luò)請(qǐng)求超時(shí)、數(shù)據(jù)庫(kù)查詢(xún)限流、數(shù)據(jù)庫(kù)內(nèi)存消耗過(guò)大等問(wèn)題，使得查詢(xún)成功率降低。

而使用存儲(chǔ)時(shí)指標(biāo)聚合的數(shù)據(jù)投遞方案，將數(shù)據(jù)提前存儲(chǔ)至中心化實(shí)例，把查詢(xún)的網(wǎng)絡(luò)傳輸轉(zhuǎn)化為寫(xiě)數(shù)據(jù)的網(wǎng)絡(luò)傳輸，把全球多實(shí)例的查詢(xún)請(qǐng)求轉(zhuǎn)換為當(dāng)前地區(qū)實(shí)例的查詢(xún)，查詢(xún)成功率高并且滿(mǎn)足業(yè)務(wù)場(chǎng)景。

5.2.2.?方案架構(gòu)

如圖為 Prometheus 數(shù)據(jù)投遞-Remote Write 的產(chǎn)品形態(tài)。數(shù)據(jù)投遞服務(wù)由兩個(gè)組件組成，一是 Prometheus 投遞組件，該組件負(fù)責(zé)從源頭 Prometheus 實(shí)例獲取數(shù)據(jù)，經(jīng)過(guò)指標(biāo)過(guò)濾、格式化后發(fā)送給公網(wǎng)轉(zhuǎn)發(fā)服務(wù)組件。公網(wǎng)轉(zhuǎn)發(fā)服務(wù)組件負(fù)責(zé)將數(shù)據(jù)路由，通過(guò)公網(wǎng)的方式把數(shù)據(jù)發(fā)送至杭州的中心化實(shí)例。

在未來(lái)的計(jì)劃中，我們將使用事件總線(xiàn) EventBridge 替換現(xiàn)有公網(wǎng)轉(zhuǎn)發(fā)服務(wù)組件，以支持更多的投遞目標(biāo)生態(tài)。

5.3.?效果

通過(guò) Prometheus 數(shù)據(jù)投遞-Remote Write 功能，將“A 運(yùn)維平臺(tái)”全球多個(gè)區(qū)域的上百個(gè)實(shí)例的數(shù)據(jù)投遞至杭州的一個(gè)中心化實(shí)例中，配置了 Grafana 的單一數(shù)據(jù)源，配置大盤(pán)后即可對(duì)“A 運(yùn)維平臺(tái)”管理的所有集群進(jìn)行可視化監(jiān)控。杜絕了之前的每個(gè)集群一個(gè)數(shù)據(jù)源的配置方式，大大方便了運(yùn)維的操作。

廣告時(shí)間

6.1.?阿里云可觀(guān)測(cè)監(jiān)控?Prometheus?版?VS?開(kāi)源?Prometheus

阿里云可觀(guān)測(cè)監(jiān)控 Prometheus 版全面對(duì)接開(kāi)源 Prometheus 生態(tài)，支持類(lèi)型豐富的組件監(jiān)控，覆蓋絕大部分開(kāi)源基礎(chǔ)設(shè)施軟件指標(biāo)采集能力。提供多種開(kāi)箱即用的預(yù)置監(jiān)控大盤(pán)，并集成豐富的 Kubernetes 基礎(chǔ)監(jiān)控以及常用服務(wù)預(yù)設(shè)看板，且提供全面托管的 Prometheus 服務(wù)。阿里云可觀(guān)測(cè)監(jiān)控 Prometheus 版的優(yōu)勢(shì)可以歸納為“開(kāi)箱即用”、“低成本”、“開(kāi)源兼容”、“數(shù)據(jù)規(guī)模無(wú)上限”、“高性能”、“高可用性”。

6.2.?產(chǎn)品計(jì)費(fèi)

目前，可觀(guān)測(cè)監(jiān)控 Prometheus 版已開(kāi)啟全新按數(shù)據(jù)寫(xiě)入量計(jì)費(fèi)模式，并每月提供 50GB 免費(fèi)額度。每日上報(bào) 1000?萬(wàn)指標(biāo)，指標(biāo)數(shù)據(jù)存儲(chǔ) 90?天，僅需 37 元。

相關(guān)鏈接：

[1]?Remote?Write 和 Remote?Read 地址使用說(shuō)明

https://help.aliyun.com/zh/prometheus/user-guide/use-remote-read-endpoints-and-remote-write-endpoints

[2]?查看 RAM 用戶(hù)的 AccessKey 信息

https://help.aliyun.com/zh/ram/user-guide/view-the-accesskey-pairs-of-a-ram-user

[3]?官方文檔

https://prometheus.io/docs/concepts/remote_write_spec/

[4]?promlabs

https://promlabs.com/blog/2022/10/05/whats-new-in-prometheus-2-39/

參考文檔：

[1] https://thanos.io/

[2] https://yunlzheng.gitbook.io/Prometheus-book/part-ii-Prometheus-jin-jie/readmd/Prometheus-remote-storage

[3] https://www.squadcast.com/blog/how-to-implement-global-view-and-high-availability-for-Prometheus

[4] https://help.aliyun.com/zh/arms/Prometheus-monitoring/posting-Prometheus-data-to-other-Prometheus-instances

[5] https://help.aliyun.com/zh/arms/Prometheus-monitoring/create-a-global-aggregation-instance