Prometheus 是一個開源監控系統，它本身已經成為了云原生中指標監控的事實標準，幾乎所有 k8s 的核心組件以及其它云原生系統都以 Prometheus 的指標格式輸出自己的運行時監控信息。我在工作中也比較深入地使用過 Prometheus，最大的感受就是它非常容易維護，突出一個簡單省心成本低。當然，這當中也免不了踩過一些坑，下面就總結一下。

[[280782]]

假如你沒有用過 Prometheus，建議先看一遍官方文檔。

接受準確性與可靠性的權衡

Prometheus 作為一個基于指標(Metric)的監控系統，在設計上就放棄了一部分數據準確性：

比如在兩次采樣的間隔中，內存用量有一個瞬時小尖峰，那么這次小尖峰我們是觀察不到的;

再比如 QPS、RT、P95、P99 這些值都只能估算，無法和日志系統一樣做到 100% 準確，下面也會講一個相關的坑。

放棄一點準確性得到的是更高的可靠性，這里的可靠性體現為架構簡單、數據簡單、運維簡單。假如你維護過 ELK 或其它日志架構的話，就會發現相比于指標，日志系統想要穩定地跑下去需要付出幾十倍的機器成本與人力成本。既然是權衡，那就沒有好或不好，只有適合不適合，我推薦在應用 Prometheus 之初就要先考慮清楚這個問題，并且將這個權衡明確地告訴使用方。

首先做好自監控

不知道你有沒有考慮過一個問題，其它系統都用 Prometheus 監控起來了，報警規則也設置好了，那 Prometheus 本身由誰來監控?

答案是”另一個監控系統”，而這個監控系統可以是另一個 Prometheus。按照官方的 quickstart 或 helm 部署的 Prometheus 單實例自己監控自己的，我們當然不能指望一個系統掛掉之后自己發現自己掛了。

因此我強烈建議在上生產環境之前，一定要確保至少有兩個獨立的 Prometheus 實例互相做交叉監控。交叉監控的配置也很簡單，每臺 Prometheus 都拉取其余所有 Prometheus 的指標即可。

還有一個點是警報系統(Alertmanager)，我們再考慮一下警報系統掛掉的情況：這時候 Prometheus 可以監控到警報系統掛了，但是因為警報掛掉了，所以警報自然就發不出來，這也是應用 Prometheus 之前必須搞定的問題。這個問題可以通過給警報系統做 HA 來應對。除此之外還有一個經典的兜底措施叫做 “Dead man’s switch”: 定義一條永遠會觸發的告警，不斷通知，假如哪天這條通知停了，那么說明報警鏈路出問題了。

不要使用 NFS 做存儲

如題，Prometheus 維護者也在 issue 中表示過不支持 NFS。這點我們有血淚教訓(我們曾經有一臺 Prometheus 存儲文件發生損壞丟失了歷史數據)。

盡早干掉維度過高的指標

根據我們的經驗，Prometheus 里有 50% 以上的存儲空間和 80% 以上的計算資源(CPU、內存)都是被那么兩三個維度超高的指標用掉的。而且這類維度超高的指標由于數據量很大，稍微查得野一點就會 OOM 搞死 Prometheus 實例。

首先要明確這類指標是對 Prometheus 的濫用，類似需求完全應該放到日志流或數倉里去算。但是指標的接入方關注的往往是業務上夠不夠方便，假如足夠方便的話什么都可以往 label 里塞。這就需要我們防患于未然，一個有效的辦法是用警報規則找出維度過高的壞指標，然后在 Scrape 配置里 Drop 掉導致維度過高的 label。

警報規則的例子：

# 統計每個指標的時間序列數，超出 10000 的報警 
count by (__name__)({__name__=~".+"}) > 10000 

“壞指標”報警出來之后，就可以用 metric_relabel_config 的 drop 操作刪掉有問題的 label(比如 userId、email 這些一看就是問題戶)，這里的配置方式可以查閱文檔。

對了，這條的關鍵詞是盡早，最好就是部署完就搞上這條規則，否則等哪天 Prometheus 容量滿了再去找業務方說要刪 label，那業務方可能就要忍不住扇你了……

Rate 類函數 + Recording Rule 的坑

可能你已經知道了 PromQL 里要先 rate() 再 sum()，不能 sum() 完再 rate()(不知道也沒事，馬上講)。但當 rate() 已經同類型的函數如 increase() 和 recording rule 碰到一起時，可能就會不小心掉到坑里去。

