在 Gartner 發布的《2023 年十大戰略技術趨勢》[1]報告中,「應用可觀測性」再次成為熱門趨勢。用戶需要建立可觀測體系來統籌、整合企業數字化所產生的指標數據，并以此為基礎進行反饋并制定決策，這對于提高組織決策有效性和及時性，將是最強有力的支撐。

新需求帶來新革命，Prometheus 產品應運而生，引領新一輪可觀測技術革命。得益于良好的產品設計，Prometheus 部署與輕度使用體驗非常流暢：敲兩三個命令就能運行起來，配置幾行 yaml 就能收集數據，編輯一個規則就能觸發告警，再配合上 Grafana，寫一句 PromQL 就能畫出趨勢圖表。一切簡單而美好，仿佛SRE光明的未來正向我們招手，這一切來的太突然，它真的如此輕易么？

當然不是。

Prometheus 用良好的用戶接口掩蓋了內部復雜實現。深入其中，我們會看到時序數據存儲、大規模數據采集、時間線高基數、數據攪動、長周期查詢、歷史數據歸檔等等。像潛藏在寧靜湖面下磨牙吮血的鱷魚，靜待不小心掉進坑中的 SRE 們。

客觀的講，這些問題早已存在，并不是 Prometheus 帶來的。云原生的到來讓這些問題變得更顯著且難以回避。想解決這些問題，需要投入大量人力、物力和精力。作為國內領先的云服務提供商，阿里云提供了優秀的可觀測全套解決方案，阿里云 Prometheus 服務正是其中重要一環，相比于開源版本 Prometheus，阿里云的 Prometheus 服務無論是易用性、擴展性、性能均有大幅度提升。今天，我們將結合企業日常運維過程中常見疑難場景，將兩者存儲能力進行對比。

測前概念解讀

在開始前，我們先闡述測試過程中涉及的問題與概念。

1.時間線（Time Series）

時間線的概念在Prometheus中非常重要，它表示一組不相同的label/value 的集合。比如temperature{city="BJ",country="CN"} 和 temperature{city="SH",country="CN"}就是兩條不同的時間線。

因為其中的city這個label對應的值不同；temperature{city="BJ",country="CN"}和 humidity{city="BJ",country="CN"} 也是兩條不相同的時間線，因為在Prometheus中，指標名稱也對應一個特殊的label __name__。時間線中的label會被索引以加速查詢，所以時間線越多存儲壓力越大。

2.時間線高基數（High Cardinality）

如果指標設計不合理，label 取值范圍寬泛，如 URL，訂單號，哈希值等，會造成寫入的時間線數量難以預估，會發生爆炸式增長，為采集、存儲帶來巨大挑戰。對于這種情況，我們稱之為時間線高基數或者時間線爆炸。時間線基數過高帶來的影響是全方位的，如采集壓力大，網絡和磁盤 IO 壓力大，存儲成本上升，查詢響應遲緩等。

高基數場景常見應對思路有兩種：依靠時序存儲本身的能力，或更優秀的架構來硬抗壓力；或使用預聚合/預計算等手段來主動降低基數。阿里云 Prometheus 在兩方面都進行了很多優化和增強，但開源版本中并沒有提供完整預聚合/預計算功能，所以此次測試中不會涉及到預聚合/預計算。

3.高攪動率（High Churn Rate）

高攪動率是高基數的特殊場景之一，如果時間線的“壽命”很短，經常被汰換，這種場景我們稱之為高攪動率。比如 k8s 場景下，deployment 每次創建新的 pod 時，都會產生新 pod name，即舊 pod 相關時間線被淘汰，新 pod 相關時間線被產生出來。如果經常性發生重啟（或類似場景），那么可能從某個時間點來看，時間線并不多，但在較長時間范圍來看，時間線總量可能就很龐大。換句話說，在高攪動率場景下，“活躍”的時間線不一定很多，但累積時間線總數非常龐大，所以對時間跨度較大的查詢影響尤其嚴重。

阿里云 Prometheus 服務與開源版本 Prometheus 能力對比↓

Prometheus 官方提供兼容性測試工具[2]，阿里云 Prometheus 服務在最主要的 PromQL 測試類別中，兼容性為 97.06%[3]且無需使用 tweak，綜合表現優于 AWS 和 GCP[4]。

測試場景

測試工具和測試數據計算

1.測試環境

