当你的网站或服务在凌晨三点悄悄挂掉，而你是第二天早上被用户电话叫醒才发现的——这种事每个运维都经历过。Uptime Kuma 就是为解决”服务监控”与”宕机告警”这两个痛点而生的开源工具。它用一个漂亮的面板，帮你 7×24 小时盯住所有站点、接口、端口和容器，一旦探测失败立刻通过 Telegram、钉钉、企业微信或 Webhook 推送通知。本文带你用 Docker 从零搭建一套生产可用的自建监控体系。
一、Uptime Kuma 是什么
Uptime Kuma 是一个轻量的自托管（self-hosted）监控面板，常被比作”开源版的 UptimeRobot”。它最大的优势是数据完全掌握在自己手里，不依赖第三方 SaaS，也不会因为免费额度用尽而漏报。单个二进制或一个容器即可运行，资源占用极低，树莓派都能跑。对讲究数据主权和成本的技术团队来说，它是生产环境监控的入门首选。
和动辄需要搭建 Prometheus + Grafana + Alertmanager 全家桶的重量级方案相比，Uptime Kuma 的安装成本几乎为零：一条 docker compose 命令就能跑起来，不需要写任何配置文件，在网页里点几下就完成监控项的增删改。它不追求指标维度上的极致灵活，而是把”这个服务现在到底活着没有”这个最朴素的问题回答得又快又准。当你只需要一个能随时告诉你谁挂了的看门人时，它比重型监控栈更省心。
二、Docker 一键部署
最稳妥的方式是用 docker-compose 把数据和容器分离，方便日后备份与升级。下面这份配置把监控数据持久化到宿主机的 ./uptime-kuma 目录：
version: "3.8"
services:
uptime-kuma:
image: louislam/uptime-kuma:1.23.13
container_name: uptime-kuma
restart: unless-stopped
ports:
- "3001:3001"
volumes:
- ./uptime-kuma:/app/data
# 如需监控宿主机上的其他容器，加入 docker.sock 只读挂载
# volumes:
# - /var/run/docker.sock:/var/run/docker.sock:ro执行 docker compose up -d 后，访问 http://服务器IP:3001 即可进入初始化界面，创建管理员账号后就能开始添加监控项。如果你还不熟悉 Compose 的用法，可以先复习一下 Docker Compose 一键编排 这篇基础。
三、添加第一个监控项
Uptime Kuma 支持多种探测类型，几乎覆盖日常运维的全部场景。理解每种类型的适用边界，才能把误报和漏报都压到最低。
| 监控类型 | 适用场景 | 判定成功条件 |
|---|---|---|
| HTTP(s) | 网站、API、健康检查端点 | 返回状态码在设定范围（默认 200–299） |
| TCP | 数据库、Redis、SSH 等端口 | 端口在超时时间内可建立连接 |
| Ping | 服务器是否在线 | ICMP 往返可达 |
| Docker Container | 监控宿主机上的容器状态 | 容器处于 running 状态 |
| Keyword | 页面内容校验 | 响应体包含指定关键字 |
对多数 Web 服务，直接选 HTTP(s) 并填入健康检查 URL 即可。例如监控 API 网关，可以指向 /health 这样的轻量端点，配合”关键字”模式还能进一步确认返回内容符合预期，避免”进程活着但业务已挂”的假阳性。
四、配置宕机告警通知
监控本身不产生价值，告警触达人才产生价值。Uptime Kuma 内置了几十种通知渠道，下面这张表帮你快速选型：
| 通知渠道 | 适合人群 | 配置难度 |
|---|---|---|
| Telegram Bot | 个人/小团队 | 低（一个 Token + Chat ID） |
| Webhook | 需要接入自建系统/飞书/钉钉 | 中（需构造 JSON） |
| Email (SMTP) | 传统告警收件箱 | 低 |
| 企业微信 / 钉钉 | 国内企业团队 | 中（群机器人 Webhook） |
如果你已有统一告警中枢，最通用的是 Webhook。Uptime Kuma 会在状态变化时向目标地址 POST 一条 JSON，你只需在接收端解析 msg 和 status 字段即可。一个简单的转发示例：
curl -X POST "https://your-webhook.example.com/alert" \
-H "Content-Type: application/json" \
-d '{"title":"{{NAME}} 状态变更","msg":"{{MSG}}","status":"{{STATUS}}"}'建议同一个监控项至少挂两个不同通道（例如 Telegram + 邮件），防止单一通道故障时告警石沉大海。模板变量 {{NAME}}、{{MSG}}、{{STATUS}} 会在推送时自动替换为真实值。
五、公开状态页（Status Page）
除了自己看，Uptime Kuma 还能一键生成对外公开的状态页，把各服务的可用率、响应耗时曲线展示给客户或用户，提升信任感。在”状态页”菜单里勾选要展示的监控项，设置自定义域名与品牌色，就能得到一个类似 status.github.com 的页面。对 SaaS 产品或对外 API 服务而言，一个诚实的状态页比口头解释更有说服力。
六、用 Nginx 反代 + HTTPS 暴露面板
直接把 3001 端口暴露在公网并不安全。更规范的做法是用 Nginx 反向代理 套一层 HTTPS，并限制访问来源。核心配置如下：
server {
listen 443 ssl;
server_name status.yourdomain.com;
ssl_certificate /etc/nginx/ssl/status.fullchain.pem;
ssl_certificate_key /etc/nginx/ssl/status.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;
# WebSocket 支持，Uptime Kuma 实时推送依赖它
}
# 面板本身带登录，但前端再加一层 Basic Auth 更稳妥
auth_basic "Restricted";
auth_basic_user_file /etc/nginx/conf.d/status.htpasswd;
}注意一定要透传 Upgrade 和 Connection 头，否则面板里的实时图表会无法建立 WebSocket 连接，看起来就像”卡住”了一样。
七、数据备份与迁移
Uptime Kuma 的所有配置和监控历史都落在 /app/data 目录（默认是 SQLite 数据库 + 附件）。备份它就能完整迁移。一个最小可用的定时备份脚本：
#!/bin/bash
# backup-uptime-kuma.sh
SRC=/opt/uptime-kuma/uptime-kuma
DST=/backup/uptime-kuma/$(date +%F)
mkdir -p "$DST"
docker compose -f /opt/uptime-kuma/docker-compose.yml exec -T uptime-kuma \
sqlite3 /app/data/kuma.db ".backup /tmp/kuma.db"
docker cp uptime-kuma:/tmp/kuma.db "$DST/kuma.db"
tar czf "$DST/data.tgz" -C "$SRC" .配合 GitHub Actions 把备份归档上传到对象存储，就能实现异地容灾，彻底告别”监控数据随服务器一起蒸发”。恢复时只需把 /app/data 目录整体替换并重启容器即可。
八、生产实践清单与常见坑
部署到生产环境前，对照下面这张清单做一次自检，能少踩很多坑：
| 检查项 | 说明 |
|---|---|
| 监控频率 | 默认 60s，核心服务可降到 20s；过频会被目标站点限流 |
| 重试次数 | 建议设为 1–2 次再告警，过滤瞬间抖动 |
| 证书监控 | 开启 SSL 证书过期提醒，避免 HTTPS 突然失效 |
| 面板安全 | 反代 + Basic Auth，并接入 fail2ban 防暴破 |
| 自身可用性 | 监控系统的存活探针要独立于被监控对象 |
另外，监控面板本身也需要被监控——可以把 Uptime Kuma 部署在和被监控服务不同的节点，避免”同归于尽”。如果面板部署在云服务器上，记得按 SSH 连接故障排查 的思路配好密钥登录与防火墙，减少暴露面。
九、小结
Uptime Kuma 用极低的成本，把”被动救火”变成”主动感知”。从 Docker 部署、监控项配置、多渠道告警、状态页公开，到 Nginx 反代与备份迁移，一套流程走下来，你的服务就拥有了一个永不疲倦的守夜人。当告警第一次在故障发生的 30 秒内把你叫醒，而不是被用户叫醒时，你就会明白这套体系的价值。
