一文讀懂 Prometheus 長期儲存主流方案

語言: CN / TW / HK

嘉賓 | 霍秉傑 整理 | 西京刀客 出品 | CSDN 雲原生

Prometheus 作為雲原生時代崛起的標誌性專案,已經成為可觀測領域的事實標準。Prometheus 是單例項不可擴充套件的,那麼如果使用者需要採集更多的資料並且儲存更長時間該選擇怎樣的長期儲存方案呢?

2022 年 8 月 9 日,在 CSDN 雲原生系列線上峰會第 15 期“Prometheus 峰會”上,青雲科技可觀測與函式計算負責⼈霍秉傑分享了《Prometheus Long-Term Storage:海納百川,有容乃大》。

Prometheus 簡介及其侷限性

file

雲原生時代崛起的 Prometheus 已經在可觀測領域得到了廣泛應用,其影響力遠遠超出了雲原生的範疇,具有兩個顯著特點。

單例項,不可擴充套件

Prometheus 的作者及社群核心開發者都秉承一個理念:Prometheus 只聚焦核心的功能,擴充套件性的功能留給社群解決,所以 Prometheus 自誕生至今都是單例項不可擴充套件的。

這對於很多從大資料時代走過來的工程師而言有點不可思議,大資料領域的很多開源專案比如 Elasticsearch、HBase、Cassandra 等無一不是多節點多角色的設計。

Prometheus 的核心開發者曾這樣解釋,Prometheus 結合 Go 語言的特性和優勢,使得 Prometheus 能夠以更小的代價抓取並存儲更多資料,而 Elasticsearch 或 Cassandra 等 Java 實現的大資料專案處理同樣的資料量會消耗更多的資源。也就是說,單例項、不可擴充套件的 Prometheus 已強大到可以滿足大部分使用者的需求。

Pull 模式抓取資料

Prometheus 倡導用 Pull 模式獲取資料,即 Prometheus 主動地去資料來源拉取資料。對於不便於 Pull 的資料來源,Prometheus 提供了 PushGateway 進行處理,但 PushGateway 在部分應用場景上存在限制。

儘管單例項的 Prometheus 已經足夠強大,但還是存在部分需求是其無法滿足的,如跨叢集聚合、更長時間的儲存等。為了擴充套件 Prometheus,社群給出了多種方案。

file

在 Prometheus 長期儲存出現之前,使用者若需要跨叢集聚合計算資料時,社群提供 Federation 方式實現。

在多個 Prometheus 例項的上一層有一個 Global Prometheus,它負責在各個例項中抓取資料並進行計算,以此解決跨叢集聚合計算的問題。但如果各個叢集的資料量較大,單例項的 GlobalPrometheus 也會遇到瓶頸。

Promretheus 長期儲存方案的崛起

file

2017 年,Prometheus 加⼊ Remote Read/Write API,自此之後社群湧現出大量長期儲存的方案,如 Thanos、Grafana Cortex/Mimir、VictoriaMetrics、Wavefront、Splunk、Sysdig、SignalFx、InfluxDB、Graphite 等。

接下來我們將挑選幾個主流的 Prometheus 長期儲存方案進行對比分析。

M3

file

M3 是 Uber 開源的一個 Prometheus 長期儲存的方案,它的元件主要包括 M3 Coordinate、M3 Queries、M3 Aggregator 及 M3DB。

M3 的工作原理是 Prometheus 將資料通過 M3 Coordinate Remote 寫入至 M3DB 中,M3 Queries 可直接對接 M3DB 進行查詢。M3Aggregator 對接收資料進行實時聚合,降取樣後存入 M3DB。

M3 是 Uber 為了滿足自身海量資料需求所開發的 Prometheus 長期儲存的方案,其缺點是部署麻煩,且社群也不活躍、文件欠佳。

VictoriaMetrics

VictoriaMetrics 是一個開源的 Prometheus 長期儲存專案,除開源專案外,還有商業化的產品和服務。VictoriaMetrics 的採用者包括知乎、Grammarly、fly.io、CERN 等。

file

VictoriaMetrics 主要由三個元件構成:接入資料的 vminsert、儲存資料的 vmstorage 以及查詢資料的 vmselect。

vminsert 和 vmselect 都是無狀態的,可以通過增加副本的方式進行擴充套件。

vmstorage 雖然是有狀態的,但也可以擴充套件,當資料量超過一個副本的儲存量時,可以通過增加另外一個副本對其進行擴充套件。

file