本次測試使用的 Prometheus 版本為 2.40.1，即截至 2022-12-20 的最新開源版本。阿里云 Prometheus 服務和部署開源 Prometheus 使用的 ECS 均位于阿里云張家口 Region。

2.測試工具

我們使用 VictoriaMetrics 提供的?prometheus-benchmark[5]來執行此次測試，在使用過程中我們也發現了此工具存在不支持 query_range 測試，churn 邏輯錯誤等問題，所以我們進行了 Bug 修復和功能增強，為了保證測試透明及可參考性，項目存放在 GitHub 上[6]。測試工具的整體架構如下圖：

3.測試條件設置

默認使用 node exporter 作為指標數據源，node exporter 產生的時間線數量和物理機器有關，比如 CPU 相關指標和機器核數有關系，FileSystem 相關指標和實際掛載的文件系統數量有關，而運行 pod 較多的機器，掛載的文件系統也會更多。在施壓集群機器節點上，我們將單個 node exporter 實際產出的時間線數量控制在（680±5）之間，后續的測試估算中，我們按照 680 per node exporter 的標準來估算。

agent 通過定義多個 static config 抓取同一個 node exporter，同時將 instance 字段 relabel 成 host-idx 的方式，模擬出多個數據源，并寫入到 remote storage 中。config updater 組件定時更新 static config 按比率調整 relabel 字段，模擬出時間線攪動場景。

如果將采集周期定義為 10 秒鐘，target 數量為 100，那么每秒鐘產生的采樣點數量，約為(680 x 100) / 10 = 6800 個/秒；如果再將攪動率參數設置為每 10 分鐘汰換 10%，那么原始時間線數量為100 x 680 = 68k，每小時新增的時間線數量為100x0.1x(60/10)x680 = 41k。

通過兩個 query 組件我們可以周期性的發起查詢請求，其中 alert query 默認每次發起 33 個告警查詢，持續時間基本都在5分鐘以內；range query 默認每次發起 32 個 range 查詢，時間跨度包括1小時、3小時、6小時、24小時。

4.測試工具使用

測試工具使用需要兩個前提條件：1，所在機器能聯通到k8s集群；2，機器上安裝helm。編輯chart/values.yaml 文件，修改其中remoteStorages等配置；編輯chart/files中alerts.yaml和range_query.yaml，作為帶發起的告警查詢和范圍查詢；調整Makefile中的namespace等配置，使用make install安裝部署，即可從數據源采集數據并寫入到remoteStorages中，同時按照配置的頻率發起查詢。

同時在部署的 pod 上，默認增加了 Prometheus 采集的相關 annotation，如果集群中已經安裝了阿里云 Prometheus，會自動采集測試工具的相關指標數據，包括寫入速率、寫入采樣點數量、查詢速率、查詢成功數量、查詢耗時等。

小型集群告警查詢場景

集群預設：

• • 集群設置 100 個 target，約等于一個普通的小型 k8s 集群，每秒寫入數據為 (100x680)/10 = 6.8k個采樣點，原始時間線為 100x680 = 68k 條，每小時汰換 1% 的 target，即每小時新增 100x680x0.01=680 條時間線，四舍五入約等于零。
  • 查詢組件每3秒鐘發起一批，共計 31 個告警查詢，查詢時間跨度 2～5 分鐘不等。

環境部署：

• • 開源 Prometheus 部署在一套 4C32G 200G SSD 阿里云資源上。

開源 Prometheus 資源使用情況

• 內存使用（GB）

• CPU使用率百分比

性能表現對比

• 查詢 QPS（黃色為開源 Prometheus 數據曲線，綠色為阿里云 Prometheus 服務數據曲線）

• 查詢耗時（黃色為開源 Prometheus 數據曲線，綠色為阿里云 Prometheus 服務數據曲線）

• 寫入速率對比（KB/s，黃色為開源Prometheus數據曲線，綠色為阿里云Prometheus服務數據曲線）

測試結論

在這種基礎場景下，開源 Prometheus 在六小時的測試期間表現穩定，資源消耗較低，響應速度也能讓人滿意。

小型集群范圍查詢場景

經歷了第一場熱身，雙方表現勢均力敵。于是我們升級測試項目，增加范圍查詢場景，尤其在 Prometheus+Grafana 中，大部分都是范圍查詢。

集群預設：

• • 集群設置 100 個 target，抓取周期為 10s，每小時 1% 的汰換率。
  • 每五秒鐘發起一批范圍查詢，查詢跨度統一為 3 小時，查詢頻率為每5秒發起一批，每批 50 條查詢語句，超時時間 30 秒鐘。

