内容摘要：监控系统上线第一周，我就被报警邮件淹没了。凌晨三点，手机在床头柜上震个不停，爬起来一看，全是同一个错误：数据库连接池耗尽。可等我睡眼惺忪地打开电脑，服务已经自己缓过来了。这种“狼来了”式的报警，比没有

监控系统上线第一周，网站我就被报警邮件淹没了。监控凌晨三点，推荐手机在床头柜上震个不停，网站爬起来一看，监控全是推荐同一个错误：数据库连接池耗尽。可等我睡眼惺忪地打开电脑，网站服务已经自己缓过来了。监控这种“狼来了”式的推荐报警，比没有监控更可怕——团队开始习惯性忽略告警，网站真正的监控故障发生时，反而没人当回事。推荐

后来我把监控指标分成了三层。网站第一层是监控“用户能感知的”，比如页面打开速度、推荐下单成功率。第二层是“系统健康度”，CPU、内存、磁盘这些老生常谈。第三层才是“深层细节”，像是JVM的GC频率、数据库慢查询日志。大部分团队把精力全砸在第二层，结果服务器指标漂漂亮亮，用户那边早就卡成幻灯片了。我的判断是：宁可少监控十个内部指标，也要把首屏时间、接口错误率这些用户侧数据抓准。

报警阈值这东西，拍脑袋定必翻车。我们曾经给CPU使用率设了80%的告警线，结果每周五下午准时触发——因为定时任务在跑批量报表。真正的做法是花两周时间收集基线数据，观察正常波动范围，再往上浮动20%作为预警线。更关键的是区分“趋势告警”和“瞬时告警”。磁盘空间从70%涨到85%用了三天，这比五分钟内从10%飙到90%更值得警惕。前者是慢性病，后者是急性发作，处理优先级完全不一样。

有一回，网站半夜崩了，监控系统却一声不吭。查了半天，发现是健康检查接口写得太死板——它只检查服务进程活着没，没检查业务逻辑是否正常。进程在，但消息队列已经堵死了，所有请求都在超时边缘。从那天起，我把健康检查改成了“模拟真实用户请求”，直接调用核心业务接口，返回非200就立刻标记实例不可用。自欺欺人的监控不如不监控，你检查什么，就得到什么。

告警通知的推送方式也得讲究。微信群里喊“服务挂了”，跟发邮件说“CPU偏高”，能是一回事吗？我现在的规则很简单：P0级故障（用户完全无法访问）直接打电话给值班人，P1级（部分功能异常）发短信，P2级（性能轻微下降）推送到钉钉群。别把所有告警都往一个渠道塞，不然值班的人会疯掉。另外，同一类型的告警要设置“冷却时间”，比如五分钟内重复报警只推送一次，给处理留出窗口。

监控数据光看不存等于白干。我们吃过亏：一次诡异的内存泄漏，排查到一半，历史数据只保留了一天，连趋势图都画不出来。后来强制要求所有指标至少保留30天，关键业务数据存90天。出了问题，翻历史曲线找拐点，比瞎猜强十倍。

最后说点实在的——监控是给人用的工具，不是摆设。每周花半小时看看告警记录，哪些报了但没卵用，直接删掉；哪些该报却没报，赶紧补上。我见过最离谱的团队，监控面板上二十多个图表，能看懂的不超过三个。精简到五个核心指标，比堆砌五十个花哨图表有用得多。毕竟，监控的目的是让你睡个好觉，不是让你天天盯着屏幕焦虑。