VictoriaMetrics 的 Agent 功能較為強大,主要體現在以下幾方面:

  • 可以代替 Prometheus 抓取資料,還可以接收 Prometheus 之外的資料來源 Push 過來的資料,如 Graphite、InfluxDB、OpenTSDB 等;
  • 可以把抓取的資料 Remote Write 到多個 Long-Term Storage;
  • 可以將數量眾多的抓取目標在 vmagent 例項之間進行分配。

file

VictoriaMetrics 還有一個單獨的用於告警的元件——VictoriaMetrics Alert,它具備兩個功能:

  • 通過查詢 vmselect 決定是否需要告警,如果需要就將告警發到 alertmanager 中;
  • 通過查詢 vmselect 計算 Recording Rule,並把計算結果通過 vminsert 寫入儲存。

file

另一個元件是 VictoriaMetrics Gateway,它主要有兩個功能:

  • 限速,在租戶讀寫時,會將部分資料寫入至另外一個 VictoriaMetrics 的例項中來記錄用量,超量的時候會做出一定的限制;
  • 訪問控制,訪問控制指在讀或者寫之前,必須先得獲取一個 Token。

VictoriaMetrics 還有其他的元件比如 vmauth、vmbackup/vmrestore、vmbackupmanager、vmanomaly 等。

值得一提的是,VictoriaMetrics 並不是所有功能都是開源的,未開源的企業版功能包括:

  • Downsampling 降取樣;
  • vmgateway 的 SSO、LDAP、JWT Token Authentication&Access Control;
  • 租戶級別的讀寫限速;
  • vmagent 讀寫 Kafka;
  • 多租戶告警與統計;
  • BackupManager;
  • 基於機器學習的異常監測 vmanomaly。

Thanos

Thanos 由 Improbable 開源,是社群最先出現的 Prometheus 長期儲存方案,採用者包括 Adobe、位元組、eBay、騰訊等。

Thanos 在架構上較為創新,具有諸多較為獨特的功能:

  • 能夠提供 Prometheus 例項的全域性查詢檢視,可以跨越多個 Prometheus 例項對資料進行查詢和聚合;
  • 可以把資料通過 Sidecar 上傳至物件儲存以便長時間儲存;
  • 提供壓縮與降取樣功能,通過壓縮可以減小物件儲存上儲存的 Block 的大小,通過降取樣可以加快長時間範圍資料的查詢與聚合速度。

Thanos 有兩種模式,Sidecar 模式和 Receive 模式。

Thanos Sidecar 模式

file

ThanosSidecar 模式是 Thanos 最早支援的模式,其原理是:

  • 每個 Prometheus Pod 中都有一個 Sidecar,這個 Sidecar 通過 Store API 與外界互動;
  • Thanos Query 通過 Store API 與 Thanos Sidecar 互動,經由 Thanos Sidecar 查詢到各 Prometheus 例項上的資料後進行聚合,去重後提供給使用者一個跨多個 Prometheus 例項的全域性檢視;
  • Thanos Sidecar 中的 Shipper 會把本地 Prometheus 例項落盤的 Block 上傳到物件儲存,之後由 Thanos Compact 對上傳到物件儲存的 Block 進行壓縮、降取樣和過期刪除;
  • 儲存在物件儲存裡的 Block 可由 Store Gateway 通過 Store API 向 Thanos Query 提供查詢服務,Store Gateway 會快取物件儲存裡 Block 的 index 以加快查詢速度;
  • 此外,Thanos Query 前面還有 Thanos Query Frontend 用於快取查詢結果以加快查詢速度;
  • Thanos Ruler 用於通過查詢 Thanos Query 計算 Recording 或 Alerting Rules。

Thanos Receive 模式

file

Thanos Receive 模式是 Thanos 響應社群使用者 Remote Write 的需求新增的模式,其原理是:

  • Prometheus 或 Prometheus Agent 通過 Remote Write 將監控資料傳送到 Thanos Receive Router;
  • Thanos Receive Router 根據租戶資訊將資料傳送給響應的 Thanos Receive Ingestor,其中 Router 是無狀態的,Ingestor 是有狀態的;
  • Thanos Receive Ingestor 相當於在一個沒有資料抓取能力和告警能力的 Prometheus 之上增加了 Store API 的支援用於和 Thanos Query/Thanos Ruler 互動,增加了 Shipper 元件將落盤 Block 上傳物件儲存;
  • Thanos Query 可以統一查詢 Thanos Ingestor、Thanos Store Gateway;
  • 其他元件作用和 Thanos Sidecar 模式類似。

Cortex

Cortex 由 Grafana 開源,Loki、Tempo、Grafana Cloud 等產品或專案都採用了 Cortex 的技術。採用者包括 AWS、Digital Ocean、Grafana Labs、MayaData、Weaveworks 等。

