内容摘要：凌晨两点，服务器返回 502 的次数突然从个位数跳到 47。值班同事被电话叫醒时，用户已经在微博上骂了十分钟。这种事发生过一次，你就不会再相信“机器跑得好好的，不用盯着”这种话。网站监控不是装个 up

凌晨两点，网站服务器返回 502 的监控次数突然从个位数跳到 47。值班同事被电话叫醒时，设计用户已经在微博上骂了十分钟。网站这种事发生过一次，监控你就不会再相信“机器跑得好好的设计，不用盯着”这种话。网站网站监控不是监控装个 uptime 机器人就完事，它得能回答三个问题：挂了没有、设计哪里挂了、网站为什么挂。监控

先说最基础的设计存活检测。很多团队用 Pingdom 或 UptimeRobot，网站每 1 分钟发一次 HTTP 请求，监控状态码非 200 就告警。设计这招便宜、好用，但有个坑：它只测一个 URL。首页返回 200，不代表下单接口没崩。我见过一个电商站，首页静态缓存好好的，支付回调接口已经连续超时 20 分钟，监控面板一片绿。后来他们在关键路径上加了 7 个探测点——登录、搜索、加购、下单、支付回调、订单查询、退款。每个点独立告警。这才叫覆盖。

探测频率也得看场景。静态博客 5 分钟一次足够。金融交易类接口，10 秒一次不算过分。但别盲目调高频率，否则你的监控服务本身就成了 DDoS 源。有个折中方案：核心接口 15 秒，边缘接口 60 秒，再配一个“连续失败 3 次才告警”的抑制规则。否则网络抖动一下，整个运维群被炸醒。

光看“通不通”太粗糙。延迟、TLS 握手时间、DNS 解析耗时、首字节时间，这些指标才能定位问题。去年帮一个客户排查，监控显示接口可用，但平均响应从 180ms 涨到 2.3s。查下来是数据库连接池被打满，慢查询堆积。如果只盯状态码，这问题能拖到用户流失才被发现。所以监控项里至少要有：响应时间 P95、错误率、吞吐量。这三个指标放一起，基本能画出系统健康度的轮廓。

日志和指标要分开处理。指标适合看趋势，日志适合查根因。Prometheus 抓指标，Loki 或 ELK 收日志，两边通过 trace ID 关联。用户反馈“支付失败”，你先看错误率面板，发现 14:03 到 14:07 有个尖峰。点进去看日志，全是“connection reset by peer”。再查那个时间段的部署记录——刚好有个服务在滚动重启。链路就通了。

告警渠道别只发邮件。邮件在凌晨没人看。Telegram 机器人、钉钉 webhook、PagerDuty 轮询电话，按严重级别分层。P0 直接打电话，P1 发群消息，P2 进工单系统。有个反直觉的经验：告警太多等于没有告警。每周花 20 分钟清理误报规则，比加新监控项更重要。

最后提一句自建 vs SaaS。小团队直接用 SaaS，省心。但如果你有合规要求，或者需要监控内网服务，自建 Prometheus + Grafana + Alertmanager 是标准答案。成本不高，一台 2C4G 的机器能扛住几十个探测目标。关键是数据在自己手里，想怎么查就怎么查。

监控方案没有银弹。从三个探测点开始，跑一周，看哪些告警是噪音，哪些故障没被抓住。迭代两三轮，基本就贴合你的业务了。别追求大而全，先保证核心链路 100% 覆盖。