一、主动监控的价值：在故障发生前收到通知
网站挂了、证书过期了、API 变慢了，如果全靠用户反馈或等自己发现，往往已经造成实际损失。uptime-kuma 是一款开源、轻量、自托管的监控工具，支持 HTTP/HTTPS、TCP、Ping、DNS、数据库等多种探测，并在判定故障时通过邮件、Telegram、企业微信、Server酱等推送告警。它的"自建 + 高度可自定义"特性很适合放在自己的 VPS 上，作为常驻的"哨兵"。相比 SaaS 监控，自建免账号、数据不出网、可控性更强。
二、最省事的部署：Docker Compose
uptime-kuma 官方推荐用 Docker 部署，一键拉起（沿用之前 Docker 文章的姿势）：
# docker-compose.yml
version: "3.8"
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
restart: always
ports:
- "8080:3001" # 映射管理端口
volumes:
- ./uptime-kuma-data:/app/data # 数据持久化，容器删除不丢
docker-compose up -d docker-compose ps
访问 http://你的IP:8080 首次会要求设置管理员账号密码。用 Docker 的最大好处是"零依赖 + 数据卷持久化 + 更新只需拉镜像重启"，与 LNMP 上已有的 Docker 环境完全兼容。
三、不装 Docker 的裸装方式
不想用 Docker 也可以用 Node.js 直接跑：
curl -fsSL https://deb.nodesource.com/setup_20.x | sudo -E bash - sudo apt install -y nodejs git # 克隆并安装依赖 git clone https://github.com/louislam/uptime-kuma.git cd uptime-kuma npm ci --only=prod node server/server.js
裸装更适合已在 Node 生态、或不想引入 Docker 的场景。生产建议也用 systemd 托管（可用之前 systemd 文章的知识）让它在后台常驻并开机自启：
# /etc/systemd/system/uptime-kuma.service [Unit] Description=Uptime Kuma After=network.target [Service] Type=simple User=www-data WorkingDirectory=/opt/uptime-kuma ExecStart=/usr/bin/node /opt/uptime-kuma/server/server.js Restart=always RestartSec=3 [Install] WantedBy=multi-user.target
sudo systemctl daemon-reload && sudo systemctl enable --now uptime-kuma
四、添加监控项与告警通知
登录后台，先建"通知"（设置你要接收的方式），再建"监控"。以监控一个网站的关键点为例：
- 监测类型：选 HTTP(s)，填目标 URL（如 https://www.yvps.cn/）。
- 请求方式：GET；可设"含有关键字"校验响应内容，避免"页面崩溃但返回200"。
- 超时 / 重试：设如 30 秒超时、重试 2 次，减少误报。
- 心跳间隔：如每 60 秒探测一次。
- 把之前建好的通知挂到这个监视器上，故障或恢复即推送。
也可以监控某一端口的 TCP 连通性（探测 MySQL 3306）、Ping（测延迟丢包）、DNS、甚至数据库查询（测试 MySQL 服务是否正常响应）。Uptime-kuma 能保存一段时间的监控状态和响应时间曲线，方便回顾历史。
五、SSL 证书与反向代理保护管理页
管理页端口（8080）直接暴露公网有风险，建议用 Nginx 反向代理 + HTTPS + 访问口令保护（沿用 SSL 与 Nginx 文章内容）：
server {
listen 443 ssl;
server_name monitor.example.com;
ssl_certificate /etc/letsencrypt/live/monitor.example.com/fullchain.pem;
ssl_certificate_key /etc/letsencrypt/live/monitor.example.com/privkey.pem;
location / {
proxy_pass http://127.0.0.1:8080;
proxy_set_header Host $host;
proxy_set_header X-Real-IP $remote_addr;
# 用 basic auth 加一层登录保护
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/.htpasswd;
}
}
# 生成 basic auth 用户 sudo apt install -y apache2-utils sudo htpasswd -c /etc/nginx/.htpasswd admin sudo nginx -t && sudo systemctl reload nginx
这样管理入口变成 https://monitor.example.com，还需输入账号密码，端口也不直接暴露。
六、告警触发与排错建议
# 日志查看容器/Uptime-kuma 运行状态 docker logs -f uptime-kuma # Docker 部署 journalctl -u uptime-kuma -n 100 # systemd 裸装
常见问题：通知收不到——先在建通知时点"测试"，排查网络与平台限制；监控误报多——把重试次数和超时调高；被自己的监控拒之门外（如果用 basic auth 探测被封）——让监控探测走允许路径并加白名单。另外监控你自己的建站服务器时，注意别让监控本身成为被防火墙限流的对象。
写在最后
uptime-kuma 用极低资源换来了"服务异常的提前预警"。落地三步：Docker 或 Node 部署、建好通知渠道、添加你想守护的监控项（HTTP 关键字、TCP 端口、Ping、数据库都行）。再配合 Nginx+HTTPS+基础认证加固管理入口。有了它，配合之前的磁盘监控与日志轮转，你的服务器就具备了"自愈前的预警"能力——大部分故障在影响用户前，你已经在手机上收到了通知。