環境部署：

• • 開源 Prometheus 部署在一套 4C32G 200G SSD 阿里云資源上。

開源 Prometheus 資源使用

• 內存使用（GB）

• CPU 使用率百分比

性能表現對比

• 查詢 QPS（黃色為開源 Prometheus 數據曲線，綠色為阿里云 Prometheus 服務數據曲線）

• 查詢耗時（P95，黃色為開源 Prometheus 數據曲線，綠色為阿里云 Prometheus 服務數據曲線)

• 數據寫入速率（KB/s，黃色為開源Prometheus數據曲線，綠色為阿里云Prometheus服務數據曲線）

測試結論

相比上一輪，本輪測試數據采集量并沒有變化，總數據量基本一致，開源 Prometheus 內存使用同樣是持平狀態。但我們增加范圍查詢后，CPU 使用量發生明顯變化，長時間持續在 60% 水位，按照 node exporter 默認告警規則，節點 CPU 使用率瞬時值達到 80% 即可觸發告警，開源 Prometheus 節點的 CPU 使用率已逼近需要關注水位。

在測試開始后約三個小時（0:30 - 3:30），開源 Prometheus 的 CPU 使用率即達到 60%，根據測試場景預設條件我們可以計算出此時時間線數量和收集的采樣點數量。時間線數量約為 100x680 + 3x100x680x0.01 = 70k，采樣點數量(3x3600/10)x100x680=7kw，單個采樣點長度約 256B，數據壓縮率 8%，所以數據文件大小約為 7kwx256Bx0.08/1024/1024=1434M，這個數據量并不大，同時時間線變化很少。

發起的范圍查詢請求 QPS=10，一般打開一個 Grafana dashboard 時同時發起的查詢都在 20~50 左右（不過因為瀏覽器的限制，這些查詢并不是真正的同時發起），再考慮到大盤的定時刷新功能和同時打開多個大盤的情況，這個 QPS 在日常使用中是可以比較容易達到的，但依然使開源 Prometheus 的 CPU 消耗飆升。

究其原因，我們認為開源 Prometheus 存在兩個問題，一是響應時間較長的問題，因為開源 Prometheus 默認只支持 10 個查詢并發，大概率會出現請求等待情況，延長的響應時間（但也拉平了CPU壓力)；另一個 CPU 使用率較高問題，我們查看開源版本 Prometheus CPU 使用情況（如下圖），大量 CPU 消耗在用戶進程上，PromQL 查詢中需要對采樣點進行各種切分與計算，從而產生大量數值計算，確實很容易把 CPU 打高。同時，開源 Prometheus engine 是單線程處理數據，可以視為要將每個采樣點“捋一遍”，這種串行化的處理方式，也是其響應時間遠遜于阿里云 Prometheus 服務的原因之一。

小型集群高攪動率場景

在前兩輪測試中，我們預設場景都是比較理想的穩定集群，時間線汰換率非常低。實際場景往往沒有這么理想，往往因為各種原因產生大量時間線，比如指標設計不合理、pod頻繁重啟等。這一輪測試中，我們預設場景就是一個非常不穩定的集群，target頻繁汰換，考驗下開源 Prometheus 和阿里云 Prometheus 服務在這種場景下表現如何。

集群設置：

• • 模擬 100 個 node exporter作為target，依然是一個小規模k8s集群的量級，每十秒鐘抓取一次，即寫入速率依然為6.8k/秒。原始時間線數量680x100 = 680k，攪動率設置為十分鐘汰換99%，即每十分鐘會重新產生 680x100 = 68k 時間線，每小時會新產生約 41 萬時間線。
  • 每 10 秒鐘發起一批 range query，使用測試工具中默認的 32 條 range query，查詢時間范圍從 1h～24h 不等，查詢超時時間為 30 秒。

環境部署：

• • 開源 Prometheus 部署機器配置為 4C32G 200G SSD。

開源Prometheus資源使用情況

• 內存使用（GB)

• CPU使用率百分比

性能表現對比

• 查詢 QPS（黃色為開源 Prometheus 數據曲線，綠色為阿里云 Prometheus 服務數據曲線）

• 查詢耗時（P95，黃色為開源 Prometheus 數據曲線，綠色為阿里云 Prometheus 服務數據曲線）

• 數據寫入速率（Byte/s，黃色為開源 Prometheus 數據曲線，綠色為阿里云 Prometheus 服務數據曲線）

