普羅米修斯的禪學
普羅米修斯的禪學是一套對新手友好的核心價值觀和準則，用於使用Prometheus對應用程式進行儀表化和編寫地道的告警。這是一份旨在由Prometheus社群維護的文件。歡迎貢獻 。
先儀表化，後提問
在開發過程中，你永遠不知道以後需要問什麼問題。軟體需要良好的儀表化，這不是可選項。沒有標籤的指標成本很低。慷慨地使用它們，但在新增標籤時請注意基數。
第一條也是最重要的一條規則——如果你只能記住一件事，就記住這條。儀表化所有事物。
測量使用者關心的事情
你的使用者關心資料庫伺服器是否宕機嗎？他們關心你的CPU飽和度嗎？是的，但不是直接關心——他們關心他們所體驗到的。他們關心是否能訪問請求的頁面以及結果是否最新。請從延遲和可用性的角度思考。讓你的SLO s指導你的儀表化和告警。
你仍然應該測量資料庫可用性和CPU飽和度等內部指標——將它們用於故障排除和容量規劃。
Use causal metrics to answer why something is broken.
標籤是新的層級結構
標籤是新的層級結構，但功能更強大、更靈活。標籤是Prometheus強大的原因。使用標籤，可以對測量結果進行分組和聚合。使用標籤進行切片和分析。記住先儀表化，後提問，儘可能多地提供上下文。但是，你必須謹慎使用標籤。請參閱下面的解釋。
避免缺失指標
直到某些事情發生才出現的時間序列很難處理。為避免這種情況，請為任何你已知可能預先存在的時間序列匯出0。使用零值初始化你的指標，以防止儀表盤損壞和告警誤報。有關更詳細的解釋，請查閱指標的存在性問題 。
請記住，標籤會建立時間序列，因此請使用你期望使用的標籤初始化你的指標——你的客戶端庫無法知道你將擁有哪些標籤。
基數很重要
每組唯一的標籤都會建立一個新的時間序列。謹慎使用標籤，並注意你放入其中的內容。避免基數爆炸；無邊界的標籤會使Prometheus崩潰。請記住，標籤在不同維度上是乘性的。
Prometheus performance almost always comes down to one thing: label cardinality.
永遠記住基數是關鍵 。
命名很難
指標名稱在單個任務中必須具有單一含義，理想情況下在所有任務中也應具有相同含義（例如process_cpu_seconds_total）。
尊重慣例而非偏好。慣例不是任何人的最愛，但慣例卻是所有人的最愛。有關具體細節，請參閱命名文件。
計數器為王，儀表盤遜色
暴露原始計數器，讓Prometheus使用rate()和increase()為你推導速率。不要在目標上預先計算速率——那會丟棄資訊。記住先儀表化，後提問。
當然，儀表盤有其用武之地。在沒有可計數內容（如溫度、磁碟滿度、佇列深度）的週期性測量中，可以使用它們。但如果某個值只會持續增加，則應將其設為計數器。
不要為聚合新增指標；PromQL可以為你完成這項工作。
先計算速率，再聚合
請注意計數器重置 。正如先計算速率，再求和；切勿先求和，再計算速率 中所述。根據經驗法則，你可以安全地直接應用於計數器值的唯一數學操作是rate、irate、increase和resets。任何其他操作都會給你帶來問題。
如果你能記錄它，就能為它設定指標
日誌對於故障排除通常至關重要，但指標同樣有價值——故障排除過程通常在不同的訊號之間來回切換。不要低估指標在理解正在發生的事情方面的價值。
每當你記錄一個事件時，考慮按大類對其進行計數。這成本低廉，可以讓你在錯誤率升高時收到告警，並對正在發生的事情有一個概覽。請記住，沒有標籤的指標成本很低——慷慨地使用計數器。
原生直方圖幾乎總是優於傳統直方圖
原生直方圖解決了傳統直方圖的桶佈局問題。它們無需預定義邊界，動態調整解析度，並使用稀疏表示，其中空桶不產生任何成本。如果你的儀表化庫或OTel支援它們，請為新的儀表化優先選擇原生直方圖。
對於傳統直方圖，建立正確的桶佈局是一門藝術。為了確保你的觀察結果的有用性和告警的正確性，你必須設計一個有意義的桶佈局。這與先儀表化，後提問相沖突，因為你甚至在測量之前就需要對你的延遲有所瞭解。讓你的SLO s指導你的桶佈局；建立與你的SLO匹配的邊界。
傳統直方圖本質上只是帶有標籤的計數器，其中桶邊界被用作標籤。在為直方圖新增額外標籤時要謹慎。請記住，標籤是乘性的，並且基數很重要。
如果你能繪圖，就能為它設定告警
你不能24/7盯著儀表盤。Prometheus統一了指標、儀表盤和告警。PromQL是每個Prometheus告警的核心，PromQL查詢是儀表盤上任何圖表的來源。請使用它。
如果你執行它，就應該為它設定告警
始終為你的目標設定告警，至少包括它們的存在性和健康狀況。你不能依賴那些無法觀察或採取行動的事物。
避免缺失和不健康的目標。Prometheus會自動為每個目標生成up指標。請使用它。
告警應是緊急的、重要的、可操作的、真實的
告警應是緊急的、重要的、可操作的、真實的 。就是這麼簡單。
不要過度告警，告警疲勞是真實存在的。
基於症狀的告警用於呼叫，基於原因的告警用於故障排除
與測量使用者關心的事情類似，對真正重要的事情進行告警。如果你的使用者沒有注意到，CPU飽和與否並不重要。讓你的SLO s指導你的告警。
並非所有告警都需要呼叫某人。基於原因的告警不應喚醒任何人——它們應匯入到儀表盤或工單佇列中，以便在需要時檢查或在空閒時批次處理。將呼叫保留給指示使用者可見影響的基於症狀的告警。
有關更多上下文，請參閱我的告警哲學 。
請再等五分鐘
Prometheus告警規則允許你指定一個for持續時間，該時間決定了條件必須為真多久告警才會觸發。如果你不指定它，一次抓取失敗就可能觸發告警。你需要容忍度。通常，至少使用5分鐘，除非你有特殊原因要另行處理。有關更多資訊，請查閱設定告警閾值 。
上下文為王
為你的告警保留常見和有用的標籤。它們對於路由和靜默化最有用。
這個想法的靈感來源於Go語言之禪 、Go語言諺語 和Python之禪 。
*Thank you very much all others that contributed with their invaluable ideas.*
The initial rules are gathered from several sources from the community, such as [Prometheus Proverbs](https://www.youtube.com/watch?v=TwH3KXKbJqM) by [Björn Rabenstein](https://github.com/beorn7), [Best Practices and Beastly Pitfalls](https://www.youtube.com/watch?v=_MNYuTNfTb4) by [Julius Volz](https://github.com/juliusv), [Patterns for Instrumenting Your Go Services](https://www.youtube.com/watch?v=LU6D5cNeHks) by [Bartek Plotka](https://github.com/bwplotka) and [Kemal Akkoyun](https://github.com/kakkoyun), [Instrumenting Applications and Alerting with Prometheus](https://www.youtube.com/watch?v=sHKWD8XnmmY) by [Simon Pasquier](https://github.com/simonpasquier) and [Robust Perception Blog](https://www.robustperception.io/blog) by [Brian Brazil](https://github.com/brian-brazil).
更多資源
遵循這些慣例可以讓你從社群工具中受益
- 監控混入 - 常見服務的可重用儀表盤和告警