获课：xingkeit.top/18078/

生产环境监控误区：Prometheus监控系统实战复盘

一、监控建好了，故障来了还是抓瞎

很多团队花大力气部署了Prometheus，Node Exporter装了、Grafana看板搭了、告警规则配了，看起来该有的都有了。结果线上真出故障时，告警倒是响了，但运维打开监控一看——CPU正常、内存正常、磁盘也正常，折腾半小时才从一个角落的日志里发现是数据库连接池耗尽了。

问题不在监控系统本身，而在于从一开始就走错了方向：采了一堆资源指标，却没采真正能反映业务健康度的指标。百度在监控发展史里讲过一句大实话：资源类指标很难反映业务真实状态，机器CPU异常时业务可能已经自行容灾了，而业务早就异常了资源指标却毫无变化-10。

二、误区一：把“能采”当“够用”，该采的指标没采

一次故障复盘，开发问：“当时数据库的慢查询数量是多少？”运维翻遍监控，没有，因为只监控了CPU和连接数，没采慢查询。又问：“磁盘IO延迟呢？”也没有，因为默认只采了容量，没采延迟-5。

这就是典型的“该采的没采”。只采基础指标（CPU、内存、磁盘容量），不采深度指标（IO延迟、锁等待、连接池状态），故障时只能看到结果，看不到原因。一位运维负责人复盘时感慨：每天采集上亿条指标，硬盘买了十几块，可每次出故障，还是找不到原因-5。

三、误区二：告警阈值靠“拍脑袋”，搞出告警疲劳

很多团队初次配置告警时，直接用了默认规则——CPU高于80%就告警。结果晚高峰期间，运维群半小时收到50多条告警，没人当回事。告警疲劳的终极结果是：没有告警-4。

真正有效的阈值不是拍脑袋定的，而是靠基线算出来的。先用7天数据做基线校准，看历史同时间段的正常范围。如果每天10点到11点都有固定高峰，告警规则应该看“是否超过历史同时间段2倍”，而不是只看瞬时百分比-1。阈值还必须带持续时间，否则一次备份任务或短时爬虫流量就能制造大量噪音。

四、误区三：数据质量没人管，采集链路不稳定就冲上去搭大盘

监控数据“价值休眠”的根源在于数据治理缺失-5。不同采集器的时间戳没同步，谁先谁后分不清；同一个指标在不同系统里叫法各异——“CPU使用率”“CPU利用率”“cpu_util”，系统根本无法关联分析；采集频率不统一，时序数据无法精确对齐。

这些问题不是“等上线后再优化”能解决的。配置变更后，先用promtool检查语法，再重载Prometheus，确认up指标稳定为1、关键指标都能返回数据，再往前走-1。采集链路都没跑稳就冲上去搭大盘、配告警，后面全是隐患。

五、误区四：只有Prometheus不够，可观测性靠的是“铁三角”

Prometheus提供的是监控指标（Metrics），但这只是可观测性的一部分。没有链路追踪和日志关联，出了故障你只能看到“哪里高了”，看不到“为什么高了”。

一个真实案例：12个微服务日均请求5000万+的系统，出故障时故障发现花30分钟（靠用户投诉），定位花32分钟（翻遍6台服务器的分散日志），根因确认又花了58分钟，总计将近2小时才搞定-4。引入全链路可观测体系后，故障发现缩到30秒，定位缩到5分钟-4。

指标告诉你“有问题”，链路告诉你“问题在哪条路径上”，日志告诉你“问题具体是什么” ——三者结合，才算真正的可观测性。

六、回头看的教训：别把Prometheus当“终点”

复盘多个生产监控项目，最大的教训就一句：Prometheus是工具，不是解决方案。它能不能发挥作用，取决于你用它采什么指标、怎么采、怎么管、怎么跟其他可观测性工具配合。

下次再有人说“监控已经搭好了”，先问三个问题：业务黄金指标（请求量、错误率、响应时间）采了吗？告警阈值是基于历史数据算的还是拍脑袋定的？出故障时能从监控直接定位到根因吗？这三个问题答不上来，监控就是摆设。