凌晨三点，网站手机响了。可用控样值班同事说官网打不开。性监我爬起来打开电脑，容易curl了一下首页，网站返回502。可用控样再查后端服务，性监进程还在，容易但连接池满了。网站这就是可用控样网站可用性监控存在的意义——不是等用户投诉才知道挂了，而是性监自己先发现。

很多人觉得搞监控很麻烦，容易要装一堆东西，网站配各种规则。可用控样其实真没那么复杂。性监你只需要回答两个问题：网站能不能访问？访问速度正不正常？围绕这两个问题，方案可以非常轻量。

最土但最有效的办法：定时curl

我最早做监控的时候，就是写了个shell脚本，每隔一分钟curl一次首页，检查HTTP状态码。返回200就过，非200就发邮件。脚本长这样：

#!/bin/bash URL="https://example.com" STATUS=$(curl -o /dev/null -s -w "%{ http_code}" --max-time 10 "$URL") if [ "$STATUS" != "200" ]; then echo "网站异常，状态码: $STATUS" | mail -s "告警" admin@example.com fi

丢进crontab，一分钟跑一次。这玩意儿简陋到什么程度？连依赖库都不用装。但它能覆盖80%的场景。服务器宕机、Nginx挂了、后端502、域名解析出问题——都能抓到。

缺点也明显。只检查状态码不够，有时候页面返回200但内容是错的。比如数据库连接失败，前端渲染了一个空白页，状态码照样是200。后来我加了一步，检查页面里有没有某个关键词，比如<title>公司名</title>。没有就告警。这样准确率高了不少。

用现成工具，别重复造轮子

自己写脚本适合练手，但生产环境还是用成熟工具省心。Uptime Kuma是我最近用得比较多的一个开源方案。Docker一行命令跑起来，Web界面配一下监控项，支持HTTP、TCP、Ping、关键词检测。告警渠道也全，邮件、钉钉、企业微信、Telegram都能接。

部署命令就一句：

docker run -d --restart=always -p 3001:3001 -v uptime-kuma:/app/data --name uptime-kuma louislam/uptime-kuma:1

跑起来之后访问3001端口，添加监控项。我一般会配三个：首页、API健康检查接口、登录页面。间隔设60秒，重试3次再告警，避免网络抖动误报。状态页还能公开给团队看，谁都不用问“网站是不是挂了”。

商业方案里，UptimeRobot免费版够用，50个监控项，5分钟检查间隔。缺点是节点在国外，国内访问速度检测不太准。国内的话，阿里云监控和腾讯云监控都有站点监控功能，按量付费，便宜。但配置起来比Uptime Kuma繁琐，告警规则也复杂一些。

监控什么，比用什么工具更重要

工具选型花不了一天，但监控项的设置需要想清楚。我的经验是分三层：

第一层，基础设施。服务器CPU、内存、磁盘、网络。这些用Node Exporter加Prometheus，或者直接用云厂商的监控。磁盘满了导致网站挂掉，这种事太常见了。

第二层，应用状态。HTTP状态码、响应时间、证书过期时间。证书过期是典型的“你知道它会发生但就是忘了”的事故。监控里加一条证书检查，提前30天告警。

第三层，业务逻辑。比如登录接口能不能正常返回token，下单接口能不能创建订单。这层最容易被忽略，但恰恰是用户最敏感的。一个电商网站，首页能打开但下单报错，跟挂了没区别。

我见过一个案例，某公司监控只盯了首页，结果支付接口挂了三个小时没人知道。后来他们在监控里加了一个模拟下单的脚本，每五分钟跑一次，发现问题立刻告警。这种业务级别的监控，才是真正有价值的。

告警疲劳是个坑

监控配多了，告警就多。告警多了，人就麻木了。我经历过一个阶段，每天收到几十条告警邮件，最后全部标为已读，看都不看。这比没有监控还危险。

解决办法就两个：一是分级，P0电话告警，P1钉钉群，P2邮件日报。二是收敛，同一问题五分钟内只告警一次，恢复后发一条恢复通知。Uptime Kuma和大多数监控工具都支持这些设置。

还有个小技巧，把告警和值班表绑定。谁值班谁收告警，别一股脑发到群里。群里人多了，反而没人负责。

说到底，网站可用性监控容易不容易，取决于你什么时候开始做。上线第一天就配好，后面都是顺手的事。等出了事故再补，那就是救火。我现在接手新项目，第一件事就是跑一个Uptime Kuma，把首页和健康检查接口配上。花不了十分钟，但能睡个安稳觉。