為什麼 Prometheus 需要長期儲存#

Prometheus 本身是一個優秀的短期指標引擎，但它的本地儲存有三個根本限制：

• 容量天花板：本地磁碟終究有上限，保留數週到數月的資料就會面臨空間壓力
• 持久性風險：Prometheus 實例掛掉或重建時，本地資料可能隨之消失
• 跨實例查詢困難：當你有多個 Prometheus 實例分別監控不同服務，想要做跨叢集的全局查詢幾乎不可能

這三個限制在小規模環境中不明顯，但當組織規模成長——多團隊、多叢集、多區域——它們會同時爆發。你需要回答「過去半年的 P99 延遲趨勢」這類問題時，才會發現 Prometheus 單機模式完全不夠用。

長期儲存不是「有了比較好」，而是在多 Prometheus 實例的環境中，它是讓指標資料真正發揮價值的必要基礎設施。

三大方案的設計哲學#

社群發展出三個主流的長期儲存方案，它們的核心差異在於如何與既有 Prometheus 整合。

Thanos：在旁邊加一層#

Thanos 採用 Sidecar 模式，設計哲學是「不改變你現有的 Prometheus，只在旁邊加元件」。

• Thanos Sidecar 部署在每個 Prometheus 實例旁邊，讀取本地 TSDB 區塊並上傳到物件儲存（S3、GCS、Azure Blob）
• Thanos Query 扮演統一查詢層，能夠同時查詢多個 Prometheus 實例和物件儲存中的歷史資料
• Thanos Compactor 負責對物件儲存中的資料做降採樣（Downsampling）和壓縮，降低長期查詢的成本
• Thanos Store Gateway 將物件儲存中的資料暴露為可查詢的介面

這種設計的最大優勢是無侵入性：你的 Prometheus 完全不需要改設定，Sidecar 只是「旁觀者」。

Cortex：推送到分散式後端#

Cortex 採用 Remote Write 模式，設計哲學是「讓 Prometheus 主動把資料推出來」。

• Prometheus 透過 Remote Write API 將指標即時推送到 Cortex 叢集
• Cortex 內部是完全分散式架構，包含 Distributor（接收）、Ingester（暫存寫入）、Querier（查詢）等多個微服務元件
• 資料最終也是存到物件儲存，但中間經過一層分散式的寫入與索引流程
• 原生支援多租戶（Multi-tenancy），不同團隊的資料在邏輯上完全隔離

這種設計讓 Prometheus 本身變成單純的「收集器」，儲存與查詢完全交給後端處理。

Mimir：下一代的效能躍進#

Mimir 是 Grafana Labs 從 Cortex fork 出來的專案，定位是下一代的分散式指標儲存。

• 繼承 Cortex 的 Remote Write 架構和多租戶能力
• 大幅簡化部署：減少元件數量，降低營運複雜度
• 效能優化：查詢速度和寫入吞吐量相較 Cortex 有顯著提升
• 與 Grafana 生態系（Grafana、Loki、Tempo）的整合更加緊密
• 提供更友善的預設配置，降低入門門檻

Mimir 和 Cortex 的關係類似於 Prometheus 和 Borgmon 的關係——後者吸取了前者的經驗，重新設計了架構。Grafana Labs 已將主要開發資源從 Cortex 轉移到 Mimir。

設計哲學比較#

三個方案的根本差異可以從一個問題看出來：Prometheus 在架構中扮演什麼角色？

高可用性與 Hash Ring#

在 Cortex 和 Mimir 的分散式架構中，Hash Ring 是實現高可用性的核心機制。

為什麼需要 Hash Ring#

當多個 Ingester 實例同時運行時，系統需要一個方式來決定「哪筆指標由哪個 Ingester 負責」。Hash Ring 就是這個分配機制：

• 每個 Ingester 在 Ring 上佔據一段範圍
• 進來的指標根據 Label 組合做 Hash，落在哪個範圍就由哪個 Ingester 處理
• 當某個 Ingester 故障，它的範圍會自動轉移給相鄰節點
• 新增 Ingester 時，會自動分擔一部分範圍

這個機制讓系統具備水平擴展和自動容錯的能力，不需要手動介入來重新分配負載。

Hash Ring 的概念並非 Cortex/Mimir 獨創，它本質上就是分散式系統中經典的 Consistent Hashing。如果你熟悉 Cassandra 或 DynamoDB 的分區機制，概念是相同的。

Thanos 的高可用策略#

Thanos 的高可用思路不同——它不需要 Hash Ring，因為它依賴的是每個 Prometheus 實例自身的資料。高可用性透過：

• 部署多個相同配置的 Prometheus 實例（各自獨立抓取）
• Thanos Query 在查詢時自動去重（Deduplication），合併來自不同副本的資料
• 物件儲存本身提供的持久性保證

選擇建議#

已有多個 Prometheus，想統一查詢 → Thanos#

如果你的環境中已經有運行良好的 Prometheus 實例，不想大幅改動既有架構，Thanos 是阻力最小的選擇。Sidecar 模式讓你可以逐步導入，不需要一次全部切換。

從零開始建新系統 → Mimir#

如果你正在規劃全新的監控平台，沒有歷史包袱，Mimir 提供最佳的效能和最簡化的營運體驗。尤其如果你已經在使用 Grafana 生態系，Mimir 的整合會非常順暢。

已在使用 Cortex → 評估遷移到 Mimir#

Cortex 仍然是穩定的方案，但社群的活躍度已逐漸轉移到 Mimir。如果營運負擔允許，遷移到 Mimir 可以獲得更好的效能和更持續的社群支援。

不要因為「看起來比較新」就選 Mimir，也不要因為「架構比較簡單」就選 Thanos。最關鍵的考量是你現在有什麼——既有的 Prometheus 部署方式和團隊的營運能力，才是決定選擇的真正因素。