7、Kubernetes 监控、日志、告警及配置管理最佳实践

Kubernetes 监控、日志、告警及配置管理最佳实践

1. 告警（Alerting）

告警是一把双刃剑，需要在监控和告警之间找到平衡。过度告警会导致告警疲劳，重要事件会被淹没在大量噪音中。例如，每次 Pod 失败都触发告警，而 Kubernetes 本身具备自动检查容器健康状况并重启容器的功能，所以应该将告警重点放在影响服务级别目标（SLO）的事件上。

SLO 是与服务的最终用户商定的特定可衡量特征，如可用性、吞吐量、频率和响应时间等。设定 SLO 能让最终用户对服务有明确的预期，也能清晰界定系统的行为。没有 SLO，用户可能会形成不切实际的期望。在 Kubernetes 这样的系统中进行告警，需要一种全新的方法，重点关注最终用户对服务的体验。例如，前端服务的 SLO 是 20 毫秒的响应时间，若发现延迟高于平均水平，就应触发告警。

1.1 确定有效告警

在典型的监控中，习惯对高 CPU 使用率、高内存使用率或进程无响应等情况进行告警，但这些可能并不需要立即采取行动并通知值班工程师。告警应针对需要立即人工关注且影响应用程序用户体验（UX）的问题。如果出现“问题自行解决”的情况，就说明该告警无需通知值班工程师。

1.2 处理无需立即行动的告警

对于无需立即行动的告警，可以专注于自动修复问题根源。例如，当磁盘满时，可自动删除日志以释放磁盘空间。在应用部署中使用 Kubernetes 的存活探针，有助于自动修复应用中无响应的进程问题。

1.3 考虑告警阈值

构建告警时，要考虑告警阈值。若阈值设置过短，会产生大量误报。一般建议设置至少五分钟的阈值，以减少误报。制定标准阈值有