Cortex 最初是基於 Chunk Storage 的版本,因部署運維起來較為複雜且依賴 Cassandra 或 DynamoDB 儲存元資料,已經確定被棄用,改為基於 Block Storage 的版本。

file

受 Thanos 的啟發,Cortex 新架構採用 Block Storage。我們可以看到,Cortex 新架構的 distributor、ingester、querier、ruler、store-gateway、compactor 都與 Thanos 類似,其中 ruler、store-gateway、compactor 都借鑑自 Thanos。

file

Grafana Mimir

Grafana Mimir 是 Grafana Lab 於 2022 年 3 月底以 AGPL v3 協議新發布的開源專案。

從 Mimir 釋出的 Blog Announcing Grafana Mimir 可以看出,Grafana Mimir 在 Fork 了 Cortex 專案之後增加了許多企業級功能,被用於 Grafana Cloud 及服務 Grafana 的企業客戶的產品 Grafana Enterprise Metrics(GEM)。這麼做的主要原因是 Grafana Lab 認為 Cortex 被一些 ISV 或雲廠商用於給自己的客戶提供服務,卻沒有像 Grafana Lab 一樣貢獻程式碼,於是將越來越多的功能放到了 Cortex 的 Fork Mimir 中。

作為 Cortex 的增強版,之前很長一段時間 Mimir 是未開源的狀態,但這與 Grafana Lab 的開源文化相悖,於是為了兼顧開源和自己的商業利益,Grafana Lab 將 Mimir 在 AGPL v3 下開源。

file

由於 Grafana Mimir Fork 了 Cortex,所以其架構和 Cortex 及 Thanos 非常相似。

雖然 Grafana Mimir 同樣借鑑了 Thanos 的 store-gateway、compactor 和 ruler,但與 Cortex 不同之處在於 querier 和 query frontend 之間加了一個額外的元件 query scheduler,更好地滿足了查詢元件的可擴充套件性。

Mimir 各元件(包括 compactor、store-gateway、query、ruler 等)的水平可擴充套件性較好,值得一提的是 Mimir 對 Alertmanage 做了多租戶和水平擴充套件的支援。

file file

Prometheus 長期儲存方案對比

file

我們可以基於多維度對上述介紹的 Prometheus 長期儲存方案進行橫向對比:

  • Thanos 和 Cortex 已捐給 CNCF 基金會並處於孵化階段,有著更好的中立性,而 Mimir 的 AGPL v3 許可證不夠友好;
  • 從一些開源專案的指標看,Thanos 更受歡迎,其採用者也比較多;
  • Mimir 是 Grafana Lab 商業產品的開源版本,具有更好的水平可擴充套件性;
  • Mimir 與 VictoriaMetrics 有著更好的文件;
  • 在涉及多租戶、許可權控制、接入資料來源的多樣性等企業級功能方面,Mimir 和 VictoriaMetrics 更優;
  • M3 在各個維度上都不佔優。

總結

綜上,我們可以得出以下結論。

  • 資料持久化到硬碟的方案裡,VictoriaMetrics 是更好的選擇,但需要注意的是 VictoriaMetrics 並沒有開源 Downsampling 降取樣功能,如需跨較長時間範圍進行聚合及查詢,耗時會比較久。
  • 資料持久化到物件儲存的方案中,Thanos 更受歡迎,Grafana Mimir 更有潛力。
  • Thanos 可以不使用物件儲存,用本地盤存資料(Cortex/Mimir 待驗證)。
  • Grafana Fork 了 Cortex,建立了 Mimir 並修改 License 為 AGPL-3.0。後續 Grafana 及社群的投⼊程度成疑,不建議繼續採用 Cortex。
  • Thanos/Cortex/Mimir 互相借鑑,架構類似。Cortex/Mimir 借鑑了 Thanos 的物件儲存訪問及持久化。Thanos 借鑑了 Cortex 的 QueryFrontend。Mimir 作為 Grafana Cloud 的開源版本,其基於 Thanos 和 Cortex 的架構做了更多的優化。
  • 總體來說,在不介意許可證的情況下,可以採⽤ Mimir,若在意更寬鬆許可證,CNCF 孵化專案的 Thanos 是更好的選擇。
  • 沒有物件儲存,推薦使用 VictoriaMetrics(有些重要功能沒開源),有物件儲存儘量用 Thanos 或 Mimir。
  • 沒有特殊原因儘量不要採用 M3。

本文由部落格一文多發平臺 OpenWrite 釋出!