Kubernetes 使用 SQL 進行可靠性監控
Kubernetes 建立了許多短暫的物件，因此按 pod 對原始觀察結果進行分組通常會產生嘈雜的報告。從工作負載邊界開始：叢集、名稱空間、部署或作業所有者、應用程式發布、受控轉換、就緒結果以及工作負載執行的面向客戶的工作。
與儀資料表分開的轉換
當觀察到的重啟計數器增加時，發出 container_restarted 事件。將累積計數器保留為上下文，但不要跨樣本求和。將準備情況記錄為單獨的布林觀察。計劃中的部署可以取代健康的 Pod，而崩潰迴圈會產生重複的重新啟動轉換，並且通常會導致持續的就緒性損失。
使用有界叢集、名稱空間和工作負載名稱。請勿將 Kubernetes 機密、環境變數值、完整清單、容器參數、原始日誌訊息或客戶負載複製到事件中。
對不穩定的工作負載進行排名
Kubernetes 重啟 SQL 配方 按工作負載對觀察進行分組，對重新啟動轉換進行計數，保留最大觀察計數器，並計算未就緒率。它的裝置展示了轉換計數和累積重啟狀態之間的差異。
按以下順序調查結果：
- 確認重複重新啟動，而不僅僅是部署替換。
- 檢查同一視窗內是否發生就緒性丟失。
- 比較版本、節點池、叢集和受控原因類別。
- 加入 API 故障、延遲作業或其他產品結果的計時。
基礎設施配方收集 增加了資源飽和度、心跳和事件計時。這些訊號有助於區分應用程式故障與容量壓力或更廣泛的叢集問題。
建置收集器到事件邊界和工作負載所有者規範化時，請從 Kubernetes整合指南 開始。
就影響而非流失發出警示
工作負載儀表板應將重新啟動轉換、準備情況、推出標記和應用程式錯誤率放在一起。僅在審查持續狀況後才調頁；一個重新安排的 Pod 或預期的部署更換通常是不可操作的。
Kubernetes 可靠性用例 為事件合約提供編碼代理提示。在使用查詢進行生產回應之前，驗證綜合重啟、部署、恢復和延遲事件案例。