大前篇提問

• config 裡可設定的參數會影響哪些模組？重載 config 時會發生什麼事？
• Prometheus Server 啟動時，各模組初始化順序是怎樣的？分別有哪些初始化工作？
• Prometheus Server 的運行過程中，有哪些模組會產生 goroutine？
• 各模組產生的 goroutine 遇到 timeout 或錯誤時，會如何處理？

本篇來回答各模組的非同步流程遇到錯誤時的處理方式。

錯誤的種類

一般系統上遇到的外部錯誤有以下幾種：

• 事件發生或處理完畢的時間點不如預期（timeout）
• 讀寫失敗，包含寫入檔案系統和 remote storage。
• 讀取到的資料不合理

對於使用者觸發的流程錯誤，通常只要回傳錯誤訊息，並確保系統的狀態能繼續運行即可。使用者（無論是其他程式或人）可以根據錯誤訊息來決定下一步行動。
然面對非同步流程的錯誤，由於沒有人能及時介入做決定，系統需要先訂好規則，並在遇到錯誤時自動依規則處理。

以下是 Prometheus Server 的在遇到各種錯誤時的處理方式。

時間點不如預期

Rule 的規則執行超過時間

計入 metric，並跳過該樣本的計算。

Scrape 到的樣本時間超過容許範圍

計入 metric，並寫入 nil（沒拉到資料）。

Scrape 的過程超過時間限或錯誤

計入 metric，並寫入 nil（沒拉到資料）。

讀寫失敗

Service Discovery 讀取失敗

使用上一次讀到的標的列表，並在下次讀取時再次嘗試讀取。

Service Discovery 結果通知寫入失敗

不做任何處理，因為寫入失敗代表上一次的更新還在進行中，下次更新時會再次嘗試寫入。

Notify 通知寫入失敗

跳過該筆通知。

Rule 的規則計算和寫入失敗

計入 metric，並跳過該樣本的計算。

Scrape 到的樣本寫入失敗

計入 metric，並跳過該樣本。

讀取到的資料不合理

Notify 通知模板套用失敗

跳過該筆通知。

Rule 的規則無法解讀

所有規則（包括所有檔案來源）都不會被載入，續用現行的 Rule 並且會在 log 中記錄錯誤訊息。

Rule Manager 啟動時資料缺失

例如 Prometheus 重新啟動的情況，Rule Manager 會嘗試在兩個抽樣週期內回填缺失的資料，以正確判斷 Alert 應處的狀態。
若兩個抽樣週期內仍未回填，則視為資料缺失。

Scrape Group 解讀失敗

跳過該 Group，該 Group 會被無視。