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

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

Prometheus 作為云原生時代崛起的標志性專案，已經成為可觀測領域的事實標準，Prometheus 是單實體不可擴展的，那么如果用戶需要采集更多的資料并且保存更長時間該選擇怎樣的長期存盤方案呢？

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

Prometheus 簡介及其局限性

云原生時代崛起的 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，社區給出了多種方案，

在 Prometheus 長期存盤出現之前，用戶若需要跨集群聚合計算資料時，社區提供 Federation 方式實作，

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

Promretheus 長期存盤方案的崛起

2017 年，Prometheus 加? Remote Read/Write API，自此之后社區涌現出大量長期存盤的方案，如 Thanos、Grafana Cortex/Mimir、VictoriaMetrics、Wavefront、Splunk、Sysdig、SignalFx、InfluxDB、Graphite 等，

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

M3

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 等，

VictoriaMetrics 主要由三個組件構成：接入資料的 vminsert、存盤資料的 vmstorage 以及查詢資料的 vmselect，

vminsert 和 vmselect 都是無狀態的，可以通過增加副本的方式進行擴展，

vmstorage 雖然是有狀態的，但也可以擴展，當資料量超過一個副本的存盤量時，可以通過增加另外一個副本對其進行擴展，

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

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

VictoriaMetrics 還有一個單獨的用于告警的組件——VictoriaMetrics Alert，它具備兩個功能：

• 通過查詢 vmselect 決定是否需要告警，如果需要就將告警發到 alertmanager 中；
• 通過查詢 vmselect 計算 Recording Rule，并把計算結果通過 vminsert 寫入存盤，

另一個組件是 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 模式

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 模式

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 的版本，

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

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 下開源，

由于 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 做了多租戶和水平擴展的支持，

Prometheus 長期存盤方案對比

我們可以基于多維度對上述介紹的 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 發布！

標籤：其他

上一篇：NebulaGraph 的云產品交付實踐

下一篇：為什么Kubernetes和容器與機器學習密不可分？