用例證據路徑
Kubernetes Reliability Monitoring with SQL：從實施到決策
完整的 kubernetes reliability monitoring with sql 測量迴圈連線一個擁有的工作流程、一個有界事件契約、一個受控裝置和一個有人可以採取行動的問題。
- 1
設定邊界
在範圍內選擇叢集、名稱空間和麵向客戶的工作負載。
- 2
捕捉結果
Begin with kubernetes_workload_sampled, kubernetes_container_restarted, kubernetes_rollout_observed and document the grain of each event.
- 3
證明行數
在分頁之前與工作負載所有者一起檢查持續閾值。
- 4
做出決定
哪些工作負載會重複重新啟動，而不是僅在部署期間重新啟動？
代理提示
將其貼上到您的編碼代理中
更換 YOUR_API_KEY 註冊後，然後要求代理執行產品流程並驗證第一個事件。
代理提示
Kubernetes Reliability Monitoring with SQL 設定提示
text
使用 Telemetry 檢測 Kubernetes 工作負載可靠性。
使用 /skill.md 和此 Telemetry API 金鑰：YOUR_API_KEY
使用 cluster、namespace、workload、pod、event_name、restart_count、ready、release 和 environment 發出受控工作負載事件。僅當有限原因類別已經可用並獲得批准時才新增它。
建立 SQL 和儀表板，用於按工作負載重新啟動轉換、就緒性損失、部署更改和相關應用程式錯誤。僅在重複重啟以及持續就緒或產品影響時發出警示。
請勿傳送 Kubernetes 機密、環境變數值、完整清單、原始日誌、容器參數或客戶負載。設定步驟
- 1在範圍內選擇叢集、名稱空間和麵向客戶的工作負載。
- 2發出有界重啟、就緒、部署和工作負載結果事件。
- 3進行安全的綜合重啟和有計劃的更換。
- 4在分頁之前與工作負載所有者一起檢查持續閾值。
要捕獲的事件
kubernetes_workload_sampledkubernetes_container_restartedkubernetes_rollout_observedservice_request_completed
問題已解鎖
- 哪些工作負載會重複重新啟動，而不是僅在部署期間重新啟動？
- 準備度損失在哪裡與失敗的產品工作相一致？
- 不穩定是從版本、節點池或叢集更改開始的嗎？
事件架構起點
此工作流程的事件契約
在將查詢或程式碼片段適應生產之前，請檢查行粒度、發出邊界、所需型別、隱私類、範例有效負載和驗證清單。
相關產品功能
繼續此工作流程 警示
將經過審查的可靠性查詢提升到擁有的閾值和回應工作流程中。
相關 SQL 查詢範例
用 SQL 回答下一個問題
針對此工作流程中的結構化欄位執行查詢，檢查範例結果，並將有用的答案轉換為儀表板或警示。
相關頁面