我們建議您閱讀我關於警報的哲學，該哲學基於 Rob Ewaschuk 在 Google 的觀察。
總結：保持警報簡單，警報症狀，擁有良好的控制台以精確指出原因，並避免出現無事可做的頁面。
關於警報規則的命名沒有嚴格的限制，因為警報名稱可以包含任意數量的 Unicode 字元，就像任何其他標籤值一樣。但是，社群已團結起來使用駝峰式命名法作為其警報名稱。
目標是盡可能減少警報，方法是針對與最終用戶痛苦相關的症狀發出警報，而不是試圖捕獲可能導致痛苦的每一種可能方式。警報應連結到相關控制台，並使其易於找出哪個元件有問題。
允許警報中的鬆弛以適應小的跳動。
通常會盡可能在高層堆疊上警報高延遲和錯誤率。
僅在堆疊中的一個點對延遲進行分頁。如果較低層的元件比應有的速度慢，但整體使用者延遲很好，則無需分頁。
對於錯誤率，在使用者可見的錯誤上進行分頁。如果堆疊下方有錯誤會導致此類故障，則無需單獨對它們進行分頁。但是，如果某些故障不是使用者可見的，但嚴重到需要人工介入（例如，您正在損失很多錢），請新增發送到這些故障的分頁。
如果不同類型的請求具有不同的特性，或者低流量類型的請求中的問題會被高流量請求淹沒，則您可能需要針對不同類型的請求發出警報。
對於離線處理系統，關鍵指標是數據通過系統所需的時間，因此如果該時間變得足夠高以至於對用戶產生影響，則應進行分頁。
對於批次作業，如果批次作業最近沒有成功，並且這會導致使用者可見的問題，則進行分頁是有意義的。
這通常應該至少足夠讓批次作業完整執行 2 次。對於每 4 小時執行一次並花費 1 小時的作業，10 小時將是一個合理的閾值。如果您無法承受單次執行失敗，請更頻繁地執行該作業，因為單次失敗不應需要人工干預。
雖然這不是導致立即使用者影響的問題，但接近容量通常需要人工干預以避免在不久的將來發生停機。
重要的是要對監控是否正常工作有信心。因此，請發出警報以確保 Prometheus 伺服器、Alertmanager、PushGateway 和其他監控基礎設施可用且正常執行。
與往常一樣，如果可以針對症狀而不是原因發出警報，這有助於減少雜訊。例如，一個黑盒測試，警報會從 PushGateway 到 Prometheus 再到 Alertmanager 再到電子郵件，比每個都發出單獨的警報更好。
使用外部黑盒監控來補充 Prometheus 的白盒監控可以捕獲其他不可見的問題，並且在內部系統完全失敗時也可以作為後備。
這份文件是開源的。請透過提交問題或拉取請求來協助改進它。