凌晨三点，网站手机突然震了。监控我眯着眼看，处理监控群里一条告警：某电商站点首页返回502，网站持续两分钟。监控值班同事已经截图，处理curl结果、网站Nginx错误日志片段一并发了出来。监控这就是处理网站监控最真实的场景——不是看仪表盘有多漂亮，而是网站出事那几分钟里，你手里有没有能用的监控信息。

很多人把监控等同于“装个UptimeRobot”。处理能通就行？网站差得远。HTTP 200不代表页面正常。监控我见过一个站点，处理状态码200，但返回的是“系统维护中”的静态页，内容长度只有正常页面的十分之一。如果只盯状态码，这种故障能瞒你半天。所以监控至少要分三层：网络层（能不能连）、应用层（返回内容对不对）、业务层（关键流程走不走得通）。

ping通了，用户却打不开

有个做跨境电商的朋友，服务器ping延迟稳定在30ms，但客户投诉页面加载要十几秒。查下来是某个第三方JS文件卡住了渲染。ping和TCP检查完全发现不了。后来他在监控里加了“页面完全加载时间”和“关键元素出现时间”，才抓住真凶。这类问题用curl测首字节时间也不够，得用无头浏览器跑真实渲染。Puppeteer或Playwright写个脚本，每五分钟跑一次，记录DOMContentLoaded和load事件耗时，超阈值就告警。成本不高，但能兜住很多“假正常”。

告警不是越多越好

刚入行时我配了一堆规则，CPU超80%告警、内存超90%告警、磁盘超85%告警。结果每天收几十条，后来全设成免打扰，真出事反而没看见。监控告警的核心是信噪比。CPU飙到90%但请求响应正常，那可能是定时任务在跑，不用半夜叫人。真正该立刻响的，是“用户侧可用性下降”——比如一分钟内错误率超过5%，或者首页连续两次检测失败。

我现在的习惯是分两级：P0告警直接打电话，只留给核心页面不可用和支付链路异常；P1发企业微信，比如单台服务器负载高、磁盘增长快，上班再处理。每个告警必须附带“可能原因”和“排查入口”。比如“首页502”后面直接跟Nginx错误日志的最近20行，值班的人不用登录机器就能判断是后端挂了还是配置错了。

日志和指标要对着看

指标告诉你“出事了”，日志告诉你“为什么”。有次监控显示某API平均响应时间从200ms涨到2s，看指标毫无头绪。翻日志发现是某个新上线的查询没走索引，全表扫描。如果只看监控图，你只会看到一条曲线翘起来，原因得去日志里挖。反过来，日志里偶尔报错但指标正常，那可能是被重试机制吞掉了，不用太紧张。两者结合，判断才准。

日志收集别用grep硬扛。站点一多，几台机器同时刷日志，你根本来不及。轻量点用Loki加Promtail，配合Grafana看；重一点上ELK。关键是要能按请求ID串起来。用户报错时给他一个trace ID，你从Nginx到应用层到数据库一把查完，比来回问“你几点操作的”高效得多。

别忽略“慢”和“错”之外的东西

证书过期、域名解析被改、CDN回源异常——这些不常发生，一发生就是全站级故障。我习惯在监控里加两条：SSL证书剩余天数少于14天告警；DNS解析结果与预期IP比对，不一致就报。还有内容篡改监控，比如首页被挂马，返回内容里出现可疑iframe，这种用关键词匹配就能发现。花不了多少时间，但能避免大事故。

监控不是装完就完事。业务在变，页面在改，告警规则也得跟着调。每季度花半小时过一遍所有规则，把误报多的删掉，把新上线的关键路径加进去。别让监控系统变成“狼来了”的小孩。真出事那一刻，你需要的是一条准确的告警，而不是一百条噪音里翻找线索。