Uptime Kuma 部署与告警教程：先监控一个网址，再验证通知真的能收到

Uptime Kuma 支持 HTTP、TCP、DNS、关键词等监控，也能发送多种渠道通知。搭建时最容易漏掉的不是“有没有绿色图标”，而是服务重启后数据是否还在，以及目标故障时通知是否真正到达。

建立一个独立的 Docker 实例

准备好 Docker 后，新建目录与 compose.yaml。下面使用官方 2 系列镜像，并把管理端口限制在本机；若已有同名实例，应先检查现有配置，不要重复启动。

1
2
3
4
5
6
7
8
9
10

services:
  uptime-kuma:
    image: louislam/uptime-kuma:2
    restart: unless-stopped
    ports:
      - 127.0.0.1:3001:3001
    volumes:
      - uptime-kuma-data:/app/data
volumes:
  uptime-kuma-data:

1
2
3

docker compose config --quiet
docker compose up -d
docker compose ps

在服务器本机打开 http://127.0.0.1:3001 并完成账户设置。远程管理应通过自己已有的安全访问方式或单独配置 HTTPS 入口，不要为了方便直接取消认证。官方特别提醒数据目录应放在本地目录或卷，NFS 等文件系统不受支持。

添加第一个 HTTP 监控

选择 HTTP(s) 类型，填入自己负责的网址，使用清楚的名称。先确认地址不需要交互式登录，再设置合理的检查间隔、超时和重试。过短间隔会增加负载，也容易把网络瞬时抖动当成持续故障。

先等到几次检查都成功，再理解响应时间曲线。HTTP 200 只说明这次请求获得了预期状态，不证明登录、搜索或文章保存功能正确；必要时增加关键词或专门的健康检查地址，但不要让健康接口输出密钥与内部资料。

通知要单独验收

在通知设置里填写自己控制的接收渠道，先使用测试通知按钮，确认消息真的抵达。然后把通知绑定到相应监控项目；只保存一个通知配置，并不代表所有监控已经使用它。

接着使用自己专门准备的测试目标制造一次短暂故障，观察故障通知与恢复通知是否都收到。不要用关闭真实生产服务的方式随意测试告警。

为什么监控绿色，用户却说打不开

监控服务器所在网络、DNS、地区、登录状态可能与用户不同。把监控地址、状态码和监控地点一起看；若只有某个地区出问题，可以添加独立监测点，而不是直接把正常检查结果当成用户反馈不成立。

升级与数据保留

持久卷保存监控配置和历史数据。升级前按官方说明备份数据，并阅读跨版本升级要求；不要删除卷来解决普通启动问题。2 标签会随该系列更新，生产使用者还应记录当时运行的具体镜像版本，以便排查变化。

官方仓库与安装说明 · 2.5.6 发布记录