Kubernetes 监控、日志与告警的最佳实践
1. 仪表盘设计
避免创建过多仪表盘(即“图表墙”),因为在故障排查时,工程师很难从过多图表中理清思路。虽然你可能认为仪表盘包含更多信息意味着更好的监控,但大多数时候,这会让查看仪表盘的用户更加困惑。应将仪表盘设计重点放在结果和解决时间上。
2. 日志概述
要全面了解环境状况,除了收集指标,还需要收集并集中管理 Kubernetes 集群及部署在集群中应用的日志。不过,简单地记录所有内容会带来两个问题:
- 存在过多干扰信息,难以快速定位问题。
- 日志会消耗大量资源,成本较高。
对于具体应记录哪些内容,并没有明确答案,因为调试日志有时虽必要但也会带来干扰。随着时间推移,你会更了解自己的环境,从而过滤掉日志系统中的无用信息。同时,为应对不断增加的日志存储量,需要实施保留和存档策略。从终端用户体验来看,保留 30 至 45 天的历史日志较为合适,这样既能调查长期出现的问题,又能减少日志存储所需的资源。若因合规原因需要长期存储日志,可将其存档到成本更低的资源中。
在 Kubernetes 集群中,需要记录日志的组件如下:
| 组件类型 | 具体组件 |
| ---- | ---- |
| 节点日志 | 收集关键节点服务的事件,如工作节点上 Docker 守护进程的日志 |
| Kubernetes 控制平面日志 | API 服务器、控制器管理器、调度器的日志,需聚合存储在主机 /var/log/kube-APIserver.log
、 /var/log/kube-scheduler.log