當(dāng)前位置：首頁 > 编程资源 > 编程问答 >内容正文

编程问答

对比开源丨Prometheus 服务多场景存储压测全解析

發(fā)布時間：2024/1/18 编程问答 35 豆豆

生活随笔收集整理的這篇文章主要介紹了对比开源丨Prometheus 服务多场景存储压测全解析小編覺得挺不錯的,現(xiàn)在分享給大家,幫大家做個參考.

在 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！

總結(jié)

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

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

编程问答

对比开源丨Prometheus 服务多场景存储压测全解析

測前概念解讀

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

測試場景

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

1.測試環(huán)境

2.測試工具

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

4.測試工具使用

小型集群告警查詢場景

開源 Prometheus 資源使用情況

性能表現(xiàn)對比

測試結(jié)論

小型集群范圍查詢場景

開源 Prometheus 資源使用

性能表現(xiàn)對比

測試結(jié)論

小型集群高攪動率場景

開源Prometheus資源使用情況

性能表現(xiàn)對比

測試結(jié)論

中型集群高攪動率場景

開源 Prometheus 資源使用

性能表現(xiàn)對比

測試結(jié)論

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

開源 Prometheus 資源使用

性能表現(xiàn)對比

測試結(jié)論

長周期查詢場景測試

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

七天跨度批量查詢

測試結(jié)論

測試總結(jié)

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

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

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

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

總結(jié)

相關(guān)鏈接

總結(jié)