凌晨两点十七分，检测监控我盯着屏幕上的网站curl输出，第十三次按下回车。正常那个破网站还是打开打不开。不是检测监控网络问题，不是网站DNS问题，不是正常服务器宕机——它只是偶尔抽风，像一台年久失修的打开洗衣机，转着转着就停，检测监控你踹一脚又好了。网站

这就是正常最头疼的监控场景。一个网站，打开白天访问量上千，检测监控晚上偶尔超时，网站用户不会半夜来投诉，正常但第二天早上九点，老板会拿着手机问你：“昨天夜里是不是挂了？”你没法回答“好像是”，因为监控系统显示一切正常——它只在完全连不上时才报警，而“连不上”和“响应慢”之间，隔着整整一片灰色地带。

我试过各种方案。最简单的，每分钟发一次HTTP请求，状态码200就算活。可有些网站返回200但页面是空的，有些返回302跳转到登录页，还有的用JavaScript渲染内容，curl根本看不到真实状态。更麻烦的是，有些服务器对监控IP有偏见，你频繁请求，它直接把你拉黑。

后来我学乖了。监控不能只盯“能不能打开”，得盯“打开得对不对”。我写了个脚本，模拟真实用户行为：带上浏览器User-Agent，接受压缩编码，跟随重定向，甚至执行一段简单的JS来验证页面关键元素是否存在。比如那个电商网站，首页必须有搜索框和购物车图标，缺了任何一个，哪怕HTTP状态码是200，也判定为故障。

判断标准也不能一刀切。有一次，某个页面正常加载耗时2.8秒，监控阈值设在3秒，结果连续三天半夜报警。我爬起来看日志，发现是数据库连接池在凌晨有缓存刷新任务，导致偶发慢查询。这算故障吗？对真实用户来说，2.8秒和3秒的差别根本感知不到，但监控系统不懂这些，它只会机械地执行规则。

所以我把监控分成了两层。第一层是硬指标：TCP连接是否建立、TLS握手是否完成、HTTP状态码是否在预期范围内。这一层挂了，说明网站真的瘫了，该打电话叫醒运维。第二层是软指标：页面加载时间、关键元素是否渲染、API响应延迟。这一层异常，只发通知，不触发报警——因为可能是网络抖动，也可能是CDN节点临时抽风，让子弹飞一会儿再判断。

还有个细节容易忽略：监控节点本身的位置。你在一台服务器上部署监控，它访问的是公网IP，但用户可能通过运营商缓存、CDN边缘节点或者内网DNS解析访问。我见过一个案例，监控显示网站秒开，但某个省份的用户投诉打不开，最后发现是该省的运营商DNS解析到了过期的IP地址。监控节点不在那个区域，永远发现不了这种问题。

所以现在我的做法是，至少部署三个不同地理位置的监控点，用不同的网络运营商——电信、联通、移动各一个。加上一个海外节点，用来检测全球可达性。每个节点独立记录数据，交叉比对。如果只有一个节点报故障，先怀疑是监控点自己的网络问题；如果两个以上节点同时报，那基本可以确认是网站本身出了状况。

这活儿干久了，你会对“正常”两个字产生怀疑。网站不是非黑即白的，它是一堆概率事件的集合。99.9%的可用性听起来很高，但换算下来，一年有将近九个小时不可用。而这九个小时可能分散在凌晨、周末、节假日，你根本察觉不到。监控的意义不在于告诉你网站挂了没，而在于让你知道——它什么时候在悬崖边上晃悠，还没掉下去。

最后说个真实笑话。我朋友的公司用第三方监控服务，每个月花几百块，界面做得花里胡哨，各种仪表盘。结果有一次网站真的挂了，监控平台发来报警邮件，邮件里写着“检测到您的网站无法访问，请检查服务器”。他一看时间，报警比故障发生晚了四十分钟。后来查原因，是监控服务商自己的探针出了问题。你看，监控系统本身，也需要被监控。