測試結論

攪動率較高時，開源 Prometheus 表現非常勉強，內存與 CPU 使用量呈現線性上漲，在堅持了八個多小時之后，機器無響應，直至被 OS kill 掉。

根據測試場景預設，我們可以大致計算下時間線總量，其中初始時間線數量 680x100 = 68000，每小時新增時間線數量 680x100x6x8 = 326w，總量相加一共計 333w。也就是說一臺 4C32G 機器，最多只能承受 333w 時間線，實際應用中我們必然需要保留余量，如果按照 50% 水位作為警戒線，約只能承擔 333萬 x 50% = 165萬 時間線。此外，考慮到實際應用中，數據保存時間少則半個月，多則半年一年，長時間數據存儲也會帶來額外內存壓力，所以一旦總時間線數量達到 100w 時，就應當提高警惕，小心應對了。

作為對比，在我們截圖的時刻，阿里云 Prometheus 服務已經寫入了 680x100 + 680x100x6x12 = 4964000 即約 500w 時間線，寫入和查詢的表現依然穩定。

中型集群高攪動率場景

經歷過前面三輪比對，我們對開源 Prometheus 的性能表現有了一定了解：單純寫入性能較好，查詢很吃 CPU，時間線數量對性能影響很大，內存消耗會成倍上升，CPU 開銷也會暴漲。

面對性能瓶頸，最直接最簡單的想法就是垂直擴容，換句話就是告訴老板加機器。加機器就能解決的問題都有一個隱含的前提條件：資源增長是線性的。如果資源是指數增長，那加機器就是一個無底洞：增加十倍的硬件投入，只能提升一倍的性能，這種情況下還走垂直擴容的路子，只能是為硬件廠商打工。

在這一輪測試中，我們提升了開源 Prometheus 的硬件機器規格，使用一臺 16C64G 200GSSD 的機器來應對高攪動率場景。

集群設置：

• • 模擬一個中型規模的 k8s 集群，500 個 target，每 10 秒鐘抓取一輪，每十分鐘汰換 99% 的 target，所以初始時間線數量為 680x500 = 34w，每小時新增時間線數量為 680x500x0.99x6 = 2019600 即每小時新增時間線數量為 200w。
  • 查詢請求方面，依然使用工具集中默認的 32 條范圍查詢，但發起查詢的間隔擴大為 30s，查詢超時時間依然設置為 30s。

環境部署：

• • 開源 Prometheus 部署機器配置為 16C64G 200GSSD。

開源 Prometheus 資源使用

• 內存使用（GB)

• CPU 使用率百分比

性能表現對比

• 查詢 QPS（黃色為開源 Prometheus 數據曲線，綠色為阿里云 Prometheus 服務數據曲線）

• 查詢耗時（P95，黃色為開源 Prometheus 數據曲線，綠色為阿里云 Prometheus 服務數據曲線）

• 數據寫入速率（Byte/s，黃色為開源 Prometheus 數據曲線，綠色為阿里云 Prometheus 服務數據曲線）

測試結論

開源 Prometheus 在堅持四個小時后終于倒下，總計寫入的時間線約為 34w + 200w x 4 = 834w。我們將硬件資源提升了四倍，但實際承載的時間線總數只提升了 834w / 333w = 2.5倍。顯然，時間線高基數，對 Prometheus 性能的影響是非線性的，即時間線基數越高，單位資源能承載的平均時間線數量越少。越大規模集群，堆硬件越不劃算。

細心的 SRE 們觀察到了另一個現象：相較于小型集群的高攪動率場景，這一輪的查詢 QPS 下降到了 1/s，而 CPU 資源也沒有像上次一樣與內存幾乎同步耗盡，而是在達到了 40% 的時候，因為內存耗盡導致機器無響應，也凸顯了 PromQL 查詢對 CPU 的消耗嚴重性。

開源 Prometheus 倒下后，阿里云 Prometheus 服務并沒有停步，最終在測試期間，已經吞下了 34w + 200w x 12 = 1434w 條時間線，依托于云服務無限擴展的特性，對于用戶來說，阿里云 Prometheus 服務的承載能力也可以認為是一個“無底洞”，借助各種彈性策略及發現讀/寫瓶頸時自動水平擴展等手段，保證服務質量。

大型集群高攪動率場景測試

