基本現(xiàn)狀

我們是分區(qū)分服的游戲，生產(chǎn)環(huán)境會(huì)有幾百上千個(gè)游戲服進(jìn)程，這些進(jìn)程都想接入 prometheus 做一些指標(biāo)監(jiān)控。優(yōu)化前的狀況是：

• 全局只部署一個(gè) pushgateway。
• 每個(gè)物理服會(huì)部署 50 個(gè)左右的游戲服進(jìn)程，每個(gè)進(jìn)程定時(shí)打印指標(biāo)到各自的指標(biāo) log 文件。
• 每個(gè)物理服部署一個(gè)定時(shí)腳本，每 10 秒串行的采集各個(gè)指標(biāo) log，并通過 curl post 給 pushgateway。
• prometheus 從 pushgateway pull 指標(biāo)。

沒有直接在游戲服進(jìn)程中內(nèi)置 exporter 的原因大致有：

• 上線之后才考慮加上 prometheus 監(jiān)控，不想做太多改動(dòng)，畢竟還涉及端口暴露之類的問題，需要運(yùn)維配合修改開服腳本。
• 進(jìn)程量太多了，而且頻繁開新服、合服，需要頻繁修改 prometheus 配置。

其實(shí)以上都是借口，不過多年的經(jīng)驗(yàn)告訴我，讓 prometheus 從上千個(gè)進(jìn)程 pull 指標(biāo)，估計(jì)也會(huì)出現(xiàn)一些性能問題：）

存在的問題

pushgateway 性能太差，不足以支撐這樣的并發(fā)量，每個(gè) post 的延遲為 5 秒左右，而定時(shí)腳本是串行工作的，所以每一輪總耗時(shí)為 250 秒左右，完全是不可用狀態(tài)。

優(yōu)化措施

我對(duì) prometheus、pushgateway 做了一些研究，經(jīng)過幾次優(yōu)化，單輪延遲從 250 秒下降到 0.1 秒，達(dá)到可用狀態(tài)。下面逐一介紹我使用過的優(yōu)化手段，其中優(yōu)化一跟優(yōu)化三帶來的效果是最明顯的。

優(yōu)化一：多個(gè)游戲服的指標(biāo)合并發(fā)送。

• 優(yōu)化效果
  單輪延遲從 250 秒下降到 6 秒。

• 具體做法
  定時(shí)腳本每輪采集完本機(jī)上所有的指標(biāo) log，把內(nèi)容合并后再一次性 post 給 pushgateway。
  prometheus 的指標(biāo)是這樣定義的：

指標(biāo)名{標(biāo)簽,...} 指標(biāo)值

比如：

memory{"server_id":1,"zone":1001,"service":"clusterd"} 10000

prometheus 會(huì)從多個(gè) target pull 指標(biāo)，但它并不是很關(guān)心一個(gè)指標(biāo)是從哪個(gè) target 來的（雖然可以配置不同 target 給指標(biāo)附加一些特定的標(biāo)簽值），只要保證 “指標(biāo)名+標(biāo)簽” 是唯一的就夠了。我們的 server_id 是唯一的，能夠保證唯一性。

優(yōu)化二：pushgateway 開啟 gzip 支持

• 優(yōu)化效果
  單輪延遲從 6 秒降到 4 秒。文檔的壓縮率挺高，1.7MB 的 log 文件經(jīng)過壓縮后是 94KB。

• 具體做法
  關(guān)于 gzip 使用的說明 https://github.com/prometheus/pushgateway#request-compression：

Request compression
The body of a POST or PUT request may be gzip- or snappy-compressed. Add a header Content-Encoding: gzip or Content-Encoding: snappy to do so.

echo "some_metric 3.14" | gzip | curl -H 'Content-Encoding: gzip' --data-binary @- http://pushgateway.example.org:9091/metrics/job/some_job

優(yōu)化三：每個(gè)物理服部署 pushgateway

• 優(yōu)化效果
  單輪延遲從 4 秒下降到 0.1 秒。

• 具體做法
  直接在每個(gè)物理服上部署一個(gè) pushgateway，服務(wù)于本服上的所有游戲服進(jìn)程；prometheus 修改配置，從多個(gè) pushgateway pull 數(shù)據(jù)。雖然 pushgateway 數(shù)量增加了，但其實(shí)沒增加多少，以 1000 個(gè)游戲服，每個(gè)物理服部署 50 個(gè)游戲服計(jì)算，也才 20 個(gè) pushgateway，對(duì) prometheus 來說壓力不大。

