用 Uptime Kuma 搭建自建监控

站点挂了往往不是第一时间知道，而是用户来反馈才知道。Uptime Kuma 是一个免费、开源的 uptime 监控工具，支持 HTTP(s)、TCP、Ping、DNS 等协议，自带漂亮的状态页和 90 多种通知渠道。数据存在自己的服务器上，没有按监控项收费的问题，小团队或个人站长用它替代商业监控服务很合适。部署过程也简单：一个 docker-compose 文件加一个反向代理，十分钟内就能把监控跑起来，比起反复比较各家 SaaS 的免费额度，自建一次就一劳永逸。

为什么要自建而不是用商业监控

商业监控服务通常按监控项和通知渠道收费，监控项一多，月费就上去了；免费套餐又往往限制历史保留时长和请求频率。Uptime Kuma 把数据存在你自己的服务器上，不受套餐限制，监控数量、历史数据、通知渠道都没有额外费用。对预算有限的小团队来说，这是很实际的考量。当然自建也有代价：监控服务本身要维护，单点部署时它挂了就没人提醒你——所以生产环境建议再挂一个外部探针兜底。

Docker Compose 部署

# docker-compose.yml
version: '3.8'
services:
  uptime-kuma:
    image: louislam/uptime-kuma:latest
    container_name: uptime-kuma
    ports:
      - "127.0.0.1:3001:3001"
    volumes:
      - ./uptime-kuma-data:/app/data
    restart: unless-stopped

参考：Uptime Kuma 官方仓库 https://github.com/louislam/uptime-kuma

注意这里只把端口绑定到 127.0.0.1，外部无法直接访问，需要配合 Nginx 反向代理加 HTTPS 暴露。

Nginx 反向代理

# /etc/nginx/sites-available/status.example.com
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;
        proxy_set_header X-Real-IP $remote_addr;
        proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
        proxy_set_header X-Forwarded-Proto $scheme;
    }
}

证书申请与自动续期可以参考Let's Encrypt 配置。

一键部署脚本

#!/bin/bash
# deploy-uptime-kuma.sh

mkdir -p /opt/uptime-kuma && cd /opt/uptime-kuma
nano docker-compose.yml   # 粘贴上面的 YAML
docker compose up -d
docker compose ps
echo "访问 http://your-server:3001"
echo "再用 Nginx 反向代理配置 HTTPS"

首次使用

打开 http://your-server:3001（或你的域名）。
创建管理员账号。
点击 Add Monitor，选择监控类型。
填入网站地址和检查间隔。
配置通知渠道（Telegram、Email、Slack 等）。

通知配置示例

Telegram：

1. 在 Telegram 里通过 @BotFather 创建机器人
2. 拿到 Bot Token 和 Chat ID
3. Uptime Kuma: Settings → Notifications → Add → Telegram
4. 填入 Token 和 Chat ID → Test 验证

邮件 SMTP：

1. Settings → Notifications → Add → SMTP
2. 填 SMTP 服务器、端口、用户名、密码
3. 建议开启 TLS
4. 发送测试邮件验证

支持的监控类型

类型	用途	典型检查项
HTTP(s)	网页可用性	状态码、关键字、响应时间
TCP	端口连通性	数据库、SSH、Redis 端口
Ping	主机存活	丢包率、延迟
DNS	域名解析	A 记录、解析结果
证书	SSL 证书有效期	到期天数

安全与维护

Uptime Kuma 虽然只是监控工具，但也别裸奔。上线后第一件事是改掉管理员密码，并关闭开放注册；面板入口建议放在独立的子域名下，配合反向代理加 HTTPS。数据目录要纳入备份计划，监控配置、通知设置都在里面。镜像升级时先备份数据再拉新版本，回滚也容易。

公开状态页的打开方式

配置好监控后，可以给每个监控项开启"公开状态页"，生成一个只读链接，放在官网页脚或文档站里。这样用户遇到故障时先看状态页，而不是直接找客服。状态页只读，不影响内部管理界面。

常见问题

通知收不到怎么办？ 先检查通知配置里的 Token/账号是否正确，用 Test 按钮发一条测试；再确认服务器能访问 Telegram/SMTP 的域名，部分厂商需要额外放行。容器重启后数据还在吗？ 只要卷挂载了 ./uptime-kuma-data:/app/data，监控配置和历史记录都在；升级镜像前先备份该目录。能监控内网服务吗？ 可以，Uptime Kuma 跑在内网就能监控内网 IP，也可以把它当作探针去测公网服务。和 Grafana/Prometheus 是什么关系？ 它是轻量的可用性监控，侧重"挂没挂"，而 Prometheus 侧重指标采集与分析，两者可以共存。

进阶：多实例与备份

如果业务面向全球用户，可以在不同地区各部署一个实例，用多个探针交叉验证。升级或迁移前，把整个 uptime-kuma-data 目录打包备份即可；恢复时解压回原路径再启动容器，配置和监控项会原样回来。

最佳实践

间隔与告警疲劳。业务告警建议 1 分钟间隔、连续失败 2-3 次再触发通知，避免网络抖动造成误报。更完整的告警策略见告警疲劳与值班实践。
多个监控点。条件允许时在国内外各放一个实例，交叉验证可以区分"网站挂了"还是"某条线路挂了"。
公开状态页。面向用户的站点可以把状态页设为公开，减少"是不是只有我这里打不开"的客服咨询。
配合合成监控。把 Uptime Kuma 与合成监控结合，覆盖更接近真实用户的场景。

监控体系的整体规划可以参考监控与告警指南，也欢迎浏览监控报警分类。