网站挂了，网站你可能是可用控种最后一个知道的人。这不是性监段子。去年有个做跨境电商的网站朋友，凌晨两点被客户电话吵醒，可用控种说网站打不开。性监他迷迷糊糊打开电脑，网站发现首页确实白屏了，可用控种而他的性监监控系统——准确地说，他根本没装监控——安静得像什么都没发生。网站那晚他损失了至少四十个订单。可用控种

所以问题来了：网站可用性监控到底选哪种？性监市面上的方案大概分三类，各有各的网站脾气。

第一类：Ping 和端口检测

最原始的可用控种那种。每隔几分钟 ping 一下服务器 IP，性监或者 telnet 一下 80 端口。通了就绿灯，不通就报警。听起来够用对吧？但坑在于，服务器活着不等于网站能用。我见过一台机器 ping 延迟 12ms，端口也开着，但 Nginx 配置出错，返回的全是 502。Ping 检测对此一无所知。它只关心“机器喘不喘气”，不关心“网站能不能看”。

适合谁？纯内网服务器、数据库节点这种不需要对外提供 HTTP 服务的场景。对外网站用这个，等于给大门装了把锁，但窗户全开着。

第二类：HTTP 状态码检测

比 ping 进了一步。发个 HTTP 请求，看返回是不是 200。如果不是，报警。大部分基础监控工具都支持，配置也简单。但这里有个陷阱：很多网站出错时依然返回 200。比如一个电商网站，商品详情页调接口失败，页面显示“暂无数据”，HTTP 状态码还是 200。监控看着一切正常，用户看到的却是空荡荡的页面。

我自己的博客就遇到过。WordPress 某个插件冲突，首页白屏，但状态码 200。监控没响，直到读者发邮件问我是不是关站了。那之后我学乖了，光看状态码不够。

第三类：内容与业务逻辑检测

这才是真正管用的。不光看状态码，还要检查页面里有没有关键内容。比如登录页有没有“用户名”输入框，商品页有没有“加入购物车”按钮，API 返回的 JSON 里有没有预期的字段。甚至可以模拟用户操作：填表单、点按钮、走一遍下单流程。

工具方面，UptimeRobot 免费版能做关键词检测，但频率最低 5 分钟。Pingdom 和 Better Uptime 更细，支持多步骤事务检测，价格也上去了。开源自建的，Uptime Kuma 这两年很火，Docker 一拉就能跑，支持 HTTP 关键词、TCP、Ping 多种模式，界面也清爽。我目前用 Uptime Kuma 监控三个站点，每 60 秒一次，关键词匹配，报警推到 Telegram。够用，不折腾。

选哪种，取决于你的网站值多少钱。个人博客，Ping 加状态码够了。电商、SaaS、任何靠网站吃饭的生意，必须上内容检测。别省那点钱，一次故障的损失够买好几年监控服务。

还有个细节：监控节点别只放一个地方。你从北京 ping 通，不代表广州用户能打开。Uptime Kuma 支持多个节点，或者用外部服务做分布式检测。另外，报警渠道别只依赖邮件，邮件延迟几分钟太正常了。短信、Telegram、Slack，哪个快用哪个。

最后说个反直觉的：监控太灵敏也是灾难。每次网络抖动都给你发警报，三天后你就麻木了，真出事时直接忽略。设置合理的重试次数和阈值，比如连续两次失败才报警。监控是工具，不是噪音制造机。