從上一輪的測試中，我們幾乎能確定基數較高時，開源 Prometheus 的資源消耗是指數級上升的，所以使用硬件配置更好的機器，承載能力不可能有成倍的提升。我們將在這一輪測試中嘗試證實或證偽這個推論。在這一輪測試中，我們基本沿用了上一輪設置。

集群設置：

• • target 總數漲到 2000 個。初始時間線數量 680 x 2000 = 136w，每小時新增時間線數量為 680 x2000 x0.99 x6 = 807w。其他配置保持不變。

環境部署：

• • 開源 Prometheus 部署機器配置為 64C 256G。

開源 Prometheus 資源使用

• 內存使用（GB）

• CPU 使用率百分比

性能表現對比

• 查詢 QPS（黃色為開源 Prometheus 數據曲線，綠色為阿里云 Prometheus 服務數據曲線）

• 查詢耗時（P95，黃色為開源 Prometheus 數據曲線，綠色為阿里云 Prometheus 服務數據曲線）

• 數據寫入速率（Byte/s，黃色為開源 Prometheus 數據曲線，綠色為阿里云 Prometheus 服務數據曲線）

測試結論

本輪中開源 Prometheus 一共堅持了約兩小時四十分鐘，寫入時間線總數為 136w + 800w x 2.67 = 2300w，對比上一輪，在硬件擴容四倍的情況下，實際支撐能力擴大了2300w /834w = 2.75 倍。進一步印證了其性能消耗非線性增長的結論。

長周期查詢場景測試

前面幾輪的測試中，我們著重比較了高攪動率/時間線爆炸場景下，開源 Prometheus 和阿里云 Prometheus 服務的性能表現，阿里云 Prometheus 服務對時間線的承載能力遠高于開源版本。在日常使用中，另一個經常遇到的，容易觸及 Prometheus 性能邊界的場景就是長周期查詢。較大的查詢時間跨度，一方面需要加載更多的時間線和采樣點數據，另一方面計算量也會跟著翻倍，直接把 IO/內存/CPU 三大項全都考驗了一遍。

因為開源 Prometheus 不接受數據亂序寫入，所以這一輪的測試中，我們提前進行了一周時間的數據準備，我們使用 ksm（kube state metrics）作為數據源，模擬了 120 個 ksm，因為測試集群規模較小，單個 ksm 暴露的時間線數量約為2500，所以總時間線數量為 2500 * 120 = 30w。采集間隔為 30s，所以每月產生的指標總量約為(30w/30) *60*60*24*30 = 260億，每周產生的指標總量約為(30w/30) *60*60*24*7 = 60億。

測試集群繼續沿用了之前的 64C 256G 高配機器。

五天數據查詢

查詢語句：sum(kube_pod_container_resource_requests_memory_bytes) by (node, namespace)

查詢時間跨度：now - 5d ~ now

查詢step：10m（頁面默認）

查詢耗時：2.71s（阿里云Prometheus服務） 16.3s（開源Prometheus）

查詢語句：(sum(kube_pod_container_resource_requests{resource=~"cpu"})by (node) / sum(kube_node_status_allocatable{resource=~"cpu"})by (node) ) * 100 > 30

查詢時間跨度：`now -6d ~ now - 1d`

查詢step：10m（頁面默認）

查詢耗時：3.59s（阿里云Prometheus服務） 14.0s（開源Prometheus）

七天跨度批量查詢

更多的時候，我們會是在 Grafana dashboard 上發起 Prometheus 查詢，一個dashboard上會同時發起 20 到 30 個查詢。多個查詢同時處理時，開源 Prometheus 和阿里云 Prometheus 服務的表現又將如何呢？

我們在 exporter 中同時發起 10 個查詢（事實上因為 Chrome 瀏覽器并發連接數限制，實際上同時發出的請求數無法達到 10 個），來模擬同時發起多個查詢的場景。查詢時間跨度設置為七天。查詢語句如下：

阿里云 Prometheus 服務總體耗時在 13 秒左右，因為瀏覽器并發請求數的限制，查詢請求不是同時發出的，每個請求的響應時間在 5 到 6 秒左右。

開源 Prometheus 總體耗時在 53 秒左右，因為單個請求耗時更久，疊加并發請求數的限制，導致總體耗時大約是阿里云 Prometheus 服務的 4 倍左右，單個請求的耗時也都在 16 到 37s。

測試結論

