凌晨三点，网站手机突然震了一下。状态运维群里弹出一条消息：“官网打不开了。检测”我翻身下床，网站打开电脑，状态浏览器里那个熟悉的检测域名转了三圈，然后是网站一行白底黑字——502 Bad Gateway。这不是状态第一次了。上个月同一个时间点，检测数据库连接池满了，网站网站瘫了四十分钟。状态再往前推两周，检测CDN节点被攻击，网站静态资源全部加载失败。状态每一次都像半夜被人从被窝里拽出来，检测告诉你家里水管爆了。
网站状态检测这件事，很多人以为就是装个Uptime Robot，设个五分钟ping一次，收到邮件就完事。真这么干，你会在凌晨三点被叫醒，然后发现监控告诉你“网站正常”，可用户截图里明明是一片空白。问题出在检测的维度太单一。HTTP 200不代表页面能看，TCP握手成功不代表后端逻辑没崩。我见过一个电商站，首页返回200，但所有商品图片的URL都指向了一个已经下线的对象存储桶。监控没报警，因为首页HTML确实吐出来了。用户看到的是一排排灰色占位图。
后来我们改了策略。检测分三层：网络层、应用层、业务层。网络层用ICMP和TCP SYN，看机房和负载均衡是否活着。应用层用HTTP请求，但不止请求一个URL——首页、登录接口、搜索接口、支付回调，每个都单独设阈值。业务层最麻烦，得模拟真实用户行为。比如用无头浏览器打开首页，等JavaScript执行完，检查页面上有没有出现“加入购物车”按钮。没有？那就是前端资源挂了或者接口超时。这套东西跑起来之后，误报少了很多，但成本也上去了。一个小团队未必愿意养一套Selenium集群。
有个细节值得说。检测频率不是越高越好。我们试过10秒一次，结果监控服务器自己先扛不住，而且目标站点的WAF把我们当成了CC攻击，直接封IP。后来改成动态频率：正常时60秒一次，连续两次失败后切到10秒一次，恢复后再切回来。这样既不会漏掉短时故障，也不会把对方惹毛。另外，检测点要分散。只从公司内网发请求，等于没测。用户可能在广州、在成都、在纽约。我们用三个云厂商的轻量服务器做探针，分别放在华东、华南、美西。有一次华东节点全挂，但美西正常，说明是区域性问题，不是代码bug。
说个真事。去年双十一前，我们做全链路压测。监控显示一切正常，响应时间200毫秒以内。但压测结束后，有个同事随手点了一下“我的订单”页面，转了十秒才出来。查日志发现，订单查询接口在压测时走了缓存，压测一停，缓存过期，所有请求直接打到分库分表后的慢查询上。监控没覆盖这个场景，因为压测流量和真实流量走的路径不一样。从那以后，我们加了一条规则：任何新上线的接口，必须同时配置“空缓存”状态下的检测用例。
工具方面，Zabbix、Prometheus、Grafana这些都能用，但别指望开箱即用。我见过有人把Zabbix的默认模板往上一套，然后抱怨“怎么数据库挂了不报警”。默认模板只监控主机存活和CPU内存，数据库连接数、慢查询、主从延迟这些，得自己写脚本或者用现成的exporter。另一个坑是告警风暴。一次机房网络抖动，三百台机器同时报警，手机震了五分钟。后来我们做了告警收敛：同一机房、同一类型的故障，只发第一条，后续合并成一条摘要。人不是机器，会被吓到麻木的。
最后说个反直觉的观察。很多团队花大钱买商业监控，却忽略了一个最简单的检测手段：自己每天手动点几下。听起来很蠢，但自动化脚本不会发现“页面排版错乱”“按钮颜色不对”“文案有错别字”这类问题。我们内部有个轮值表，每天一个人花十分钟走一遍核心流程。上个月就是靠这个发现了一个CSS文件被误删，导致所有弹窗的关闭按钮跑到了屏幕外面。监控没报，因为HTTP状态码全是200。
网站状态检测不是装个软件就完事。它更像是一种习惯：你得知道用户实际在经历什么，而不是你以为服务器在做什么。凌晨三点的电话谁都不想接，但接多了，总能学会怎么让电话少响几次。