考网站监控，网站很多人第一反应是监控背命令。ping、考试curl、网站traceroute，监控三件套往上一怼，考试觉得能通就行。网站真到线上出问题，监控这些全不够用。考试我见过一个运维，网站监控面板全绿，监控用户却打不开页面。考试查了两小时，网站发现是监控CDN节点回源超时，而他的考试监控只盯着源站IP的ICMP响应。

网站监控的本质不是“服务器活着”，而是“用户能正常用”。这两件事之间隔着DNS解析、TCP握手、TLS协商、HTTP响应、内容渲染。任何一层断掉，用户看到的就是白屏或报错。你的监控如果只覆盖其中一两层，等于闭着眼睛开车。

HTTP状态码会骗人

200不代表正常。我遇到过接口返回200，body里是{ "code":500,"msg":"db error"}。也见过页面200，但HTML里只有一行“系统维护中”。所以监控不能只看状态码，得校验内容。最简单的办法：检查响应体里是否包含某个关键词，比如“登录”或“商品列表”。没有就告警。这比看状态码靠谱得多。

还有重定向。302跳到登录页，对爬虫和监控来说都是200链路，但真实用户被踢出去了。监控脚本得跟随重定向，并且判断最终落地页是不是预期页面。如果跳到了/login，说明会话失效，这本身就是故障。

频率和位置决定监控质量

每分钟一次，从公司机房发请求——这种监控只能发现“机房到服务器”的链路问题。用户可能在北京、广州、成都，走的是不同运营商。你在杭州电信ping得通，不代表杭州移动能打开。更不代表纽约用户能打开。

我习惯用三个探测点：一个国内主力机房，一个海外VPS，一个移动4G网络下的树莓派。三个点同时告警才升级为P1，单点告警先观察。这样能过滤掉大量局部网络抖动，避免半夜被假警报叫醒。

频率也别太死板。核心支付接口可以10秒一次，静态博客页面5分钟一次就够了。全站统一30秒是懒人做法，浪费资源还容易触发风控。

告警要带上下文

“网站不可用”这种告警等于废话。有用的告警长这样：

[P1] 支付接口异常 时间：2025-03-21 14:32:07 探测点：上海电信 URL：https://api.example.com/pay 状态：连接超时（10s） 连续失败：3次 最近成功：14:31:37 

有了这些信息，值班的人不用登录监控平台就能判断：是单点网络问题，还是服务端挂了。如果三个探测点全超时，直接找后端。如果只有上海电信超时，先看是不是运营商故障。

别忽略证书和域名

SSL证书过期是经典事故。监控脚本里加一行openssl s_client -connect example.com:443 -servername example.com | openssl x509 -noout -dates，每天跑一次，到期前30天开始提醒。域名过期同理，whois查一下到期时间，加到日历里。

DNS解析也要监控。有时候域名没到期，但NS记录被误改，或者解析被污染。从不同探测点dig一下，对比返回的A记录是否一致。不一致就告警。

监控不是装完就完

我每季度会做一次“故障演练”：手动把源站停掉，看监控多久发现、告警是否准确、值班人是否知道怎么处理。上次演练发现，告警短信被运营商拦截了，因为内容里有“故障”两个字。改成“服务波动”就正常了。这种坑，不演练根本不知道。

网站监控考试，考的不是工具用得多熟，而是你有没有把用户路径拆解清楚。从输入域名到看到内容，中间每一步都可能断。你的监控覆盖了几步，就决定了你能多快发现故障。剩下的，靠演练和复盘慢慢补。