01 引言
Prometheus 作為目前最主流的可觀測開源專案之一，已經成為雲原生監控的事實標準，被眾多企業廣泛應用。在使用 Prometheus 的時候，我們經常會遇到全域性檢視的需求，但是資料確分散在不同的 Prometheus 例項中，遇到這種情況該怎麼解決呢？本文列舉了社群一般解決方案，同時給出了阿里雲的全域性檢視解決方案，最後給出了某客戶基於阿里雲 Prometheus 的實踐案例，希望能給您帶來啟發與幫助。
02 背景
在使用阿里雲 Promtheus 時，由於地域的限制、業務原因或者其他原因，經常會遇到 Prometheus 多例項的場景。如下圖所示，某使用者在杭州區域有多個 Prometheus “通用”例項。在多例項的背景下，我們經常會遇到一些問題。
2.1. 問題 1-單一 Grafana 大盤資料來源
我們知道 Grafana 大盤是觀測 Prometheus 資料最常規、最普遍的方式。通常情況下，每觀測一個 Prometheus 叢集就需要建立一個資料來源，假設我有 100 個 Prometheus 叢集，就需要建立 100 個資料來源。聽著是個很麻煩的事情，如果你還能接受，那麼繼續往下看。
在編輯 Grafana panel 並填寫 PromQL 時我們可以選擇資料來源，但是為了保證資料查詢和展示的一致性與簡潔性，Grafana 僅允許一個 panel 使用一個資料來源。
如果我們需要在一個大盤內同時繪製多個資料來源的 panel，那麼使用以上 100 個資料來源時就會產生 100 個 panel，並且需要編輯 100 次 panel 並編寫 100 次 PromQL，非常不利於運維。理想狀態下應該是合併為一個 panel，並且每個資料來源一個時間線，不僅方便指標監控，更是大大減少大盤的維護動作。
2.2. 問題 2-例項間資料計算與查詢
當不同的業務使用了不同的 Prometheus 例項，但這些例項都有在上報著相同的指標，我們希望將這些資料做聚合（sum）、增長率（rate）等運算，由於存在著例項間的儲存隔離，這樣的操作是不允許的。同時我們並不希望把這些資料都上報到同一個例項中，因為根據業務場景，可能這些資料來自不同的 ACK 叢集、ECS、Flink 例項等，甚至資料來源不是同一個地區，因此保持例項級別的隔離是有必要的。
03 社群解決方案
所以，針對多 Prometheus 例項存在的上述問題，社群是如何解決的呢？
3.1. Federation 方案
Prometheus Federation 機制是 Promehteus 本身提供的一種叢集化的擴充套件能力,但是也可以用於解決資料的中心化查詢問題。當我們要監控的服務很多的時候，我們會部署很多的 Prometheus 節點分別 Pull 這些服務暴露的 Metrics，Federation 機制可以將這些分別部署的 Prometheus 節點所獲得的指標聚合起來，存放在一箇中心點的 Prometheus。如下圖所示為常見的 Federation 架構：
邊緣節點每一個 Prometheus 例項都會包含一個/federate 的介面，用於獲取一組指定的時間序列的監控資料，Global 節點只需要配置一個採集任務，用於從邊緣節點獲取監控資料即可。為了更好的理解 Federation 機制，下面給出了 Global Prometheus 的配置檔案的配置。
scrape_configs:
- job_name: 'federate'
scrape_interval: 10s
honor_labels: true
metrics_path: '/federate'
# 根據實際業務情況進行Pull metrics，透過match引數，配置要拉取的Metrics
params:
'match[]':
- '{job="Prometheus"}'
- '{job="node"}'
static_configs:
# 其他 Prometheus 節點
- targets:
- 'Prometheus-follower-1:9090'
- 'Prometheus-follower-2:9090'3.2. Thanos 方案
對於開源的 Prometheus 版本，我們可以使用 Thanos 實現聚合查詢，如下為 Thanos 的 Sidecar 部署模式：
這張圖中包含了 Thanos 的幾個核心元件（但並不包括所有元件）：
- Thanos Sidecar：連線 Prometheus，將其資料提供給 Thanos Query 查詢，並且將其上傳到物件儲存以供長期儲存。
- Thanos Query：實現了 Prometheus API，提供全域性查詢檢視將來 StoreAPI 提供的資料進行聚合最終返回給查詢資料的 client（如 Grafana）。
- Thanos Store Gateway：將物件儲存的資料暴露給 Thanos Query 去查詢。
- Thanos Compact：將物件儲存中的資料進行壓縮和降低取樣率，加速大時間區間監控資料查詢的速度。
- Thanos Ruler：對監控資料進行評估和告警，還可以計算出新的監控資料，將這些新資料提供給 Thanos Query 查詢並且/或者上傳到物件儲存，以供長期儲存。
- Thanos Receiver：從 Prometheus 的遠端寫入 WAL 接收資料，將其公開和/或上傳到雲端儲存。
那 Thanos 如何實現 global 查詢的呢？
Thanos Query 實現了 Prometheus 的 HTTP API，這樣查詢 Prometheus 監控資料的 client 就不直接查詢 Prometheus 本身了，而是去查詢 Thanos Query，Thanos Query 再去下游多個儲存了資料的地方查資料，最後將這些資料聚合去重後返回給 client，從而實現了 global 查詢。而為了實現 Thanos Query 去查下游分散的資料，Thanos 為此抽象了 Store API 的內部 gRPC 介面，其它一些元件透過這個介面來暴露資料給 Thanos Query。
在上述的架構中單個的 Prometheus 會將採集的資料存到本機磁碟上，每個 Prometheus 附帶部署一個 Sidecar，這個 Sidecar 實現 Thanos Store API，由於 Prometheus 本地磁碟有限，所以對於長時間週期的存在透過 Sidecar 的 Thanos Store API 會將資料儲存在物件儲存；無論對於單個 Prometheus 上的資料查詢還是物件儲存的查詢都是基於“Store API”，如下對查詢進行進一步的抽象。
3.3. Prometheus Remote Write 方案
Remote Write 也是解決 Prometheus 多例項全域性查詢的有效解決方案，其基本思想與 Prometheus Federation 機制非常類似，將分別部署的 Prometheus 節點所獲得的指標利用 Remote Write 機制存放在一箇中心點的 Prometheus 或者第三方儲存中。
使用者在 Prometheus 配置檔案中指定 Remote Write 的 URL 地址，一旦設定了該配置項，Prometheus 將採集到的樣本資料透過 HTTP 的形式傳送給介面卡 (Adaptor)，而使用者則可以在介面卡中對接外部任意的服務。外部服務可以是開源 Prometheus，也可以是真正的儲存系統，也可以是公有云的儲存服務。
如下為樣例，修改 Prometheus.yml 新增 Remote Storage 相關的配置內容。
remote_write:
- url: "http://*****:9090/api/v1/write"04 阿里雲解決方案
4.1. 阿里雲 Prometheus 全域性聚合例項解決方案
4.1.1. 阿里雲 Prometheus 全域性聚合例項方案介紹
阿里雲推出了“Prometheus 全域性聚合例項”，其目標是實現跨多個阿里雲 Prometheus 例項的資料聚合，在查詢資料時同時從多個例項中讀取資料，其原理為“查詢時指標聚合”。
使用阿里雲全域性聚合例項（以下簡稱 Gloabal View）可以保證單個阿里雲 Prometheus 例項間的資料隔離，即每個 Prometheus 例項後端擁有獨立的儲存，不是透過合併資料到一箇中央儲存，而是在查詢時動態地從各個例項的儲存中檢索需要的資料。這樣，當使用者或者前端應用程式發起查詢請求時，Global View 會並行地對所有相關 Prometheus 例項進行查詢，並將結果彙總，提供一個統一的檢視。
4.1.2. 對比分析
下面針對開源 Prometheus Federation 以及 Thanos 方案以及阿里雲全域性聚合例項方案進行簡單的彙總說明。
1）Prometheus Federation
雖然 Prometheus Federation 能解決全域性聚合查詢，但是還存在一些問題。
- 邊緣節點和 Global 節點依然是單點，需要自行決定是否每一層都要使用雙節點重複採集進行保活，也就是仍然會有單機瓶頸。
- 對歷史資料的儲存問題仍舊未得到解決，必須依賴第三方儲存，切缺少對歷史資料的降準取樣能力。
- 整體運維成本比較高。
- 可擴充套件性較差，新增或移除 Prometheus 例項需要修改配置檔案。
2）Thanos Federation
- 架構比較複雜，運維成本較高。
- 仍存在 Prometheus 副本的單點問題。
- 時間線發散的情況下，支援的上限不夠，不提供維度發散場景最佳化。
- 不支援降取樣，長週期查詢效能不高。
- 不支援運算元下推，大資料量的請求效能有限，並且處理開銷大。
3）阿里雲全域性聚合例項
- Prometheus 例項託管、免運維。
- 支援圖形化介面進行多例項的管理，靈活性強、可擴充套件性高。這種模式允許系統輕鬆地新增或移除阿里雲 Prometheus 例項，而不需要重新配置整個儲存系統。
- 不佔用額外的儲存空間。由於沒有將資料複製到集中的儲存中，這種方法可以節約儲存空間，每個 Prometheus 例項只需要維護自己的資料集。在不額外配置儲存的情況下，查詢到的資料僅是臨時用於展示，真正的資料持久化仍然歸於被聚合的例項。
- 隔離性：每個例項的自治效能夠提高系統的容錯性，因為單個例項的問題不會直接影響到其他例項。
- 支援跨 region 例項以及跨賬號例項聚合，滿足企業個性化的需求。
但是需要注意的是 Thanos Federation 與阿里雲全域性聚合例項都是非合併資料的方式實現全域性查詢。由於需要在查詢時從多個資料來源檢索資料，這可能會導致查詢效能下降，特別是當查詢涉及大量不需要的資料時，需要等待多個資料來源篩選出需要的資料，等待這些資料處理的過程可能導致查詢超時或長時間等待。
4.1.3. 阿里雲 Prometheus 全域性聚合例項實踐
阿里雲 Prometheus 極大簡化了使用者的操作，無需手動部署 Prometheus 擴充套件元件，使用者透過控制檯操作便可實現全域性檢視的功能。在建立 Prometheus 例項時選擇“全域性聚合例項”，勾選需要聚合的例項，並選擇查詢前端所在的地區（影響查詢域名的生成），點選“儲存”後即可。
進入建立好的全域性聚合例項，點選任意大盤，可以看到該例項已經能查詢到剛剛聚合的其他例項資料。實現了我們在 Grafana 一個資料來源查詢多個例項資料的需求。
4.2. 阿里雲 Prometheus Remote Write 解決方案
4.2.1. 阿里雲 Prometheus Remote Write 解決方案
阿里雲 Prometheus remote write 的能力是阿里雲 Prometheus 資料投遞的原子能力。Prometheus 資料投遞的原理為“儲存時的指標聚合”，其目標是將跨多個 Prometheus 例項的資料透過 ETL 服務提取出來，再寫入某個聚合例項的儲存中。
透過這種方式，相同的 Prometheus 資料可以同時儲存在不同的例項中：
1. 在被聚合的 Prometheus 例項中，儲存著該例項所有的原始資料，包括期望被聚合查詢的例項以及其他資料。用於原業務場景中單例項的查詢。
2. 在中央/聚合 Prometheus 中，儲存著其他“被聚合例項”的“期望被聚合的資料”，在統一管理的場景下，可以透過該例項獲取全域性檢視的查詢，執行跨例項資料的搜尋。
4.2.2. 阿里雲 Prometheus Remote Write VS 社群 Prometheus Remote Write
1）Prometheus Remote Write
開源 Remote Write 的形式最大的弊端在於對 Prometheus Agent 的影響，在 Agent 設定 Remote Write 會增加 Agent 的資源消耗，影響資料採集的效能，而這一點往往是致命的。
2）阿里雲 Prometheus Remote Write
阿里雲 Prometheus Remote Write 的優勢還是非常明顯的。
- 查詢效能高：因為只儲存了必要的聚合資料，聚合 Prometheus 例項的查詢響應時間更短，極大地提升了使用者體驗。此外，在查詢時本質上只是對一個 Prometheus 例項進行操作，而非多個例項，讀寫的效能、計算的效能更高。
- 資料質量高：經過篩選後的資料更加乾淨，沒有不必要的 "髒資料"，這有助於進行更加精準和有效的資料分析。
- 提供豐富的 ETL 能力: 在寫入聚合例項之前提供豐富的處理能力，如過濾篩選、指標富化等。
- 圖形化配置，操作簡單便捷。
同時當然也有一些劣勢，大家需要綜合權衡取捨。
- 費用問題：由於需要額外的 Prometheus 例項來作為聚合和全域性查詢的儲存點，這意味著需要額外的 TSDB 後端儲存需要被聚合的資料，這些獨立的儲存空間是需要計費的。
- 網路消耗：在資料投遞過程中，跨網路的資料傳輸會增加頻寬佔用，特別是在跨資料中心或寬頻有限的環境中，所以需要進行合理的評估。
4.2.3. 阿里雲 Prometheus Remote Write 使用
1. 在左側導航欄，選擇 Prometheus 監控 > 資料投遞（beta），進入可觀測監控 Prometheus 版的資料投遞頁面。
2. 在資料投遞頁面的頂部選單欄，選擇地域，然後單擊新建任務。
3. 在對話方塊中輸入任務名稱和任務描述後，單擊確定。4. 在任務編輯頁面，配置資料來源和投遞目標。
| 配置項 | 說明 | 示例 |
| Prometheus 例項 | 被投遞的 Prometheus 資料來源。 | c78cb8273c02***** |
| 資料過濾 | 根據白名單或黑名單模式填入需要過濾的指標，透過 Label 篩選投遞資料。支援正規表示式，多個條件換行，多個條件為且（&&）的關係。 | __name__=rpc.*job=apiserverinstance=192.* |
5. 配置 Prometheus Remote Write 地址以及認證方式。
| Prometheus 型別 | 地址獲取方式 | 要求 |
| 阿里雲 Prometheus | Remote Write 和 Remote Read 地址使用說明[1]當資料投遞源例項與目標例項處於同一地區時，請使用內網地址 | 認證方式選擇 B“A 運維平臺” c Auth，並輸入具備 AliyunARMSFullAccess 許可權的 RAM 使用者的 AK 和 SK。AK 和 SK 的獲取方式，請參見檢視 RAM 使用者的 AccessKey 資訊[2]使用者名稱：AccessKey ID，用於標識使用者。密碼：AccessKey Secret，用於驗證使用者的金鑰。AccessKey Secret 必須保密。 |
| 自建 Prometheus | 官方文件[3] | 1. 自建 Prometheus 的版本為 2.39 以上版本。2. 需配置 out_of_order_time_window。具體操作，請參見 promlabs[4]。 |
le data-draft-node="block" data-draft-type="table" data-size="normal" data-row-style="normal">
-
Prometheus 型別 地址獲取方式 要求 阿里雲 Prometheus Remote Write 和 Remote Read 地址使用說明[1]當資料投遞源例項與目標例項處於同一地區時，請使用內網地址 認證方式選擇 B“A 運維平臺” c Auth，並輸入具備 AliyunARMSFullAccess 許可權的 RAM 使用者的 AK 和 SK。AK 和 SK 的獲取方式，請參見檢視 RAM 使用者的 AccessKey 資訊[2]使用者名稱：AccessKey ID，用於標識使用者。密碼：AccessKey Secret，用於驗證使用者的金鑰。AccessKey Secret 必須保密。 自建 Prometheus 官方文件[3] 1. 自建 Prometheus 的版本為 2.39 以上版本。2. 需配置 out_of_order_time_window。具體操作，請參見 promlabs[4]。 -
Prometheus 型別 地址獲取方式 要求 阿里雲 Prometheus Remote Write 和 Remote Read 地址使用說明[1]當資料投遞源例項與目標例項處於同一地區時，請使用內網地址 認證方式選擇 B“A 運維平臺” c Auth，並輸入具備 AliyunARMSFullAccess 許可權的 RAM 使用者的 AK 和 SK。AK 和 SK 的獲取方式，請參見檢視 RAM 使用者的 AccessKey 資訊[2]使用者名稱：AccessKey ID，用於標識使用者。密碼：AccessKey Secret，用於驗證使用者的金鑰。AccessKey Secret 必須保密。 自建 Prometheus 官方文件[3] 1. 自建 Prometheus 的版本為 2.39 以上版本。2. 需配置 out_of_order_time_window。具體操作，請參見 promlabs[4]。
6. 配置網路。
| Prometheus 型別 | 網路模式 | 網路要求 |
| 阿里雲 Prometheus | 公網 | 無 |
| 自建 Prometheus | 公網 | 無 |
| 專有網路 | 請選擇自建 Prometheus 例項所在的 VPC，並確保您填寫的 Prometheus Remote Write 地址在該 VPC、交換機和安全組內可訪問。 |
4.3. 阿里雲解決方案總結與選擇
阿里雲提供了全域性聚合例項以及資料投遞-Remote Write解決方案各有優劣。
Prometheus 全域性聚合例項的設計理念是在保持 Prometheus 例項的儲存獨立性的同時，提供一個統一的介面對多個例項進行查詢來實現全域性檢視。該方案的核心理念為“查詢時指標聚合”，也就是說資料原封不動地儲存在多個例項中，當統一查詢時才將多個例項的資料獲取並聚合。這種方法有其明顯的優點，如節省儲存空間，但也存在一些挑戰，對於例項數量較多、資料量大的場景查詢效能會受較大影響。
Prometheus 資料投遞-Remote Write 的設計理念是將查詢的流量轉化為資料寫入的流量，它消耗了額外的儲存空間提供多例項聚合資料的方案，它透過在寫入之前篩選資料，使得中心例項精簡地儲存著聚合資料。該方案的核心理念為“儲存時指標聚合”，此時多個例項的資料副本將儲存在統一中心化例項中，對多個例項的查詢將轉化為單例項查詢，大大提升了查詢速率與資料質量。
| 方案 | 核心理念 | 儲存空間 | 查詢方式 |
| 全域性聚合例項 | 查詢時指標聚合 | 不額外消耗儲存空間 | 多例項查詢 |
| 資料投遞-Remote Write | 儲存時指標聚合 | 需要額外儲存聚合資料 | 單例項查詢 |
05 案例分析
5.1. 某客戶運維平臺可觀測現狀
5.1.1. 介紹
下圖所示為某客戶的內部運維平臺，這裡暫且稱為“A 運維平臺”，客戶公司利用 A 運維平臺進行公司內部 K8s 叢集的生命週期管理。在 A 運維平臺中，只能針對單個叢集進行相關監控資料的檢視，當有多個叢集有問題需要排查時，只能一個一個處理。
同樣的，在使用 Grafana 時，當前大盤只能檢視某個叢集的具體資料，無法對多個叢集同時監控。
此時 SRE 團隊無法對所有叢集狀態有全域性的視角，難以準確獲取該產品的健康狀態。在平時的運維工作中，大多依賴告警提示某個叢集處於非健康狀態。目前 A 運維平臺託管了上百個叢集，全部依賴告警會有訊息過多的風險，導致等級較高的故障無法快速定位。
5.1.2. 訴求
當前在“A 運維平臺”的運維管理面臨一個挑戰：缺少對所有地區叢集狀態的一目瞭然的全域性檢視。“A 運維平臺”的目標是配置單一的 Grafana 大盤，透過引入單一的資料來源，實現對個產品線整所有租戶叢集執行狀況的實時監控這應。包括關鍵指標的視覺化，例如叢集的整體狀態（包括叢集的數量、各節點和 Pod 的數量、全網叢集的 CPU 使用情況等），以及\APIServer 的 SLO（服務水平目標）狀態（諸如全網非 500 響應的動詞比例、50X 錯誤的詳細資訊、請求成功率等）。
透過這個精心設計的大盤，運維團隊可以迅速鎖定任何處於非健康狀態的叢集，快速概覽業務量，並對潛在問題進行快速調查，大幅提升運維效率和響應速度。這樣的整合不僅最佳化了監控流程，也為運維團隊提供了一個強大的工具，以確保系統的穩定性和服務的連續性。
5.1.3. 難點
跨大洲資料傳輸：“A 運維平臺”的場景涉及到全球所有區域，SRE 團隊在運維時希望能在杭州區域的大盤檢視全球所有區域的例項資料，這就涉及到了跨大洲的資料傳輸。當在 Grafana 進行跨大洲的例項查詢時，因為網路傳輸的延遲存在，經常性地出現查詢超時的問題。
請注意：當您使用 Promethues 配置資料跨境時。您同意並確認，您完全擁有該份業務資料的所有處置許可權，對資料傳輸的行為全權負責。您應確保您的資料傳輸符合所有適用法律，包括提供充分的資料安全保護技術和策略，履行獲得個人充分明示同意、完成資料出境安全評估和申報等法定義務，且你承諾您的業務資料不含任何所適用法律限制、禁止傳輸或披露的內容。如您未遵守前述宣告與保證，您將承擔對應的法律後果，導致阿里雲和或其他關聯公司遭受任何損失的，您應承擔賠償責任。
單例項資料量過大：並非所有的資料都需要全區域全例項聚合查詢，全球視角的運維一般只關心某幾個表示叢集狀態的指標；或是針對某些指標，只關心幾個特定的 label（namespace）。隨著被“A 運維平臺”託管的叢集增加、租戶增加，上報指標的 label 越來越多樣化，可能涉及到指標緯度發散的問題。目前針對指標緯度發散的問題業界仍沒有統一的解決方案，此時查詢會大量消耗 TSDB 的記憶體。在單 Prometheus 例項的場景下對這類發散指標查詢時就已經給 TSDB 例項很大的壓力，當一次性獲取“A 運維平臺”所有 Prometheus 例項資料時給伺服器的壓力過大。
超大空間跨度的查詢：需要對某幾個指標，把當前區域/全球的所有例項資料求和等計算。在問題 2 單例項資料量的基礎上，推廣至“A 運維平臺” 上百個 Prometheus 例項，此時所有例項涉及到的資料量更加龐大。當 TSDB 進行查詢、篩選、計算操作時，會佔用大量的記憶體，一般的計算資源配額無法滿足。
5.2. 透過資料投遞實現中心化資料查詢
5.2.1. 方案選型
是選擇全域性聚合例項還是資料投遞？在“A 運維平臺”的場景下，針對以上討論的需求以及難點，選擇資料投遞是更好的方案。有如下原因：
1）傳輸延遲容忍度
當使用資料投遞時，鏈路能承受更大的網路延遲。
- 當使用全域性聚合例項查詢時：
- 每次請求都會產生多個跨大洲的網路延遲。在測試過程中，跨大洲網路傳輸延遲在 500ms～700ms 間，在特殊時段、網路波動等情況下延遲甚至能達到 1min+，極易造成查詢超時。
- “A 運維平臺”例項部署在全球各個地區，當其中 99% 的資料都成功查詢，某個地區由於網路波動導致查詢超時，那麼其他 99% 成功查詢到的資料也就不可用了，對資料齊全度要求很高。
- 在查詢時客戶的 PromQL、時間跨度是不固定的，導致查詢的資料量是任意的。當查詢資料量過大，資料可能會分到多個 HTTP 包傳輸（受限於網路提供商），此時網路延遲很大。
- 當使用資料投遞時：
- 資料投遞的資料網路傳輸不會隨著使用者查詢量改變，而是將各 Prometheus 例項採集到的資料實時的投遞至中心化 Prometheus 例項中，此時資料包不超過 1MB 大小，網路延遲維持在固定的範圍。
- 聚合資料都儲存在中心化 Prometheus 例項中，因此只需保證對該例項的查詢不出錯即可，無需考慮查詢齊全度的問題。
- 即使經過了超大的跨大洲網路傳輸，我們仍然能透過攢批、重試等方式保證資料成功寫入了中心 Prometheus 例項。儘管中心例項中的最新資料與當前時間有分鐘級的延遲，查詢成功率有了保證。
2）節省計算資源
執行 PromQL 查詢時，指標的時間線數量決定了查詢所需的 CPU、記憶體資源。也就是說指標的 label 越多樣，所消耗的資源就越多。
- 當使用全域性聚合例項查詢時：
- 被聚合的例項儲存著所有的原始資料，查詢的資源消耗較大。由於 TSDB 的特性，即使進行了 label 的篩選，仍有可能將該時間段的全量資料載入到記憶體中。在“A 運維平臺”的場景中，由於每次查詢都涉及到海量資料，因此對記憶體的消耗是非常大的，往往會觸發查詢限流。
- 在測試的過程中，查詢時間跨度為 1 小時，需要等待 30 秒後才能返回結果。
- 當使用資料投遞時：
- 被查詢的例項僅有一個，並且該例項儲存的資料經過前置篩選，是我們所關心的需要聚合的相關資料。假設我們要在杭州地區查詢全球上百個例項的資料，此時底層相當於只查詢當前杭州地區的某個例項，效率很高。
- 在測試的過程中，查詢時間跨度為 1 小時，只需等待 1 秒就能返回結果。
總的來說，當我們選擇多例項資料統一管理的方案時，除了考慮是否需要額外的儲存空間，針對業務場景來說查詢成功率是更重要的參考指標。
在“A 運維平臺”的場景下，因為涉及到了跨大洲、海量例項、海量資料，因此查詢時再進行指標聚合容易產生網路請求超時、資料庫查詢限流、資料庫記憶體消耗過大等問題，使得查詢成功率降低。
而使用儲存時指標聚合的資料投遞方案，將資料提前儲存至中心化例項，把查詢的網路傳輸轉化為寫資料的網路傳輸，把全球多例項的查詢請求轉換為當前地區例項的查詢，查詢成功率高並且滿足業務場景。
5.2.2. 方案架構
如圖為 Prometheus 資料投遞-Remote Write 的產品形態。資料投遞服務由兩個元件組成，一是 Prometheus 投遞元件，該元件負責從源頭 Prometheus 例項獲取資料，經過指標過濾、格式化後傳送給公網轉發服務元件。公網轉發服務元件負責將資料路由，透過公網的方式把資料傳送至杭州的中心化例項。
在未來的計劃中，我們將使用事件匯流排 EventBridge 替換現有公網轉發服務元件，以支援更多的投遞目標生態。
5.3. 效果
透過 Prometheus 資料投遞-Remote Write 功能，將“A 運維平臺”全球多個區域的上百個例項的資料投遞至杭州的一箇中心化例項中，配置了 Grafana 的單一資料來源，配置大盤後即可對“A 運維平臺”管理的所有叢集進行視覺化監控。杜絕了之前的每個叢集一個資料來源的配置方式，大大方便了運維的操作。
相關連結：
[1] Remote Write 和 Remote Read 地址使用說明
https://help.aliyun.com/zh/prometheus/user-guide/use-remote-read-endpoints-and-remote-write-endpoints
[2] 檢視 RAM 使用者的 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
作者：淡唯（啃唯）、陽其凱（逸陵）
原文連結
本文為阿里雲原創內容，未經允許不得轉載。