在本輪測試中，自建 Prometheus 即使在資源充沛的情況下，長跨度查詢速度也遠遜于阿里云 Prometheus 服務。這是因為阿里云 Prometheus 服務并不是簡單的開源托管，我們在查詢方面做了非常多的技術優化，包括算子下推、降采樣、函數計算優化等技術手段，綜合提升大查詢/長時間跨度查詢的性能表現。

實際上隨著查詢時間跨度的繼續加長，阿里云 Prometheus 服務的查詢性能優勢相較于開源 Prometheus 會更加明顯。同時開源 Prometheus 默認支持的并發查詢只有 20（并發查詢 20，并發 remote read 10），而阿里云 Prometheus 服務依托強大的云化計算資源，并發查詢能力輕松上千。對于 SRE 而言，從長周期數據中觀察系統異常變化規律非常重要，對于 IT 體系管理人員而言，從長周期數據中觀察系統的演進趨勢也是必不可少的工作，在這種場景下，開源 Prometheus 并不是一個可靠的伙伴。

測試總結

經過了六輪不同角度不同強度的測試，我們也可以得到一些初步的結論：

• 寫入性能一般不會成為 Prometheus 的瓶頸。在大型集群高攪動率場景測試中，我們的寫入速率最高，每分鐘寫入采樣點數達到了 816w（136wx60/10 = 816w），但無論是開源 Prometheus 還是阿里云 Prometheus 服務均能很好的承接這種量級的寫入。這也符合時序數據庫寫多讀少的設計思路。
• 查詢對 CPU 的消耗遠多于寫入。在小型集群范圍查詢場景測試中體現最為明顯，僅僅是查詢測試期間幾個小時的數據，就能輕易將 CPU 使用率拉升到 60% 的高位。因為 Prometheus 的所謂查詢，并不是將數據從存儲中讀出來就完事，更多的是各種 PromQL 的處理，其中包含大量的數據切分、判斷、計算，所以如果有大查詢/復雜查詢/長周期查詢/高時間線基數查詢時，很容易將 CPU 打滿。
• 時間線數量對 Prometheus 的內存消耗影響很大，且不是線性增長。
  • 在小型集群高攪動率場景、中型集群高攪動率場景、大型集群高攪動率場景下，面對時間線爆炸的情況下，三個集群都沒能堅持太久就掛掉，掛掉的原因也都是內存耗盡導致 OOMKill。
  • 時間線增多同樣導致查詢變慢，在三個場景的查詢耗時 P95 中，隨著時間線的增多，阿里云 Prometheus 服務的查詢響應時間也會相應變長。因為在 promQL 邏輯中，尤其是很多函數計算邏輯中，每條時間線是需要單獨計算的，100w 時間線就要計算 100w 輪，所以響應時間自然也要變長。
  • 資源消耗的增長是非線性的。相比小型集群，中型集群的資源擴了四倍，實際承載的時間線數量增長了 2.5 倍；相比中型集群，大型集群的資源也擴了四倍，實際承載的時間線數量增長了 2.75 倍。即如果集群吐出的時間線數量就是很多，加機器硬抗并不是一個明智的選擇。
  • 阿里云 Prometheus 服務針對高基數存儲/查詢做了不少有效的優化，所以在高基數的承載能力、高基數的查詢響應上都能將開源 Prometheus 拉開一定距離。
• 長時間跨度查詢除了要消耗大量 CPU 時間，還因為要加載數天的數據，帶來更多的 IO 消耗，兩相疊加導致查詢響應會比較慢。阿里云 Prometheus 服務在這方面做了很多技術優化，包括 TSDB 數據文件優化、文件加載優化、降采樣、算子下推、函數計算優化等等，最終的查詢效率較開源 Prometheus 高出數倍。

阿里云 Prometheus 服務 VS 開源

成本永遠是企業用戶說不膩的話題。IT 上云對于降低/拉平企業數字化成本的作用毋庸置疑，而具體到 Prometheus 組件上，云服務的成本表現，相比于自建模式會怎樣呢，我們在這里一起做一個簡單的比較。以下的自建成本計算中，我們統一使用張家口 region 的 ECS 價格。

場景1：小規模線上集群

線上這個詞在IT語境中有著神奇的魔力，任何名詞只要前面加上“生產/線上”的前綴，聊天室的氣氛都會瞬間嚴肅起來。不信你在公司群里，發一句“老板咱們線上環境掛了”試試 :

