完整譯文請訪問：http://www.coderdocument.com/docs/prometheus/v2.14/best_practices/alerting.html。
對什麼告警
目標是儘可能少地觸發告警，通過關聯終端用戶痛點來觸發告警，而不是試圖捕捉所有可能觸發告警的條件。告警應該鏈接到相關的控制檯，以便於找出哪個組件有問題。
可以對告警保持一定的寬容，以適應小幅波動。
在線服務系統
儘可能對高延遲和高錯誤率情況觸發告警。
在堆棧中某一點的延遲只顯示一個頁面。如果較低級別的組件延遲較高，但是總體來說，延遲良好，那麼就不需要添加頁面。
有關錯誤率，只對“用戶可見錯誤”提供頁面。如果有錯誤會使堆棧掛掉而引發故障，則不需要分別對它們提供分頁。但是，如果有些故障用戶不可見，但是嚴重到需要人工參與（例如，錯誤導致損失很多錢），則需要添加相關頁面。
如果不同類型的請求具有不同的特徵，你可能需要分別對它們發出告警，否則低流量類型的請求中的問題將被高流量請求淹沒。
離線處理
對於離線處理系統，關鍵指標是系統處理數據所需的時間，因此如果數據處理耗時很長，會對用戶造成影響，則添加頁面。
批處理作業
對於批處理作業，如果批處理作業最近沒有成功，則需要添加頁面，而且這將引發用戶可見的問題。
這通常需要足夠的時間執行兩次完整的批處理作業。對於每4小時運行一次、需要1小時的作業，10小時是合理的閾值。如果你無法接受一次運行失敗，請更頻繁地運行作業，因爲一次失敗應該不需要人工進行干預。
容量
雖然容量問題不會立即對用戶造成影響，但容量不足通常需要人工進行干預，以避免在不久的將來出現停機。
元監控
重要的是要確認監控正在發揮作用。因此，要有告警，以確保Prometheus服務器、Alertmanager、PushGateway和其他監控基礎設施是可用的並且正常運行。
與往常一樣，如果能夠根據症狀而不是原因觸發告警，這有助於降噪。例如，從PushGateway到Prometheus，再到Alertmanager，再到電子郵件的告警黑盒測試比各自告警要更合適。
使用外部墨盒監控來補充Prometheus的白盒監控，可以捕捉到原本不可見的問題，也可以在內部系統完全故障時用作回調。