我曾经天真地以为，监控系统越全面越好。监控指标越多，就能越早发现问题。

直到有一次，我发现我的服务频繁超时，原因竟然不是业务代码，而是 Prometheus 在疯狂抓取指标。

是的，你没看错——我的监控把我自己监控挂了。

监控是有代价的，而且不便宜

很多人觉得监控是“零成本”的。搭一套 Prometheus + Grafana，放几个 exporter，心里美滋滋觉得线上情况尽在掌握。

但监控系统的资源消耗，有时候超乎你的想象。

先说数据采集。每一个指标的采集都需要：CPU时间去执行查询，内存去存储结果，网络带宽去传输数据，磁盘IO去写入时序数据库。如果你采集了几千个指标，每秒采集一次，那这个开销就不是“忽略不计”了。

我见过一个项目，跑了200多个 exporter，每个 exporter 每15秒采集一次数据。结果呢？采集端占用了8%的CPU，存储端每天生成200GB的数据量。光存储费用一个月就好几万。

更可怕的是，当监控数据量大了之后，查询监控面板本身就成了性能瓶颈。想看一下某个接口的QPS，结果 Dashboard 加载要十几秒。这不是本末倒置吗？

报警疲劳症——你的团队正在被监控pua

我见过最离谱的一个团队，一天能收到几百条报警。CPU报警、内存报警、磁盘报警、接口延迟报警、错误率报警……运维同事每天不是在处理报警，就是在处理报警的路上。

结果呢？当真正的严重故障来临时，大家的第一反应是——“又是哪个监控报警了？”

这就是报警疲劳。当报警太多、太频繁、太不准之后，人就会自动进入“忽略模式”。重要的报警和垃圾报警混在一起，真正的问题反而被淹没了。

报警多的原因通常有两个：阈值设置不合理，以及缺少报警分级。

阈值的问题很多人意识不到。我见过一个团队，所有服务的CPU报警阈值都设的80%。问题是，有些服务正常情况下CPU就是会飙到90%，而有些服务CPU才50%就已经出问题了。一刀切的阈值，不是报警不足就是虚惊一场。

报警分级更是没人做。P0故障报警、P1问题要响应、P2优化可以缓——这种分级大部分团队都没有，或者有也不执行。最后所有报警都变成了最高优先级，等于没有优先级。

虚假的安全感——你在看仪表盘，但没在看路

我见过很多人，花了大把时间搭监控、做仪表盘、设报警。结果呢？出了故障还是从用户反馈知道的，不是从监控看到的。

问题出在哪？

很多团队的监控是“技术导向”而不是“业务导向”的。CPU、内存、磁盘、网络——这些都是机器层面的指标。你的老板真正关心的是什么？是“有多少用户成功下单了”。

如果你没有监控“下单成功率”这个业务指标，那你其实不知道你的系统是否正常。

还有一个常见的误区：只监控自己写的代码，不监控依赖的组件。你的服务OK，但MySQL慢了你不知道；你的服务OK，但Redis快爆了你不知道。系统是链性的，任何一个环节出问题都会影响最终用户体验。

那些年我踩过的监控坑

说几个我自己的真实经历。

有一次，报警说MySQL主从延迟了。我赶紧去查，看到Seconds_Behind_Master 是0——等等，那延迟告警是怎么触发的？看了半天发现，是监控采集脚本本身有问题，把0误当成了异常值。这种“报警本身就是bug”的坑，我踩过不止一次。

还有一次，线上出了故障，我去看监控面板想定位问题。结果监控面板本身加载了快一分钟，出来的图还是错的——时区设置有问题，凌晨3点的数据标成了下午3点。在最紧急的时候，监控系统给我挖了一个大坑。

最离谱的一次，是某次大促前我加了一堆监控指标，想“全面掌握系统状态”。结果大促当天，这些指标在 Grafana 里叠在一起，乱得根本看不清。监控是加了的，但加的方式不对等于没加。

怎么让监控真正有用？

说了这么多坑，说说我觉得正确的做法。

第一，监控要分层。基础设施层（CPU、内存、磁盘）、中间件层（数据库、缓存、队列）、应用层（接口QPS、延迟、错误率）、业务层（下单量、支付成功率）。每层都要有，但每层的关注点不一样。不要眉毛胡子一把抓。

第二，报警要克制。我建议一个服务的核心报警不超过5条。多了就精简，精简不了的就要考虑“报警收敛”——把同类报警聚合在一起，避免轰炸。PagerDuty 或者其他平台的报警聚合功能，用起来。

第三，仪表盘要“救火模式”优先。设计仪表盘的时候，想象一个场景：凌晨三点你在被窝里被叫醒，你打开这个Dashboard，30秒内你要能判断——问题大不大？问题在哪？要不要继续排查？做不到这一点的仪表盘都是失败的。

第四，监控数据也要治理。不是所有指标都有用，有些指标从上线那天起就没人看过。定期清理无用的指标和仪表盘，给监控“减肥”。

第五，有条件的话，给核心业务指标设置“端到端监控”。不是监控你的服务能返回200，而是监控用户的操作能成功走完整个链路。用 Synthetic Monitoring 或者 Real User Monitoring 都可以，关键是别只监控自己能看到的，要监控用户能感知的。

写在最后

监控不是万能的，但没有监控是万万不能的。问题是——大部分团队的监控，是在“假装努力”。

搭了一堆系统，设了一堆阈值，但报警该来的不来，不该来的一大堆。仪表盘做得很漂亮，但出了事还是靠经验、靠日志、靠用户反馈。

监控系统应该是你线上安全的最后一道防线，而不是一个“看起来很专业”的装饰品。

下次你加监控指标的时候，问问自己：这条报警来了，我知道该干什么吗？如果答案是否定的，那这个指标加了也是白加，说不定还会分散你的注意力。

记住：最好的监控，是让你感觉不到它存在的监控。当你要去查监控的时候，说明监控已经没拦住问题了。