👁 102 次阅读
网站半夜宕机没人知道？个人站长必备的监控自查手册
说一个很多人踩过的坑：你的服务器在凌晨三点挂了，但你早上八点醒来才发现。中间这五个小时，用户打不开你的网站，搜索引擎爬虫碰了一鼻子灰，潜在客户转头去了竞争对手那里。而你什么都不知道。
更隐蔽的情况是：网站看起来“还活着”，服务器能 ping 通，但数据库连接池满了、SSL 证书过期了、或者某个 API 接口超时了。这些故障不会让站点完全打不开，却会让用户体验直线下降。等到有人投诉的时候，问题可能已经持续了好几天。
个人站长和小团队最缺的从来不是技术能力，而是“知道出事了”的能力。你没有 24 小时值班的运维，也不太可能半夜爬起来刷新浏览器。所以这篇文章不讲虚的，只讲一套能落地的监控自查方案——用什么工具、配什么规则、哪些指标必须盯。
先搞清楚：你的网站到底可能怎么“死”
监控不是随便加几个监测项就完了。你得先知道自己要防的是什么。
最常见的网站故障其实就三类：第一类是服务器层面的宕机，比如进程崩溃、内存溢出、被 OOM Killer 干掉；第二类是外部服务故障，比如 DNS 解析异常、域名过期、SSL 证书失效——你的服务器可能跑得好好的，但用户就是打不开；第三类是“半死不活”状态，HTTP 状态码还是 200，但响应时间从 200ms 涨到了 8 秒，或者页面返回了一堆错误内容。
很多站长只监控第一类。他们 ping 一下服务器，通了就以为没事了。DNS 和证书的问题，他们完全不设防。至于性能退化这种“温水煮青蛙”式的故障，更是等到用户大量流失才后知后觉。
所以监控方案的底层逻辑应该是：外部视角优先，多维度覆盖，告警及时。
外部监控：用 UptimeRobot 把“知道”这件事变成自动化
外部监控的核心价值在于：它从公网来探测你的站点，跟你服务器本身的死活无关。哪怕你的服务器彻底断电，外部监控照样能发现你的网站挂了。
我自己用的是 UptimeRobot，免费版对个人站长来说绰绰有余。具体给的是什么：50 个监控项，5 分钟检测间隔，支持 HTTP、Ping、端口和关键词监控，还有公开状态页和邮件/App 推送。最关键的是它免费版允许商业使用，没有“仅限个人”的限制。
注册地址在这里：https://uptimerobot.com/?red=meng&sub_id=aibsz-3169。注册完直接添加监控就行，不需要绑卡，也不需要理解什么复杂的配置概念。
添加监控的时候，有三件事必须做。
第一，不要只监控首页。首页返回 200 不代表你的网站正常。至少加三个监控项：首页、登录页（或者一个需要数据库查询的页面）、以及一个关键 API 端点（比如 `/api/health`）。如果你的 WordPress 站点，加一个 `/wp-admin/admin-ajax.php` 的探测，能提前发现数据库连接的问题。
第二，开启关键词监控。UptimeRobot 的免费版支持关键词检测。你可以在监控设置里指定一个页面必须包含的字符串，比如你的网站名称或者一个特定的 `
第三，注意检测间隔的现实意义。5 分钟意味着最坏情况下，你的网站可能挂了 4 分 59 秒你才知道。对个人站来说这个延迟可以接受。如果你做的是电商或者预约类站点，5 分钟可能太长了，那就需要考虑付费版或者自建方案。
UptimeRobot 的告警渠道支持邮件和手机 App 推送，免费版还带五个集成（Google Chat、Discord、Pushover、Pushbullet、Splunk）。建议至少配一个手机推送，邮件在半夜的提醒效果远不如 App 通知。
自建监控：Uptime Kuma 适合“不想把数据交给别人”的人
如果你对数据主权有要求，或者想用更低的检测间隔（Uptime Kuma 支持 20 秒），那 Uptime Kuma 是值得折腾的选择。
它是一个开源的自托管监控工具，部署极其简单，一条 Docker 命令就能跑起来。核心功能和 UptimeRobot 类似：HTTP 监控、TCP 端口检测、Ping、DNS 查询、关键词匹配。但它的通知渠道支持更广，包括企微机器人、飞书、钉钉、Server 酱这些国内常用的工具。
Uptime Kuma 最大的优势是数据完全在你自己手里，而且检测间隔可以压得很低。如果你有一台闲置的小 VPS，部署上去当监控节点，成本几乎为零。
但它有一个致命的坑必须说清楚：不要把你的监控和业务部署在同一台服务器上。如果你的监控节点和网站跑在同一台机器上，服务器一挂，监控也跟着失联，你照样什么都不知道。监控节点必须独立，哪怕是一台最便宜的 1 核 1G 的 VPS 都行。
另一个现实问题是：Uptime Kuma 需要你自己维护。Docker 镜像更新、数据库备份、反向代理配置、SSL 证书续期——这些你都得自己管。如果你只是想“知道网站挂没挂”，不愿意花时间折腾运维，UptimeRobot 的零维护体验更合适。
别忘了 DNS 和 SSL：这两个坑最容易被忽视
前面说的监控工具都能检测 HTTP 状态码，但 DNS 解析失败和 SSL 证书过期不一定能让 HTTP 探测报警。
DNS 的问题在于“时好时坏”。你的域名可能因为注册商故障或者解析缓存异常，在某些地区无法解析，但在你本地测试一切正常。UptimeRobot 和 Uptime Kuma 都支持 DNS 记录监控，建议你至少加一条 A 记录的检测，确认域名能正确解析到你的服务器 IP。
SSL 证书的问题更隐蔽。证书过期的那一天，Chrome 会直接显示红色警告页，用户看到“您的连接不是私密连接”之后大概率直接关掉页面。但很多监控工具只检测 HTTP 状态码，证书过期了它照样返回 200，监控不会报警。
解决这个问题有两个思路。一个是靠监控工具本身：Uptime Kuma 内置了证书信息展示，可以看到期时间。另一个是专门做证书监控：如果你有多个域名，可以试试 Domain Admin 这个开源项目，专门监控域名和 SSL 证书的到期时间，支持邮件、企微、飞书、钉钉通知。部署成本很低，能解决一个非常具体的痛点。
系统层面的自查：那些“不挂但很慢”的问题
外部监控能告诉你“用户访问不了”，但没法告诉你“为什么”。当你的网站响应时间从 200ms 变成 3 秒的时候，你需要知道是哪一层出的问题。
如果你用的是阿里云 ECS，基础云监控是免费自带的，不需要额外配置就能用。它提供 1000 条/月的免费短信报警和 100 万次/月的 API 查询调用。你可以直接在里面配置 CPU、内存、磁盘 I/O、带宽的告警规则。比如内存使用率超过 85% 连续 3 个周期就发短信，这个免费的额度对个人站来说完全够用。
如果你用的是非阿里云的 VPS，可以考虑装一个轻量的系统监控 Agent，或者直接用 `cron + 脚本` 做最基础的自查。写一个每分钟跑一次的 shell 脚本，检查 `free -m` 的内存剩余、`df -h` 的磁盘使用率、以及 `systemctl status nginx` 的服务状态，异常就发邮件。粗糙，但有效。
关键是要想清楚：你盯的指标必须跟你实际的业务瓶颈相关。WordPress 站点最怕的是 PHP-FPM 进程池被占满，那就盯进程数。Node.js 站点最怕的是事件循环阻塞，那就盯事件循环延迟。数据库驱动的站点，连接池使用率比 CPU 使用率更有意义。
一个最小可行的监控清单
如果你不想看上面那么多细节，这是可以直接抄的作业：
外部监控（UptimeRobot 或 Uptime Kuma）：
- 首页 HTTP 监控，间隔 5 分钟，关键词检测验证内容
- 关键接口 HTTP 监控，验证数据库连通性
- DNS A 记录监控，确认域名解析正常
- SSL 证书到期监控（如果工具支持）
系统监控（阿里云监控或自建脚本）：
- CPU 使用率 > 90% 持续 5 分钟报警
- 内存使用率 > 85% 报警
- 磁盘使用率 > 80% 报警
- 目标服务进程存活检测
告警渠道：
- 至少配置一个手机推送（UptimeRobot App 或 Telegram Bot）
- 邮件作为备份渠道
- 如果是国内工具，企微/钉钉机器人消息最适合团队协作
这套清单跑起来，你基本上不会再出现“网站挂了五个小时才发现”的情况。最坏情况下，5 分钟的检测间隔意味着你最多损失五分钟的用户访问。
最后说一句
监控这件事的逻辑其实很简单：你不可能手动盯着一个东西 24 小时不出错，所以让机器替你盯。UptimeRobot 免费版 50 个监控项，5 分钟检测，零维护，对绝大多数个人站长来说已经是“用了就回不去”的工具。注册地址放在这里了：https://uptimerobot.com/?red=meng&sub_id=aibsz-3169。花十分钟配好，以后半夜睡得踏实。
网站出故障不可怕，可怕的是你比用户还晚知道。