共同事件契約
使這些查詢可重用的欄位
- timestamp_utc，服務、主機、區域、環境和資源
- cpu_utilization_pct、memory_utilization_pct、disk_utilization_pct 和 request_rate
- instance_type、replica_count、部署和 capacity_limit
SQL 之前的定義
查詢無法為您做出的決定
- 1定義多個完整儲存桶的持續飽和度，而不是針對單個峰值發出警示。
- 2保持不同資源型別的單位和利用率分母一致。
- 3在建議更多容量之前，將資源壓力與服務需求聯絡起來。
推薦順序
先建立檢測，然後診斷
分析模式
讓結果解釋決定
將需求與利用率配對
在資源使用旁邊繪製請求或作業量，以便將基礎架構更改與普通工作負載成長分開。
找到持續的壓力
使用完整的時間段和連續的閾值突破來區分容量風險和短暫的爆發。
比較部署邊界
按服務、區域、主機類或部署分解飽和度，以定位不均勻的負載和推出迴歸。
完整的查詢範例
複製查詢，然後驗證假設
入門system_metrics
查詢主機和容器資源飽和度
根據持續的 CPU、記憶體和磁碟利用率對基礎設施源進行排名，同時保留樣本量。
哪些基礎設施來源持續受到資源限制？
檢視 SQL 和結果中級cache_request_events
查詢快取未命中和踩踏風險
透過有界快取鍵模式比較命中率、後端成本和併發缺失。
哪些快取鍵模式將低命中率與併發後端工作結合在一起？
檢視 SQL 和結果高階incident_lifecycle_events
計算事件檢測和恢復時間
計算檢測結構化事件生命週期事件的時間和恢復時間。
每項服務需要多長時間來檢測事件並從事件中恢復？
檢視 SQL 和結果入門kubernetes_workload_events
按工作負載查詢 Kubernetes 重啟情況
按容器重啟事件、就緒失敗和觀察到的累積重啟計數對 Kubernetes 工作負載進行排名。
哪些 Kubernetes 工作負載正在重新啟動並且未透過就緒性檢查？
檢視 SQL 和結果