All in One：Prometheus 多實例數據統一管理最佳實踐

作者：淡唯（啃唯）、陽其凱（逸陵）

引言

Prometheus 作爲目前最主流的可觀測開源項目之一，已經成爲雲原生監控的事實標準，被衆多企業廣泛應用。在使用 Prometheus 的時候，我們經常會遇到全局視圖的需求，但是數據確分散在不同的 Prometheus 實例中，遇到這種情況該怎麼解決呢？本文列舉了社區一般解決方案，同時給出了阿里雲的全局視圖解決方案，最後給出了某客戶基於阿里雲 Prometheus 的實踐案例，希望能給您帶來啓發與幫助。

背景

在使用阿里雲 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 實例等，甚至數據來源不是同一個地區，因此保持實例級別的隔離是有必要的。

社區解決方案

所以，針對多 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"

阿里雲解決方案

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 數據可以同時存儲在不同的實例中：

在被聚合的 Prometheus 實例中，存儲着該實例所有的原始數據，包括期望被聚合查詢的實例以及其他數據。用於原業務場景中單實例的查詢。
在中央/聚合 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 使用

在左側導航欄，選擇 Prometheus 監控 > 數據投遞（beta） ，進入可觀測監控 Prometheus 版的數據投遞頁面。

在數據投遞頁面的頂部菜單欄，選擇地域，然後單擊新建任務。
在對話框中輸入任務名稱和任務描述後，單擊確定。
在任務編輯頁面，配置數據源和投遞目標。

配置 Prometheus Remote Write 地址以及認證方式。

配置網絡。

4.3. 阿里雲解決方案總結與選擇

阿里雲提供了全局聚合實例以及數據投遞-Remote Write解決方案各有優劣。

Prometheus 全局聚合實例的設計理念是在保持 Prometheus 實例的存儲獨立性的同時，提供一個統一的接口對多個實例進行查詢來實現全局視圖。該方案的核心理念爲“查詢時指標聚合”，也就是說數據原封不動地存儲在多個實例中，當統一查詢時纔將多個實例的數據獲取並聚合。這種方法有其明顯的優點，如節省存儲空間，但也存在一些挑戰，對於實例數量較多、數據量大的場景查詢性能會受較大影響。

Prometheus 數據投遞-Remote Write 的設計理念是將查詢的流量轉化爲數據寫入的流量，它消耗了額外的存儲空間提供多實例聚合數據的方案，它通過在寫入之前篩選數據，使得中心實例精簡地存儲着聚合數據。該方案的核心理念爲“存儲時指標聚合”，此時多個實例的數據副本將存儲在統一中心化實例中，對多個實例的查詢將轉化爲單實例查詢，大大提升了查詢速率與數據質量。

案例分析

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 運維平臺”管理的所有集羣進行可視化監控。杜絕了之前的每個集羣一個數據源的配置方式，大大方便了運維的操作。

廣告時間

6.1. 阿里雲可觀測監控 Prometheus 版 VS 開源 Prometheus

阿里雲可觀測監控 Prometheus 版全面對接開源 Prometheus 生態，支持類型豐富的組件監控，覆蓋絕大部分開源基礎設施軟件指標採集能力。提供多種開箱即用的預置監控大盤，並集成豐富的 Kubernetes 基礎監控以及常用服務預設看板，且提供全面託管的 Prometheus 服務。阿里雲可觀測監控 Prometheus 版的優勢可以歸納爲“開箱即用”、“低成本”、“開源兼容”、“數據規模無上限”、“高性能”、“高可用性”。