网站在线检测

凌晨三点，网站我盯着屏幕上的线检502错误码，咖啡杯沿凝着褐色渍痕。网站这不是线检第一次了——上周刚上线的电商站，每到深夜流量高峰就崩。网站技术群里有人建议用第三方监控，线检我试了三天，网站短信轰炸倒是线检准时，可每次收到告警，网站故障已经发生至少十分钟。线检

后来我换了思路，网站自己写了个检测脚本。线检每两分钟发一次HTTP请求，网站记录响应时间、线检状态码、网站DNS解析耗时。第一周跑下来，数据让我后背发凉：看似稳定的站点，其实有三次响应超过5秒，两次返回了不完整的HTML。用户不会告诉你页面卡了，他们只会默默关掉标签页。

线上监控工具不少，UptimeRobot、Pingdom、StatusCake，界面一个比一个漂亮。但真正用起来，你会发现问题不在“检测”本身，而在“告警”的粒度。凌晨的告警邮件没人看，白天又容易被工作群消息淹没。我现在的做法是分级通知：响应超时只记日志，连续三次失败才推微信，彻底宕机才打电话。阈值得慢慢调，调得太灵敏，你会被自己折腾死；调得太松，监控就成摆设。

有个细节很多人忽略——检测节点位置。用阿里云的服务器监控放在美国的站点，延迟天然就高，误报率能到三成。我在东京、法兰克福、弗吉尼亚各放了一个轻量节点，才大致摸清真实用户的地域体验。最意外的是，故障居然经常出在证书续期上。Let's Encrypt的证书有效期90天，自动续期脚本偶尔失灵，服务就悄悄挂了。这种问题，第三方监控根本不会告诉你原因，只给你一个冰冷的红色感叹号。

现在我的监控面板上，除了常规指标，还加了“首字节时间”和“资源加载失败率”。前者能看出后端逻辑是否臃肿，后者能暴露CDN节点问题。上周某个图片资源在部分省份加载失败，就是因为源站某个目录权限被误改。这种边缘情况，靠用户投诉发现就晚了。

说到底，在线检测不是装个插件就完事。它得跟你的业务逻辑绑定——电商站关注下单接口的可用性，内容站盯着文章页的渲染速度，BBS要看发帖接口的稳定性。我见过有人对静态首页做秒级监控，结果动态接口早就挂了三天。那不是检测，是心理安慰。

今早看数据，过去30天里，我的脚本共发出21600次请求，捕获了7次异常，其中4次是第三方API超时，2次是数据库连接池耗尽，1次是机房网络抖动。没有一次是用户先发现的。这大概就是检测存在的意义——把那些“差点发生”的事故，变成日志里几行安静的记录。