共同事件契约
使这些查询可重用的字段
- 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 和结果