以上優(yōu)化完，整個(gè)拓?fù)浯蟾攀沁@樣子：

優(yōu)化過程回顧

在 pushgateway 的 github 主頁 (https://github.com/prometheus/pushgateway)，README.md 最開始就寫了設(shè)計(jì)初衷：

The Prometheus Pushgateway exists to allow ephemeral and batch jobs to expose their metrics to Prometheus. Since these kinds of jobs may not exist long enough to be scraped, they can instead push their metrics to a Pushgateway. The Pushgateway then exposes these metrics to Prometheus.

而我并沒有注意到這個(gè)，很多人也都沒注意到這個(gè)。我花了不少時(shí)間在 github issues 搜索 performance 相關(guān)的 issue；在 google 搜索 “pushgateway 性能差”、“pushgateway bad performance”，但都沒啥收獲。

唯一的收獲是發(fā)現(xiàn)新版本的 pushgateway 支持 gzip 了，但這個(gè)帶來的效果并不怎么明顯。

關(guān)于 performance，這個(gè) issue “Feature request: Multi-thread support #402” (https://github.com/prometheus/pushgateway/issues/402) 說的內(nèi)容跟我的場(chǎng)景有點(diǎn)類似。他提到他們有 1000 個(gè) client 需要發(fā)指標(biāo)給 pushgateway，當(dāng)只有一個(gè) pushgateway 時(shí)請(qǐng)求延遲是 4 分鐘，當(dāng)數(shù)量增加到三個(gè)之后，請(qǐng)求延遲下降到 12 秒，所以他問 pushgateway 是否能提供多線程支持。而項(xiàng)目維護(hù)者的回復(fù)是:

https://github.com/prometheus-community/PushProx may be helpful for your use case, but as said, details need to be discussed elsewhere.

Also note that using the PGW to allow push with Prometheus is not just a performance problem. There are loads of semantic problems, too (like inability to deal with metric inconsistencies, up-monitoring, staleness handling, …). That’s why I like to keep the PGW simple and focused on what it is meant for.

pushgateway 的維護(hù)者說得也有道理，要 “keep the PGW simple and focusd on what it is meant for”, blah blah …。哎，反正他懶得優(yōu)化的時(shí)候，這些都是說得過去的說辭。

不過也沒關(guān)系，通過這些優(yōu)化手段：1.批量合并指標(biāo)數(shù)據(jù) 2.多進(jìn)程方式部署 pushgateway，我們也達(dá)到了優(yōu)化目標(biāo)，并且能扛住未來數(shù)據(jù)量的增長(zhǎng)。

總結(jié)

• pushgateway 沒有多線程支持，并發(fā)性能很差，并且未來也不考慮支持多線程，因?yàn)樗脑O(shè)計(jì)目標(biāo)不在于此。
• pushgateway 在生產(chǎn)環(huán)境應(yīng)該以多進(jìn)程的方式進(jìn)行部署，可以每個(gè)物理服部署一個(gè)進(jìn)程。
• 往 pushgateway 發(fā)送指標(biāo)數(shù)據(jù)的時(shí)候，盡量把數(shù)據(jù)合并起來發(fā)送，減少發(fā)送的次數(shù)，合并的時(shí)候想辦法保證 “指標(biāo)名+標(biāo)簽” 唯一就行了。
• 使用一個(gè)工具前，需要深入了解此工具的設(shè)計(jì)初衷、適用場(chǎng)景、性能局限等。
• 一個(gè)項(xiàng)目的文檔，最關(guān)鍵的內(nèi)容往往放在最開頭，不妨花點(diǎn)時(shí)間好好讀一讀。

本文首發(fā)于我的博客：https://blog.antsmallant.top/2023/09/14/prometheus-pushgateway文章來源地址http://www.zghlxwxcb.cn/news/detail-789870.html

到了這里，關(guān)于prometheus pushgateway 性能差的解決辦法的文章就介紹完了。如果您還想了解更多內(nèi)容，請(qǐng)?jiān)谟疑辖撬阉鱐OY模板網(wǎng)以前的文章或繼續(xù)瀏覽下面的相關(guān)文章，希望大家以后多多支持TOY模板網(wǎng)！