當時，我們已經有了一個維度很高的指標(只能繼續維護了，因為沒有盡早干掉)，為了讓大家查詢得更快一點，我們設計了一個 Recording Rule，用 sum() 來去掉維度過高的 bad_label，得到一個新指標。那么只要不涉及到 bad_label，大家就可以用新指標進行查詢，Recording Rule 如下：

sum(old_metric) without (bad_label) 

用了一段時候后，大家發現 new_metric 做 rate() 得到的 QPS 趨勢圖里經常有奇怪的尖峰，但 old_metric 就不會出現。這時我們恍然大悟：繞了個彎踩進了 rate() 的坑里。

這背后與 rate() 的實現方式有關，rate() 在設計上假定對應的指標是一個 Counter，也就是只有 incr(增加) 和 reset(歸0) 兩種行為。而做了 sum() 或其他聚合之后，得到的就不再是一個 Counter 了，舉個例子，比如 sum() 的計算對象中有一個歸0了，那整體的和會下降，而不是歸零，這會影響 rate() 中判斷 reset(歸0) 的邏輯，從而導致錯誤的結果。寫 PromQL 時這個坑容易避免，但碰到 Recording Rule 就不那么容易了，因為不去看配置的話大家也想不到 new_metric 是怎么來的。

要完全規避這個坑，可以遵守一個原則：Recording Rule 一步到位，直接算出需要的值，避免算出一個中間結果再拿去做聚合。

警報和歷史趨勢圖未必 Match

最近半年常常被問兩個問題：

• 我的歷史趨勢圖看上去超過水位線了，警報為什么沒報?
• 我的歷史趨勢圖看上去挺正常的，警報為什么報了?

這其中有一個原因是：趨勢圖上每個采樣點的采樣時間和警報規則每次的計算時間不是嚴格一致的。當時間區間拉得比較大的時候，采樣點非常稀疏，不如警報計算的間隔來得密集，這個現象尤為明顯，比如時序圖采樣了 0秒，60秒，120秒三個點。而警報在15秒，30秒，45秒連續計算出了異常，那在圖上就看不出來。另外，經過越多的聚合以及函數操作，不同時間點的數據差異會來得越明顯，有時確實容易混淆。

這個其實不是問題，碰到時將趨勢圖的采樣間隔拉到最小，仔細比對一下，就能驗證警報的準確性。而對于聚合很復雜的警報，可以先寫一條 Recording Rule, 再針對 Recording Rule 產生的新指標來建警報。這種范式也能幫助我們更高效地去建分級警報(超過不同閾值對應不同的緊急程度)

group_interval 會影響 resolved 通知

Alertmanager 里有一個叫 group_interval 的配置，用于控制同一個 group 內的警報最快多久通知一次。這里有一個問題是 firing(激活) 和 resolved(已消除) 的警報通知是共享同一個 group 的。也就是說，假設我們的 group_interval 是默認的 5 分鐘，那么一條警報激活十幾秒后立馬就消除了，它的消除通知會在報警通知的 5 分鐘之后才到，因為在發完報警通知之后，這個 Group 需要等待 5 分鐘的 group_interval 才能進行下一次通知。

這個設計讓”警報消除就立馬發送消除通知”變得幾乎不可能，因為假如把 group_interval 變得很小的話，警報通知就會過于頻繁，而調大的話，就會拖累到消除通知。

這個問題修改一點源碼即可解決，不過無傷大雅，不修也完全沒問題。

最后一條：不要忘記因何而來

最后一條撒點雞湯：監控的核心目標還是護航業務穩定，保障業務的快速迭代，永遠不要忘記因何而來。

曾經有一端時間，我們追求”監控的覆蓋率”，所有系統所有層面，一定要有指標，而且具體信息 label 分得越細越好，最后搞出幾千個監控項，不僅搞得眼花繚亂還讓 Prometheus 變慢了。

還有一段時間，我們追求”警報的覆蓋率”，事無巨細必有要有警報，人人有責全體收警報(有些警報會發送給幾十個人)。最后當然你也能預想到了，告警風暴讓大家都對警報疲勞了。

這些事情乍看起來都是在努力工作，但其實一開始的方向就錯了，監控的目標絕對不是為了達到 xxx 個指標，xxx 條警報規則，這些東西有什么意義?

依我看，負責監控的開發就算不是 SRE 也要有 SRE 的心態和視野，不要為監控系統的功能或覆蓋面負責(這樣很可讓導致開發在監控里堆砌功能和內容，變得越來越臃腫越來越不可靠)，而要為整個業務的穩定性負責，同時站在穩定性的投入產出比角度去考慮每件事情的性質和意義，不要忘記我們因何而來。