网站挂了两天你才知道，问题不在技术，在于没有监控
个人站长最容易犯的错，是把全部精力放在"把站建起来"，却忘了"站挂了怎么第一时间知道"。现实往往是：证书过期了、磁盘写满了、PHP-FPM 进程死了、域名被墙了，你忙着做别的事，直到读者发邮件问"你的站怎么打不开"，才发现已经宕了几个小时甚至两天。对靠站点流量吃饭的人来说，每一分钟不可用都是实打实的损失。
解决方案不需要花钱买商业监控。开源项目 Uptime Kuma 是一个颜值高、部署简单、功能完备的自建监控面板，支持 HTTP/TCP/Ping/DNS 等多种探针、支持多种告警渠道（Telegram、邮件、飞书、Webhook 等）、支持状态页。本文讲清楚用 Docker 十分钟把它跑起来、配置探针、接入告警，以及个人站长做监控时最容易忽略的几个盲区。
为什么选 Uptime Kuma
市面上自建监控的方案不少：Zabbix 太重、Prometheus + Grafana 强大但学习曲线陡、Netdata 偏性能指标而非可用性探测。Uptime Kuma 的定位很清楚——专注"服务活着吗 / 内容对吗 / 证书快过期了吗"，用起来像商业的 UptimeRobot，但完全自托管、数据在自己手里、没有免费版限制。它有这些实用特性：
- 探针类型丰富：HTTP(s)、TCP 端口、Ping、DNS 解析、关键词匹配、JSON 查询、推送心跳。
- 告警渠道覆盖广：Telegram、Discord、Slack、邮件 SMTP、飞书、企业微信、Webhook、Gotify 等。
- 每条探针可配置重试次数、心跳间隔、超时，避免误报。
- 内置状态页（Status Page），可以对外展示你的服务状态。
- 证书到期提醒、域名到期提醒（需配合相应检查）。
第一步：用 Docker 十分钟部署
Uptime Kuma 官方推荐 Docker 部署，配置和数据库都放在一个挂载卷里，升级和迁移都方便：
docker run -d \
--restart=always \
--name uptime-kuma \
-p 127.0.0.1:3001:3001 \
-v uptime-kuma:/app/data \
louislam/uptime-kuma:1
注意这里用 127.0.0.1:3001:3001 而不是 3001:3001，意思是只监听本机，不直接暴露到公网。监控面板本身含有你的服务器信息和配置，暴露到公网是安全隐患。正确的做法是前面挂一个 Nginx 反代，加上 HTTPS 和访问认证。反代配置示例：
server {
listen 443 ssl http2;
server_name status.example.com;
ssl_certificate /etc/letsencrypt/live/status.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/status.example.com/privkey.pem;
location / {
proxy_pass http://127.0.0.1:3001;
proxy_http_version 1.1;
proxy_set_header Upgrade $http_upgrade;
proxy_set_header Connection "upgrade";
proxy_set_header Host $host;
# 加一层基础认证，双保险
auth_basic "Monitor";
auth_basic_user_file /etc/nginx/.htpasswd;
}
}
WebSocket 升级头（Upgrade / Connection）不能少，Uptime Kuma 的实时状态推送依赖 WebSocket，漏了会导致面板一直转圈。生成密码文件用 htpasswd -c /etc/nginx/.htpasswd youruser。
第二步：配置第一批关键探针
首次访问 https://status.example.com 会引导你创建管理员账号。登录后点"添加新的监控项"，个人站最该先配这几类：
- 网站首页 HTTP(s)：URL 填你的首页，方法 GET，期望状态码 200，心跳间隔 60 秒，重试 2 次。这是我最重要的探针——首页打不开一切都白搭。
- 关键接口 / 内容关键词：选 HTTP(s) - Keyword 类型，在响应里匹配一段你首页固定出现的文字（比如站名）。这一招能识别"页面返回 200 但实际是错误页 / 数据库连不上吐的空白页"的情况，比单纯看状态码可靠得多。
- 数据库端口 TCP：TCP 监控
127.0.0.1:3306，确认 MySQL 进程活着。端口通不代表查询正常，但能抓住进程崩溃的场景。 - 证书过期监控：HTTPS 类型探针会自动解析并提示证书剩余天数，提前 14 天告警，避免 Let's Encrypt 自动续期失败后临期才发现。
- 推送心跳（Push）：给 cron 备份任务配一个 Push 探针，备份脚本跑成功后
curl一下那个专属 URL。如果某天没收到心跳，说明备份悄悄失败了——这是最容易被忽视、后果最严重的一类故障。
第三步：接一条真正能叫醒你的告警
监控的价值 100% 取决于告警能不能及时到达你。Uptime Kuma 的告警配置分两步：先在"设置 - 通知"里添加一个渠道，再在探针里勾选它。推荐个人站长至少配一条即时通讯渠道：
- Telegram：机器人推送最稳定，国内网络环境下也能通过代理到达。在 Telegram 里
@BotFather建机器人拿 Token，获取你的 chat id 填进去即可。 - 飞书 / 企业微信机器人：Webhook 方式，配置简单，适合国内使用。
- 邮件 SMTP：作为兜底，但邮件容易被漏看，不建议作为唯一渠道。
- Webhook / Gotify：进阶玩法，可以推送到你自己的服务或自建通知网关。
强烈建议配 两条不同渠道。单一渠道出问题（比如 Telegram 被墙、SMTP 被限流）时，你有第二道保险。告警本身的可靠性，就是整个监控体系的天花板。
个人站长最容易忽略的几个盲区
- 监控服务器和被监控服务器是同一台：如果这台机器整机宕了，监控也一起死，你收不到任何告警。正确做法是把 Uptime Kuma 部署在另一台 VPS 上，监控你的主站。跨机器的可用性才是真正的可用性。
- 只监控首页状态码：返回 200 不等于内容正常。一定要加关键词探针，或者对关键的动态接口单独探。
- 心跳间隔太短造成误报：设成 30 秒且重试 0 次，网络一抖动就狂发告警，很快你就不看告警了。合理值：间隔 60 秒、重试 2~3 次。
- 忘了监控"监控本身"：如果 Uptime Kuma 进程挂了，你不会收到任何通知。可以再给它的状态页加一个外部免费监控（或另一台机器上的脚本）做兜底。
- 不监控资源水位：硬盘、内存、inode 会在无声无息中被耗光，直到某天写不进去。Uptime Kuma 本身偏可用性，磁盘水位可以用一个简单的 cron + 告警 Webhook 或另配轻量脚本补齐。
用状态页对外建立信任
Uptime Kuma 内置的状态页功能对个人站长来说是个被低估的资产。你可以创建一个公开的状态页，只挂上几个对外服务的探针（首页、API、静态资源），给它一个好看的域名和主题色，然后在网站页脚放一个"服务状态"的链接。这带来的价值有两层：一是让读者知道"如果打不开，不是你的问题，是我们正在处理"，减少无谓的困惑；二是出现故障时透明公开，反而比假装没事更能积累长期信任。状态页可以只暴露你想让用户看到的部分，内部的数据库端口、备份心跳这类探针不必放上去。
配置状态页时注意两件事：一是状态页的访问是公开的，别把含内部信息的探针名称写得太具体（比如别叫"10.0.0.5 生产库"）；二是可以给状态页单独设一个不暴露管理入口的域名，管理面板和状态页分离。这些细节没有技术门槛，但体现的是运营一个正经站点的专业度。
把监控纳入日常运维节奏
监控搭好之后，真正的功夫在于把它变成一个习惯而非一次性任务。建议给自己定几条简单的规则：收到告警后，无论多晚都先确认一下是真故障还是误报，并记录在案；每周抽十分钟看一眼状态页的历史，观察有没有周期性的小抖动被忽略；每次给网站做重大改动（换主题、改反代、升级 PHP）之后，主动刷新探针确认一切正常再离开。监控不是用来事后追责的，而是用来把故障窗口压缩到最短的工具。个人站长没有团队值班，唯一能替代"人盯着"的，就是一套配置得当、告警可靠、你真的会看它的监控体系。
为什么这套投入值得
搭好 Uptime Kuma 大约只花一个下午，却能在未来几年里持续救命：证书快过期了提前十几天提醒你、数据库半夜崩了立刻通知你、备份静默失败了第一时间暴露、CDN 配置改错导致全站 502 也在几分钟内被发现。对个人站长来说，可观测性不是大厂的奢侈品，而是独立站活下去的必需品。先让"站挂了你能知道"这件事成立，其他优化才有意义。