Kubernetes 使用 SQL 进行可靠性监控
Kubernetes 创建了许多短暂的对象，因此按 pod 对原始观察结果进行分组通常会产生嘈杂的报告。从工作负载边界开始：集群、命名空间、部署或作业所有者、应用程序发布、受控转换、就绪结果以及工作负载执行的面向客户的工作。
与仪表分开的转换
当观察到的重启计数器增加时，发出 container_restarted 事件。将累积计数器保留为上下文，但不要跨样本求和。将准备情况记录为单独的布尔观察。计划中的部署可以取代健康的 Pod，而崩溃循环会产生重复的重新启动转换，并且通常会导致持续的就绪性损失。
使用有界集群、命名空间和工作负载名称。请勿将 Kubernetes 机密、环境变量值、完整清单、容器参数、原始日志消息或客户负载复制到事件中。
对不稳定的工作负载进行排名
Kubernetes 重启 SQL 配方 按工作负载对观察进行分组，对重新启动转换进行计数，保留最大观察计数器，并计算未就绪率。它的装置展示了转换计数和累积重启状态之间的差异。
按以下顺序调查结果：
- 确认重复重新启动，而不仅仅是部署替换。
- 检查同一窗口内是否发生就绪性丢失。
- 比较版本、节点池、集群和受控原因类别。
- 加入 API 故障、延迟作业或其他产品结果的计时。
基础设施配方收集 增加了资源饱和度、心跳和事件计时。这些信号有助于区分应用程序故障与容量压力或更广泛的集群问题。
构建收集器到事件边界和工作负载所有者规范化时，请从 Kubernetes集成指南 开始。
就影响而非流失发出告警
工作负载仪表板应将重新启动转换、准备情况、推出标记和应用程序错误率放在一起。仅在审查持续状况后才调页；一个重新安排的 Pod 或预期的部署更换通常是不可操作的。
Kubernetes 可靠性用例 为事件合约提供编码代理提示。在使用查询进行生产响应之前，验证综合重启、部署、恢复和延迟事件案例。