一个电商站在周末下午挂了四十分钟，第一个电话是客户打来的。老板问运维在干什么，运维说在看另一个报警。监控装了，但配得不对，等于没装。
监控要覆盖四个层面
最外层是可用性：首页能不能打开、响应多少毫秒。往里是接口：关键接口成功率、耗时。再往里是资源：CPU与内存以及磁盘跟带宽。最里面是业务：下单量、支付成功率。四层缺一层都会漏。业务监控最容易被忽略，也最有用。
网站能打开、接口能返回，但支付成功率从百分之九十五掉到百分之六十，这种问题只有业务监控能抓到。先小步试。技术指标全绿而业务已经出事，是常见情况。告警太多等于没有告警。见过的典型场景：一天三百条报警，运维全部静音，真出事时没人看。
告警要少而准
所以告警要分级：致命的第一时间打电话，重要的发消息，一般的进日报。阈值也别照抄模板。CPU超过百分之八十报警，对一台日常跑在七十五的机器就是天天响。合理做法是看历史基线，偏离基线一定程度才报。
这个方法叫动态阈值，实际效果好得多。报警说接口慢，慢在哪一段？是数据库查询、是第三方接口跟还是网络？没有链路追踪就只能猜。给关键请求打上链路标识，把每一段耗时记下来，定位时间能从小时级降到分钟级。
故障定位要有链路
值班要有手册。什么报警对应什么处理动作，写清楚。深夜被叫起来的人，脑子不清楚，靠手册比靠记忆靠谱。这份文档平时没人看，出事时救命。一句收尾：监控的目标不是记录故障，是让客户永远比你晚知道。数准不准？
网站监控的常见疑问
网站监控要监控什么
覆盖可用性跟接口和资源与业务四个层面，业务指标如支付成功率最容易被遗漏。
告警太吵怎么办
按严重程度分级推送，并用历史基线做动态阈值，避免固定阈值天天误报。
故障怎么快速定位
给关键请求加链路追踪，记录各段耗时，配合值班处理手册。
监控本身也要被监控。采集程序挂了、告警通道发不出去。都会造成"看起来一切正常"。设一个心跳：如果监控超过十分钟没上报，直接人工确认一次。
总结：监控的价值在提前发现。四层覆盖、告警分级跟链路可追，客户才不会比你先知道。