線上環境里，可觀測能力不再是可選項，而是必選項，平時要可用，預警問題要管用，排查問題時更得中用。這就對我們的可觀測工具提出了更高的要求，既要有優秀的 SLA，又要好用易用，關鍵時刻才能成為排查問題的神兵利器，而不只是一個簡單花哨的數據展板。

自建一個這樣的 Prometheus 工具套件，與使用阿里云 Prometheus 服務的成本又能差多少呢？

假設我們現在面對的，是一個小型線上集群，五臺物理機上運行了 50 個業務 pod，各種依賴的基礎設施如 DB，redis 等有 10 個 pod，另外還有 10 個 k8s 的基礎組件 pod，共計 70 個 pod 的小集群。這樣一個集群里，主要的指標來源有：

• node exporter，1200 series per exporter x 5 exporter = 6000 series
• kube state metrics，15000 series per exporter = 15000 series
• cadvisor，7000 series per exporter x 5 exporter = 35000 series
• infra pod，1500 series x 10 pod = 15000 series
• 其他 pod 指標（JVM等）10000

按照 30 秒抓取一次，每月抓取 86400次（2x60x24x30），基礎指標（node exporter/kube state metrics/cadvisor）指標量約 48.4 億，自定義指標（infra pod，其他pod）指標量約 21.6 億，日均自定義指標量 72M。我們將采集到的數據通過 remote write 的方式再寫一份到備節點，以保證數據的可用，數據保留時長設定為一個月。

自建的成本每一項都不高，零零碎碎加起來卻比阿里云 Prometheus 服務高很多，大約這就是批發和零售的差距吧~ :)

在上面的成本比較中，因為自建 Prometheus 的人力成本會相對復雜，所以我們這里按照 8000 元/月的中高級運維工程師工資計算。實際上，搭建一套完整的可觀測系統，人力的投入并不是敲幾個命令行將 Prometheus 跑起來那么簡單。

在真實的業務應用中，幾乎一定會依賴到各種各樣的基礎設施，包括但不限于 DB、gateway、MQ、redis 等等，這些組件健康與否直接關系整個系統的穩定運行。而對于SRE來說，就意味著必須要為這些組件配套 exporter、繪制大盤、配置告警等等，也意味著需要長期持續的優化大盤優化告警，這些細碎而必要的工作帶來的額外人力分散在每時每刻，咋一看不起眼，匯總起來卻是不小的企業成本。對此，阿里云 Prometheus 服務提供了集成中心功能，其中集成了監控常見的基礎設施組件的快捷入口，一鍵完成 exporter 部署安裝、dashboard 繪制、告警規則配置的能力，讓客戶的精力從這些瑣碎的事情中釋放出來，聚焦于更有價值的部分。

同時，系統出現異常時，也是可觀測系統大顯身手的時候，如果我們能有一個優秀的 dashboard，將散落各處的觀測數據歸集到一起，對于問題處理會有事半功倍的效果。但這方面開源社區并沒有太多可供借鑒的東西，開源社區中更多關注大盤的通用性而非易用性。

針對 SRE 的現實需求，阿里云 Prometheus 服務依賴自身在可觀測領域的多年積淀，以及對我們用戶使用場景的總結提煉，針對 POD/NODE/K8s/ingress/Deployment 等場景，在包年包月版本中，特別提供了 Pro 版本大盤，將常用的指標監控和日志、進程、網絡、事件、應用性能等分項監控融為一爐，一張大盤通觀全局，讓角落里的異常也無處遁形。以 Pod Pro 大盤為例，在一張盤中整合了日志、事件、網絡、應用性能等多個維度的數據，SRE 們無需手忙腳亂的在各種系統/工具/大盤中切換奔波，便捷高效的定位異常，盡早扼殺問題苗頭。更多其他的 Pro 版本大盤，也都在這里列出[7]，供大家參考。

場景2：隨著業務發展壯大

隨著業務發展壯大，集群規模也更大了，SRE肩上的擔子有重了許多，我們需要更多資源來應對挑戰。

我們預設這是一個中等規格的容器集群，有十臺物理機，其中運行了200個業務pod，配套的各種 infrastructure 如 MySQL、redis、MQ、gateway、注冊中心、配置中心等共計 50 個 Pod，另外有 k8s 自帶的各種 Pod 如網絡插件，存儲插件等約 30 個。繼續沿用主從模式保證可用性。同時我們將數據存儲時長延長到六個月，以便長期趨勢觀察和異常追溯。

集群的時間線數量預估如下：

