Prometheus 是一個開源監控系統，它本身已經成為了雲原生中名額監控的事實标準，幾乎所有 k8s 的核心元件以及其它雲原生系統都以 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 存儲檔案發生損壞丢失了曆史資料)。
盡早幹掉次元過高的名額
根據我們的經驗，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 的心态和視野，不要為監控系統的功能或覆寫面負責(這樣很可讓導緻開發在監控裡堆砌功能和内容，變得越來越臃腫越來越不可靠)，而要為整個業務的穩定性負責，同時站在穩定性的投入産出比角度去考慮每件事情的性質和意義，不要忘記我們因何而來。
作者丨吳葉磊 來源丨https://aleiwu.com/post/prometheus-bp/ dbaplus社群歡迎廣大技術人員投稿，投稿郵箱： [email protected] > > > >
活動推薦
11月15日，廣州：Gdevops全球靈活運維峰會将舉辦2019年度收官盛會，重點圍繞智慧運維、DevOps、資料庫領域，攜手阿裡、騰訊、京東、螞蟻金服、新浪微網誌、甜橙金融、聯通大資料、微衆銀行、貝殼找房、新炬網絡等技術代表展開年度技術總結與發展趨勢展望，掃碼汲取全年技術精華。
