Uptime Kuma 监控搭建完整指南

Uptime Kuma 是一款开源、自托管的可用性监控工具，界面漂亮、部署简单，被称为"自托管版的 UptimeRobot"。适合个人项目、小团队快速搭建监控与状态页。本文带你从零跑通完整流程。

准备工作

一台装了 Docker 的机器（VPS、NAS、甚至树莓派都行）：

docker --version   # 确认 Docker 可用

第一步：Docker 一键部署

docker run -d --restart=always \
  -p 3001:3001 \
  -v uptime-kuma:/app/data \
  --name uptime-kuma \
  louislam/uptime-kuma:1

参数解读：

• -d：后台运行；
• --restart=always：崩溃或重启 Docker 后自动拉起——监控工具自己必须足够皮实；
• -p 3001:3001：端口映射，宿主机 3001 → 容器 3001；
• -v uptime-kuma:/app/data：数据卷持久化，删容器不丢配置；
• --name uptime-kuma：容器命名，方便管理。

跑起来后访问 http://服务器IP:3001，创建管理员账号即进入仪表盘。

第二步：创建监控器

点"添加监控项"，常用类型：

• HTTP(s)：填 URL，设置探测间隔（默认 60 秒）、重试次数、期望状态码、关键字断言；
• TCP 端口：监控数据库端口（3306/5432）、SSH（22）等；
• Ping：主机层可达性；
• DNS：校验域名解析结果；
• Docker 容器：监控本机容器运行状态。

第三步：配置通知

设置 → 通知，支持几十种渠道：Telegram、Slack、Discord、邮件、Webhook、企业微信（通过 Webhook）等。配置后点"测试"确认能收到，再把通知绑定到各监控器上。

第四步：搭建状态页

"状态页"功能可以把选定监控器的可用性公开成一个页面（类似 status.example.com）：分组展示服务、显示近期可用率与事件时间线。给客户或内部用户一个"服务状态自查"入口，能显著减少故障期间的询问消息。

Uptime Kuma 的局限：什么时候该换

开源单机架构决定了它的边界：

• 单点问题：监控工具本身跑在一台机器上，那台机器挂了 = 监控全盲。而它监控的对象往往就包括那台机器所在的基础设施；
• 单地域探测：从一个点探测，无法发现区域性网络问题，误报率也更高；
• 无多用户与权限体系：团队共用一个管理员账号；
• 数据能力弱：没有长期趋势分析、没有与日志/链路数据的关联；
• 规模化困难：几百个监控项后的管理与性能都吃力。

个人项目与小团队内部系统，Uptime Kuma 完全够用；面向客户的核心业务，需要多地域、高可用、与可观测性数据打通的平台。

观测云对照

观测云的可用性监测提供开箱即用的 SaaS 版能力：多地域探测节点（平台维护，无需自己保活）、HTTP/TCP/ICMP/DNS/SSL 全协议、关键字断言、秒级频率；告警直连钉钉/企微/飞书/电话；状态页功能内置；更重要的是探测数据与 APM、日志、RUM 天然关联——可用性告警可以直接下钻到后端 Trace，自托管方案里这需要人工拼接多个系统。

常见问题（FAQ）

Q：Uptime Kuma 数据怎么备份？
A：备份 Docker 卷 uptime-kuma（容器内 /app/data）：docker run --rm -v uptime-kuma:/data -v $(pwd):/backup busybox tar czf /backup/kuma-backup.tar.gz /data。

Q：能监控内网服务吗？
A：这正是自托管的优势——Uptime Kuma 部署在内网就能探测内网地址。观测云同样支持自建拨测节点覆盖内网。

Q：Uptime Kuma 挂了谁来报警？
A：这是个哲学问题（谁来监控监控者）。实践方案：用外部 SaaS 监控 Uptime Kuma 本身的 3001 端口，形成互备。