网站监控

凌晨三点十七分，网站监控手机震了一下。网站监控我翻了个身没理它，网站监控过了五分钟又震了一下。网站监控爬起来一看，网站监控是网站监控运维群里自动告警——公司主站返回502，连续三次探测失败。网站监控从床上弹起来打开电脑，网站监控前后不过四分钟，网站监控但客户投诉邮件已经进来了两封。网站监控

这就是网站监控网站监控最真实的场景。它不会在你喝着咖啡刷着报表的网站监控时候出事，偏偏挑你睡得最沉的网站监控时候给你一闷棍。

监控到底在盯什么

很多人以为装个UptimeRobot，网站监控每隔五分钟ping一下服务器就算完事。网站监控这跟拿体温计判断一个人健不健康差不多——不发烧不代表没病。

我现在的做法是分三层看。最外层是可用性，就是网站能不能打开，HTTP状态码是不是200。这层最简单，工具也最多，但最容易骗人。CDN缓存了一个静态页面，探测节点拿到的永远是200，可后端数据库已经挂了三分钟了。所以第二层必须看关键接口的响应内容，不能只看状态码。比如登录接口，你得模拟真实请求，验证返回的JSON里有没有token字段。

第三层最容易被忽略——性能基线。页面能打开，但加载时间从800毫秒变成了4秒，用户已经在骂娘了，你的监控面板还是一片绿。我给每个核心页面设了响应时间阈值，超过基线50%就触发预警，不等它彻底挂掉。

告警疲劳比漏报更可怕

去年有段时间，我们监控系统每天发两百多条告警。磁盘使用率超过80%也报，某个冷门接口偶尔超时也报。结果呢？所有人把告警群设成了免打扰。真正出事那次，消息发出去四十分钟没人看。

后来我做了一件事：把所有告警按影响面分级。P0是主站不可用或核心交易链路中断，电话直接打到值班人手机上。P1是部分功能降级，发企业微信。P2是趋势性指标异常，每天汇总一次邮件。规则砍掉了一半，告警量降到每天十几条，反而没人漏看了。

阈值也别设太死。磁盘80%报警？如果这台机器每天增长0.1%，那还有两百天才满，急什么。换成“预计24小时内写满”才值得半夜叫人。

那些监控覆盖不到的地方

工具能告诉你服务器CPU飙到95%，但告诉不了你用户在支付页面反复点击提交按钮是因为按钮文案写得太模糊。工具能发现接口返回了500错误，但发现不了返回的是200、内容却是“系统繁忙请稍后再试”。

我养成了一个习惯：每周花二十分钟看客服工单和用户反馈，把高频问题反向映射到监控规则里。上个月有用户抱怨“搜索功能时好时坏”，查了半天发现是搜索接口在结果为空时返回了200但响应体格式变了，前端解析失败。监控没报，因为状态码正常。补了一条JSON schema校验规则，问题再没出现过。

监控的终点不是 dashboard 上那片绿色，是用户打开页面时不用皱眉。工具是死的，人是活的。别让告警群变成狼来了的故事，也别指望一套默认模板能覆盖你所有的业务场景。凌晨三点那个电话该不该打，取决于你对“坏掉”的定义有多认真。