网站监控程序

凌晨三点，网站手机震了一下。监控我迷迷糊糊摸过来看，程序是网站一条告警短信：某客户的生产环境站点返回 502。那一刻我彻底清醒了——如果没有这套监控程序，监控这个故障可能要等到早上九点用户投诉才会被发现，程序而中间六个小时的网站订单损失，没人能估得准。监控

很多人以为网站监控就是程序装个 UptimeRobot，每隔五分钟 ping 一下，网站挂了发邮件。监控这想法太天真。程序真实的网站监控程序要解决三个层次的问题：站点是不是活着、响应是监控不是正常、业务逻辑是程序不是跑通了。第一层最简单，HTTP 状态码 200 就算过。第二层要看响应时间、TLS 证书有效期、DNS 解析是否漂移。第三层最麻烦——比如一个电商网站，首页能打开，但下单接口返回 500，普通探针根本发现不了。我见过一个案例，某 SaaS 产品的登录页正常，但用户提交表单后一直转圈，原因是后端某个队列消费者挂了。监控程序只盯着首页，整整两天没人知道。

那监控程序到底怎么写？核心就三件事：定时器、探测器、通知器。定时器负责按周期触发任务，cron 或者 Go 的 ticker 都行。探测器是真正干活的部分，发起 HTTP 请求，记录状态码、耗时、响应体大小，有时候还要校验返回的 JSON 里某个字段是不是预期值。通知器负责把异常推出去，邮件、短信、Slack、钉钉，看团队习惯。我自己的做法是，探测器返回一个结构体，包含 status、latency_ms、error_msg，然后交给通知器判断——连续三次失败才告警，单次抖动忽略，避免半夜被误报吵醒。

有个细节容易被忽略：监控程序自己也会挂。我早期写过一个 Python 脚本，跑在客户的一台旧服务器上，结果那台机器磁盘满了，监控进程被 OOM 杀掉，而没人监控监控程序。后来我改成双节点互检，A 节点监控 B 节点的心跳，B 节点监控 A，任何一方失联超过两分钟，直接打电话。听起来有点过度设计，但生产环境里，监控系统的可靠性必须高于被监控对象，否则就是盲人骑瞎马。

再说说告警疲劳。刚入行时我设了特别敏感的阈值，响应时间超过 500ms 就发通知，结果一天收几十条，后来全组人都把告警邮件设了过滤规则，真出事反而没人看。现在我的策略是分层：P0 故障（站点不可访问）立刻电话；P1（响应超时、证书过期前七天）走即时通讯；P2（性能下降趋势）每天汇总一封日报。这样既不会漏掉关键问题，也不至于把团队逼疯。

如果你打算自己写一个，我建议从最简单的 shell 脚本开始：curl -o /dev/null -s -w "%{ http_code} %{ time_total}" https://example.com，配合 crontab 每两分钟跑一次，状态码不是 200 就调个 webhook。别一上来就上 Prometheus + Grafana + Alertmanager 全家桶，那套东西运维成本不低，小团队容易把自己玩进去。等站点数量超过二十个，或者需要监控业务指标了，再考虑换重型工具也不迟。

监控程序的价值不在于技术多先进，而在于它能不能在用户之前发现问题。凌晨三点那条短信，虽然吵醒了我，但让我在十分钟内恢复了服务。这十分钟，比任何架构图都实在。