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

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

當(dāng)然不是。

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

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

測前概念解讀

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

1.時間線（Time Series）

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

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

2.時間線高基數(shù)（High Cardinality）

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

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

3.高攪動率（High Churn Rate）

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

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

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

測試場景

測試工具和測試數(shù)據(jù)計算

1.測試環(huán)境

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

2.測試工具

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

3.測試條件設(shè)置

默認(rèn)使用 node exporter 作為指標(biāo)數(shù)據(jù)源，node exporter 產(chǎn)生的時間線數(shù)量和物理機(jī)器有關(guān)，比如 CPU 相關(guān)指標(biāo)和機(jī)器核數(shù)有關(guān)系，FileSystem 相關(guān)指標(biāo)和實際掛載的文件系統(tǒng)數(shù)量有關(guān)，而運行 pod 較多的機(jī)器，掛載的文件系統(tǒng)也會更多。在施壓集群機(jī)器節(jié)點上，我們將單個 node exporter 實際產(chǎn)出的時間線數(shù)量控制在（680±5）之間，后續(xù)的測試估算中，我們按照 680 per node exporter 的標(biāo)準(zhǔn)來估算。

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

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

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

4.測試工具使用

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

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

小型集群告警查詢場景

集群預(yù)設(shè)：

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

環(huán)境部署：

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

開源 Prometheus 資源使用情況

• 內(nèi)存使用（GB）

• CPU使用率百分比

性能表現(xiàn)對比

• 查詢 QPS（黃色為開源 Prometheus 數(shù)據(jù)曲線，綠色為阿里云 Prometheus 服務(wù)數(shù)據(jù)曲線）

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

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

測試結(jié)論

在這種基礎(chǔ)場景下，開源 Prometheus 在六小時的測試期間表現(xiàn)穩(wěn)定，資源消耗較低，響應(yīng)速度也能讓人滿意。

小型集群范圍查詢場景

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

集群預(yù)設(shè)：

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

環(huán)境部署：

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

開源 Prometheus 資源使用

• 內(nèi)存使用（GB）

• CPU 使用率百分比

性能表現(xiàn)對比

• 查詢 QPS（黃色為開源 Prometheus 數(shù)據(jù)曲線，綠色為阿里云 Prometheus 服務(wù)數(shù)據(jù)曲線）

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

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

測試結(jié)論

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

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

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

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

小型集群高攪動率場景

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

集群設(shè)置：

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

環(huán)境部署：

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

開源Prometheus資源使用情況

• 內(nèi)存使用（GB)

• CPU使用率百分比

性能表現(xiàn)對比

• 查詢 QPS（黃色為開源 Prometheus 數(shù)據(jù)曲線，綠色為阿里云 Prometheus 服務(wù)數(shù)據(jù)曲線）

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

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

測試結(jié)論

攪動率較高時，開源 Prometheus 表現(xiàn)非常勉強(qiáng)，內(nèi)存與 CPU 使用量呈現(xiàn)線性上漲，在堅持了八個多小時之后，機(jī)器無響應(yīng)，直至被 OS kill 掉。

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

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

中型集群高攪動率場景

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

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

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

集群設(shè)置：

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

環(huán)境部署：

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

開源 Prometheus 資源使用

• 內(nèi)存使用（GB)

• CPU 使用率百分比

性能表現(xiàn)對比

• 查詢 QPS（黃色為開源 Prometheus 數(shù)據(jù)曲線，綠色為阿里云 Prometheus 服務(wù)數(shù)據(jù)曲線）

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

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

測試結(jié)論

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

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

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

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

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

集群設(shè)置：

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

環(huán)境部署：

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

開源 Prometheus 資源使用

• 內(nèi)存使用（GB）

• CPU 使用率百分比

性能表現(xiàn)對比

• 查詢 QPS（黃色為開源 Prometheus 數(shù)據(jù)曲線，綠色為阿里云 Prometheus 服務(wù)數(shù)據(jù)曲線）

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

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

測試結(jié)論

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

長周期查詢場景測試

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

因為開源 Prometheus 不接受數(shù)據(jù)亂序?qū)懭?#xff0c;所以這一輪的測試中，我們提前進(jìn)行了一周時間的數(shù)據(jù)準(zhǔn)備，我們使用 ksm（kube state metrics）作為數(shù)據(jù)源，模擬了 120 個 ksm，因為測試集群規(guī)模較小，單個 ksm 暴露的時間線數(shù)量約為2500，所以總時間線數(shù)量為 2500 * 120 = 30w。采集間隔為 30s，所以每月產(chǎn)生的指標(biāo)總量約為(30w/30) *60*60*24*30 = 260億，每周產(chǎn)生的指標(biāo)總量約為(30w/30) *60*60*24*7 = 60億。

測試集群繼續(xù)沿用了之前的 64C 256G 高配機(jī)器。

五天數(shù)據(jù)查詢

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

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

查詢step：10m（頁面默認(rèn)）

查詢耗時：2.71s（阿里云Prometheus服務(wù)） 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（頁面默認(rèn)）

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

七天跨度批量查詢

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

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

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

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

測試結(jié)論

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

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

測試總結(jié)

經(jīng)過了六輪不同角度不同強(qiáng)度的測試，我們也可以得到一些初步的結(jié)論：

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

阿里云 Prometheus 服務(wù) VS 開源

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

場景1：小規(guī)模線上集群

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

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

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

假設(shè)我們現(xiàn)在面對的，是一個小型線上集群，五臺物理機(jī)上運行了 50 個業(yè)務(wù) pod，各種依賴的基礎(chǔ)設(shè)施如 DB，redis 等有 10 個 pod，另外還有 10 個 k8s 的基礎(chǔ)組件 pod，共計 70 個 pod 的小集群。這樣一個集群里，主要的指標(biāo)來源有：

• 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 指標(biāo)（JVM等）10000

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

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

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

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

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

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

場景2：隨著業(yè)務(wù)發(fā)展壯大

隨著業(yè)務(wù)發(fā)展壯大，集群規(guī)模也更大了，SRE肩上的擔(dān)子有重了許多，我們需要更多資源來應(yīng)對挑戰(zhàn)。

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

集群的時間線數(shù)量預(yù)估如下：

• 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
• 其他自定義指標(biāo)（如JVM）20000 series

一個月約產(chǎn)生基礎(chǔ)指標(biāo) 116 億，自定義指標(biāo)（infrastructure產(chǎn)生的指標(biāo)）82 億。

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

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

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

場景3：多集群統(tǒng)一監(jiān)控

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

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

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

隨著數(shù)據(jù)采集規(guī)模的擴(kuò)大，阿里云 Prometheus 服務(wù)的成本優(yōu)勢更加明顯，而且免運維的特性更加釋放了 SRE 的人力投入。同時配合阿里云云原生可觀測家族的其他組件，能夠完整的覆蓋各種可觀測場景（log/trace/metrics），聚力協(xié)同，為企業(yè)系統(tǒng)的穩(wěn)定運行保駕護(hù)航。

總結(jié)

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

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

相關(guān)鏈接

按量付費成本計算請參考

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

[1] 《2023 年十大戰(zhàn)略技術(shù)趨勢》

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] 優(yōu)于 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

作者：智真

原文鏈接

本文為阿里云原創(chuàng)內(nèi)容，未經(jīng)允許不得轉(zhuǎn)載。

總結(jié)

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

如果覺得生活随笔網(wǎng)站內(nèi)容還不錯，歡迎將生活随笔推薦給好友。