网站监控代码

去年秋天，网站一个做跨境电商的监控朋友半夜给我打电话，说网站挂了三个小时，代码损失够买一辆Model 3。网站我问他怎么发现的监控，他说是代码客户发邮件骂过来的。这年头，网站靠人肉盯网站跟用蜡烛照明差不多——不是监控不行，是代码没必要。

网站监控代码本质上就是网站一段自动巡检脚本。它每隔几十秒或几分钟去访问你的监控页面，像一只不知疲倦的代码看门狗。但很多人以为监控就是网站判断“能不能打开”，这想法太粗糙了。监控HTTP 200不代表页面正常，代码可能返回的是一张写着“数据库连接失败”的图片；加载速度快也不代表没问题，也许支付按钮的JavaScript早就报错了。

真正有用的监控代码至少要盯三层东西。第一层是网络层——DNS解析时间、TCP连接耗时、TLS握手是否成功。第二层是应用层——HTTP状态码、响应体里有没有关键内容（比如“加入购物车”这个按钮的HTML标签是否还在）、API接口返回的JSON里error字段是不是null。第三层是业务层，这层最容易被忽略，也最要命。比如你监控一个电商网站，光看首页返回200没用，得模拟真实用户走一遍：打开商品页、点击购买、检查库存接口是否返回了正常数据。我见过一个案例，网站首页和商品页都正常，但提交订单的接口因为一个证书过期静默失败了三天，监控系统一直显示绿色。

写监控代码不需要多复杂的框架。一个简单的Python脚本加requests库就能起步。关键在“断言”怎么写。别只写 if response.status_code == 200，那等于没写。要写 if "库存不足" not in response.text and response.json()["stock"] > 0 这类具体判断。更省事的做法是用现成工具，比如Uptime Kuma、Prometheus的Blackbox Exporter，或者商业的Datadog Synthetics。但工具越省事，你越容易忘记监控的本质——它是在替你回答一个问题：“用户现在能正常用吗？”

还有个坑：监控节点放哪儿。你用一台北京的服务器去监控一个只面向广州电信用户的站点，数据参考价值有限。最好在多个地域部署轻量探针，或者直接用第三方全球节点服务。另外，监控频率别太贪心。每10秒一次对小型站点就是DDoS。通常生产环境用1分钟间隔，关键支付链路可以到20秒。

告警策略比监控本身更容易搞砸。我见过一个团队，监控代码每5分钟发一封邮件，结果所有人把告警规则设成了“直接进垃圾箱”。好的做法是分级：连续3次失败才告警，不同严重级别走不同通道——Slack通知值班群，PagerDuty打电话给on-call。还有，别只告警“网站挂了”，要带上具体信息：哪个URL、什么错误、返回内容的前200个字符。半夜被叫醒的人没心情去翻日志。

最后说个反直觉的经验。监控代码本身也会挂。你的监控脚本依赖的第三方库升级了、证书过期了、或者探针服务器磁盘满了——这时候你收到的不是“网站正常”，而是“监控失联”。所以记得给监控系统本身加个心跳检测。一个简单办法：让监控脚本每跑完一次就往一个公共的healthcheck服务发个ping，如果那个服务超过10分钟没收到ping，就给你发短信。这招救过我两次。

网站监控不是装个软件就完事。它更像给网站做心电图，导联贴对位置、阈值设合理、报警别太吵，才能在你真正需要的时候，准确告诉你：心脏还在跳，还是已经室颤了。