• node exporter，1500 series per exporter x 10 = 15000 series
• cadvisor，10000 series per node x 10 = 100000 series
• ksm，20000 series = 20000 series
• infra pod，1500 series * 50 = 75000 series
• 其他自定義指標（如JVM）20000 series

一個月約產生基礎指標 116 億，自定義指標（infrastructure產生的指標）82 億。

共計約 200 億采樣點，單個采樣點體積平均約256B，壓縮率8%，數據文件體積 200 億 x 256B x 8% ，即約 410G。六個月數據的總體積約 410G x 6 = 2460G。

當前集群的初始的時間線數量已經達到了 20w+，即使只考慮正常業務更新帶來的 pod 啟停（pod 啟停會帶來大量新的時間線，pod 頻繁重啟則一定會帶來時間線爆炸），六個月時間內累計的時間線也能輕松突破 100w，所以我們選用了 ecs.g6e.4xlarge 規格的機器來保證系統裕度。

要維護這樣的一套 Prometheus 環境，加上各種周邊設施（exporter，Grafana，alert等），至少需要投入 0.2 個人力，也就意味著每月數千元的人力成本投入。

場景3：多集群統一監控

對于規模較大的企業，生產集群往往會有多個，一來更加靠近客戶，提供更快的響應速度，二來也可以提供一些容災能力，避免整個線上環境被一鍋端。但對于SRE而言，這樣的架構方式就需要將數據做匯總，開源 Prometheus 提供了聯邦集群的方式，阿里云 Prometheus 服務提供了 GlobalView 功能，都可以做到一次查多個集群，針對這兩種方式，我們再次來估算下監控成本。

假設我們的應用部署在三個不同 region，集群規模參考上場景 2 中的集群。我們有三種部署方案：

• 分層聯邦模式，三個開源Prometheus集群分布在三個不同region（worker） + 一個高級別的federate集群（master），其中master集群配置和worker保持一致，但不使用備節點。
• remote write模式，將三個region的數據remote write到一個中心節點，所以中心節點的資源需求也會更高。
• 使用ARMS Prometheus的GlobalView，三個ARMS Prometheus集群分布在三個不同region（worker） + 一個GlobalView集群（master）
• remote write模式，將是哪個region的數據remote write到同一個ARMS Prometheus實例中，使用大規格 Prometheus 實例（250 億采樣點/月）。

隨著數據采集規模的擴大，阿里云 Prometheus 服務的成本優勢更加明顯，而且免運維的特性更加釋放了 SRE 的人力投入。同時配合阿里云云原生可觀測家族的其他組件，能夠完整的覆蓋各種可觀測場景（log/trace/metrics），聚力協同，為企業系統的穩定運行保駕護航。

總結

總的來看，開源 Prometheus 在順風局表現還是不錯的，低負載時響應和資源使用都可圈可點。但現實很殘酷，理想的場景并不多見，總是會有各種層出不窮的意外挑戰 SRE 們緊繃的神經（題外話：解決和預防各種意外，不就是 SRE 的目標么？），對于無論是事前預防，事中告警，事后復盤，一套可靠的可觀測體系都能讓你事半功倍，用詳實準確的數據支撐你的行動。

事實上阿里云 Prometheus 服務工具箱里，不止有性能強悍的存儲能力，還有很多其他的神兵利器，比如化繁為簡的預聚合，比如高性能且自動擴展的采集 agent，比如 xxx，后續我們會持續為大家介紹。用我們的產品和服務，幫助 SRE 們更加 Reliable！

相關鏈接

按量付費成本計算請參考

https://help.aliyun.com/document_detail/183914.html

[1] 《2023 年十大戰略技術趨勢》

https://www.gartner.com/cn/newsroom/press-releases/2023-top-10-strategic-tech-trends

[2] 兼容性測試工具

https://github.com/prometheus/compliance

[3] 兼容性為 97.06%

https://help.aliyun.com/document_detail/408652.html

[4] 優于 AWS 和 GCP

https://promlabs.com/promql-compliance-tests/

[5] prometheus-benchmark

https://github.com/VictoriaMetrics/prometheus-benchmark

[6] 項目存放在 GitHub 上

https://github.com/liushv0/prometheus-benchmark

[7] 這里列出

https://help.aliyun.com/document_detail/440066.html#section-9ot-waf-tt5

作者：智真

原文鏈接

本文為阿里云原創內容，未經允許不得轉載。

總結

以上是生活随笔為你收集整理的对比开源丨Prometheus 服务多场景存储压测全解析的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。