Prometheus 不完全避坑指南
Prometheus 是一個開源監控系統，它本身已經成為了雲原生中指標監控的事實標準，幾乎所有 Kubernetes 的核心元件以及其它雲原生系統都以 Prometheus 的指標格式輸出自己的執行時監控資訊。我在工作中也比較深入地使用過 Prometheus，最大的感受就是它非常容易維護，突出一個簡單省心成本低。當然，這當中也免不了踩過一些坑，下面就總結一下。
假如你沒有用過 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 儲存檔案發生損壞丟失了歷史資料）。
儘早幹掉維度（Cardinality）過高的指標
根據我們的經驗，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 產生的新指標來建警報。這種方式也能幫助我們更高效地去建分級警報（超過不同閾值對應不同的緊急程度）。
Alertmanager 的 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 的心態和視野，不要為監控系統的功能或覆蓋面負責（這樣很可讓導致開發在監控裡堆砌功能和內容，變得越來越臃腫越來越不可靠），而要為整個業務的穩定性負責，同時站在穩定性的投入產出比角度去考慮每件事情的性質和意義，不要忘記我們因何而來。