基于 K8s 的 Prometheus + Grafana 监控告警体系要覆盖哪些部分

在 Kubernetes 上搭监控，Prometheus 只是其中一环。一套能用的告警体系要同时回答四个问题：指标从哪来、存到哪、怎么看、出事通知谁。这份记录按这四个环节把要覆盖的内容列一遍，顺便记下规模上来以后才会遇到的那几件事。

一、采集：四类对象都要覆盖

按对象分，至少要覆盖物理节点、容器、线上业务、Kubernetes 自身的组件和资源四类。前两类看资源水位，第三类要看接口耗时和错误率这类业务指标，第四类最容易被漏掉——集群组件不健康时，业务表现往往只是「莫名其妙变慢」。拿不准的短生命周期任务，指标推不进抓取流程，就用 Pushgateway 先接住再被抓取；它上面的指标不会自动过期，作业跑完要主动清掉，否则面板上会一直挂着一条早就不存在的旧值。

二、查询与展示

指标进了库只是开始，查询语句（PromQL）决定这些数据能不能被问出答案：按标签下钻到某个命名空间、某个工作负载，是排障时最常做的动作。展示层用 Grafana 接 Prometheus，把集群、命名空间这类维度做成变量下拉，一个面板就能覆盖整层对象，比复制几十个面板好维护。

三、告警：规则与通知分开看

规则负责判断「什么算异常」，Alertmanager 负责「通知谁、怎么通知、通知几次」。路由按标签分层，团队和环境的边界就划在这里；一次故障引发的连锁告警用分组和抑制压下去，只留根因那条；计划维护用静默盖住，别靠人肉忽略。渠道可以接微信、QQ、钉钉，邮件作为兜底留痕。

每条故障规则都应该配一条对应的恢复通知，只发不恢复的告警时间一长就没人看了。

四、规模上来以后

• 联邦集群：多集群或节点数量大时，上层只拉下层的聚合结果，别让单个实例去抓全网。
• 异地备份：本地盘一坏就是全部历史，时序数据要留远端副本，规则和配置进版本库。
• 高可用：采集和告警都做多副本、配置一致，单副本挂掉的那段时间正好是最需要告警的时候。
• 抓取间隔和数据保留时长要一起定，标签基数大了会直接把内存顶穿，先收敛维度再谈扩容。