告警
我們建議您閱讀基於 Rob Ewaschuk 在 Google 觀察的《我的告警哲學》 。
總結來說：保持告警簡潔，基於症狀告警，擁有良好的控制檯以定位原因，並避免發出無需處理的告警。
命名
告警規則的命名沒有嚴格限制，告警名稱可以包含任意數量的 Unicode 字元，就像其他標籤值一樣。然而，社群普遍採用 駝峰命名法 來命名告警。
告警內容
目標是儘可能減少告警數量，透過對與終端使用者痛點相關的症狀進行告警，而不是試圖捕獲所有可能導致痛點的方式。告警應連結到相關的控制檯，並方便找出是哪個元件出了問題。
在告警中留出餘地，以適應小的波動。
線上服務系統
通常情況下，應在技術棧中儘可能高的層級對高延遲和錯誤率進行告警。
只在技術棧的一個點上對延遲發出呼叫。如果一個低階元件比預期慢，但整體使用者延遲正常，則無需發出呼叫。
對於錯誤率，應針對使用者可見的錯誤發出呼叫。如果技術棧深層出現會導致此類故障的錯誤，則無需單獨對它們發出呼叫。然而，如果某些故障是使用者不可見的，但其嚴重程度足以需要人工干預（例如，您正在損失大量資金），則應為此類故障新增呼叫。
如果不同型別的請求具有不同的特性，或者低流量請求中的問題可能被高流量請求掩蓋，您可能需要為它們設定不同的告警。
離線處理
對於離線處理系統，關鍵指標是資料透過系統所需的時間，因此如果時間過長，足以影響使用者，則應發出呼叫。
批處理作業
對於批處理作業，如果它近期未成功執行，並且這將導致使用者可見的問題，那麼發出呼叫是有意義的。
這通常至少應是批處理作業完整執行兩次所需的時間。對於一個每4小時執行一次，每次耗時一小時的作業，10小時將是一個合理的閾值。如果您無法承受單次執行失敗，則應更頻繁地執行該作業，因為單次失敗不應需要人工干預。
容量
雖然接近容量不會立即對使用者造成影響，但通常需要人工干預以避免在不久的將來發生中斷。
元監控
確保監控系統正常執行至關重要。因此，應設定告警以確保 Prometheus 伺服器、Alertmanager、PushGateway 和其他監控基礎設施可用並正常執行。
一如既往，如果可能，對症狀而非原因進行告警有助於減少噪音。例如，一個黑盒測試能告警從 PushGateway 到 Prometheus 再到 Alertmanager 直至電子郵件的整個流程，這比對每個單獨元件設定告警要好。
用外部黑盒監控補充 Prometheus 的白盒監控可以發現其他不可見的問題，並在內部系統完全失效時作為備用方案。