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

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

當(dāng)然不是。

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

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

測(cè)前概念解讀

在開(kāi)始前，我們先闡述測(cè)試過(guò)程中涉及的問(wèn)題與概念。

1.時(shí)間線（Time Series）

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

因?yàn)槠渲械腸ity這個(gè)label對(duì)應(yīng)的值不同；temperature{city="BJ",country="CN"}和 humidity{city="BJ",country="CN"} 也是兩條不相同的時(shí)間線，因?yàn)樵赑rometheus中，指標(biāo)名稱(chēng)也對(duì)應(yīng)一個(gè)特殊的label __name__。時(shí)間線中的label會(huì)被索引以加速查詢，所以時(shí)間線越多存儲(chǔ)壓力越大。

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

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

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

3.高攪動(dòng)率（High Churn Rate）

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

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

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

測(cè)試場(chǎng)景

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

1.測(cè)試環(huán)境

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

2.測(cè)試工具

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

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

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

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

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

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

4.測(cè)試工具使用

測(cè)試工具使用需要兩個(gè)前提條件：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ù)并寫(xiě)入到remoteStorages中，同時(shí)按照配置的頻率發(fā)起查詢。

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

小型集群告警查詢場(chǎng)景

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

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

環(huán)境部署：

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

開(kāi)源 Prometheus 資源使用情況

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

• CPU使用率百分比

性能表現(xiàn)對(duì)比

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

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

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

測(cè)試結(jié)論

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

小型集群范圍查詢場(chǎng)景

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

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

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

環(huán)境部署：

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

開(kāi)源 Prometheus 資源使用

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

• CPU 使用率百分比

性能表現(xiàn)對(duì)比

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

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

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

測(cè)試結(jié)論

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

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

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

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

小型集群高攪動(dòng)率場(chǎng)景

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

集群設(shè)置：

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

環(huán)境部署：

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

開(kāi)源Prometheus資源使用情況

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

• CPU使用率百分比

性能表現(xiàn)對(duì)比

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

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

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

測(cè)試結(jié)論

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

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

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

中型集群高攪動(dòng)率場(chǎng)景

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

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

在這一輪測(cè)試中，我們提升了開(kāi)源 Prometheus 的硬件機(jī)器規(guī)格，使用一臺(tái) 16C64G 200GSSD 的機(jī)器來(lái)應(yīng)對(duì)高攪動(dòng)率場(chǎng)景。

集群設(shè)置：

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

環(huán)境部署：

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

開(kāi)源 Prometheus 資源使用

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

• CPU 使用率百分比

性能表現(xiàn)對(duì)比

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

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

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

測(cè)試結(jié)論

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

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

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

大型集群高攪動(dòng)率場(chǎng)景測(cè)試

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

集群設(shè)置：

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

環(huán)境部署：

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

開(kāi)源 Prometheus 資源使用

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

• CPU 使用率百分比

性能表現(xiàn)對(duì)比

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

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

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

測(cè)試結(jié)論

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

長(zhǎng)周期查詢場(chǎng)景測(cè)試

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

因?yàn)殚_(kāi)源 Prometheus 不接受數(shù)據(jù)亂序?qū)懭?#xff0c;所以這一輪的測(cè)試中，我們提前進(jìn)行了一周時(shí)間的數(shù)據(jù)準(zhǔn)備，我們使用 ksm（kube state metrics）作為數(shù)據(jù)源，模擬了 120 個(gè) ksm，因?yàn)闇y(cè)試集群規(guī)模較小，單個(gè) ksm 暴露的時(shí)間線數(shù)量約為2500，所以總時(shí)間線數(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億。

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

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

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

查詢時(shí)間跨度：now - 5d ~ now

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

查詢耗時(shí)：2.71s（阿里云Prometheus服務(wù)） 16.3s（開(kāi)源Prometheus）

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

查詢時(shí)間跨度：`now -6d ~ now - 1d`

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

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

七天跨度批量查詢

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

我們?cè)?exporter 中同時(shí)發(fā)起 10 個(gè)查詢（事實(shí)上因?yàn)?Chrome 瀏覽器并發(fā)連接數(shù)限制，實(shí)際上同時(shí)發(fā)出的請(qǐng)求數(shù)無(wú)法達(dá)到 10 個(gè)），來(lái)模擬同時(shí)發(fā)起多個(gè)查詢的場(chǎng)景。查詢時(shí)間跨度設(shè)置為七天。查詢語(yǔ)句如下：

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

開(kāi)源 Prometheus 總體耗時(shí)在 53 秒左右，因?yàn)閱蝹€(gè)請(qǐng)求耗時(shí)更久，疊加并發(fā)請(qǐng)求數(shù)的限制，導(dǎo)致總體耗時(shí)大約是阿里云 Prometheus 服務(wù)的 4 倍左右，單個(gè)請(qǐng)求的耗時(shí)也都在 16 到 37s。

測(cè)試結(jié)論

在本輪測(cè)試中，自建 Prometheus 即使在資源充沛的情況下，長(zhǎng)跨度查詢速度也遠(yuǎn)遜于阿里云 Prometheus 服務(wù)。這是因?yàn)榘⒗镌?Prometheus 服務(wù)并不是簡(jiǎn)單的開(kāi)源托管，我們?cè)诓樵兎矫孀隽朔浅６嗟募夹g(shù)優(yōu)化，包括算子下推、降采樣、函數(shù)計(jì)算優(yōu)化等技術(shù)手段，綜合提升大查詢/長(zhǎng)時(shí)間跨度查詢的性能表現(xiàn)。

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

測(cè)試總結(jié)

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

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

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

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

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

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

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

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

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

• 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ù)通過(guò) remote write 的方式再寫(xiě)一份到備節(jié)點(diǎn)，以保證數(shù)據(jù)的可用，數(shù)據(jù)保留時(shí)長(zhǎng)設(shè)定為一個(gè)月。

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

在上面的成本比較中，因?yàn)樽越?Prometheus 的人力成本會(huì)相對(duì)復(fù)雜，所以我們這里按照 8000 元/月的中高級(jí)運(yùn)維工程師工資計(jì)算。實(shí)際上，搭建一套完整的可觀測(cè)系統(tǒng)，人力的投入并不是敲幾個(gè)命令行將 Prometheus 跑起來(lái)那么簡(jiǎn)單。

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

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

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

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

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

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

集群的時(shí)間線數(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

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

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

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

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

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

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

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

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

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

總結(jié)

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

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

相關(guān)鏈接

按量付費(fèi)成本計(jì)算請(qǐng)參考

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

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

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

[2] 兼容性測(cè)試工具

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] 項(xiàng)目存放在 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 服务多场景存储压测全解析的全部?jī)?nèi)容，希望文章能夠幫你解決所遇到的問(wèn)題。

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