Uptime Kuma：给服务器装一张值班表

假设这样一个现场：实验室的树莓派接着电表做采集，脚本挂了三天没人发现，等到出周报才看见数据断了一截。这不是技术难题，是没人盯着。

louislam/uptime-kuma 干的就是"盯着"这件事。93,319 star、8,666 fork，MIT 协议，一条 docker 命令起服务，浏览器里点几下就能把网址、端口、Ping、DNS、容器状态全挂上去，出问题时按你指定的渠道喊人。

项目名片

它解决什么问题

自建服务的故障大多不是"崩了"，而是"悄悄不动了"：脚本还在跑，但没在写数据；页面还打得开，但接口返回 502；证书还有三天过期，没人看。

常见的用法有三类：盯一个域名的可用性、盯一台机器的存活、盯还没过期的证书。三件事的共同点是"出问题时不需要多聪明的诊断，只需要有人马上知道"，而这恰好是商用监控按月按探针收费最不划算的部分。

Uptime Kuma 替掉的是"给自己那几台机器配一个看着的人"这一层——替掉的是成本和上手门槛，替不掉的是分布式探测和专业告警编排。

核心机制

1. 监控项按"类型 + 心跳间隔"定义，README 写明心跳为 20 秒级；HTTP、TCP、Ping、DNS、Websocket、Push 都在支持列表里。
2. 通知走 90+ 个渠道，Telegram、Discord、Slack、邮件这些常见的基本都在仓库的 notifications 目录里能查到对应实现。
3. 状态页可以单独绑定域名（README 的 Features 里写着 Map status pages to specific domains），也就是对外展示的那张页面不必和管理面板挤在同一个地址上。
4. 前端是单页应用 + WebSocket，不是定时轮询 REST：README 的 Motivation 里作者原话是想试 "WebSocket with SPA instead of a REST API"。（推断：所以反向代理必须转发 WebSocket，否则页面会卡在重连。）
5. 数据默认落在容器的 /app/data，一个进程一套数据，部署形态很轻——（推断：反过来说，它也没有多节点同时探测的能力。）

跑起来

compose 方式，四行，路径用变量拼短：

mkdir -p ~/kuma && cd ~/kuma
U=https://raw.githubusercontent.com
U=$U/louislam/uptime-kuma/master
curl -o compose.yaml $U/compose.yaml
docker compose up -d

不想用 compose 就一条 docker run：

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

只想本机访问，把端口那行换成 -p 127.0.0.1:3001:3001，别把管理面板直接暴露在公网。

从零到能用

1. 浏览器打开 http://你的服务器IP:3001，第一次会让你建管理员账号，密码别用默认的。
2. 右上角「添加监控项」，类型选 HTTP(s)，填你自己服务的地址，间隔保持 60 秒起步。
3. 同一页往下，勾上「证书到期提醒」，给证书留 14 天缓冲。
4. 左侧「通知」里加一个渠道，Telegram 填 bot token 和 chat id，点「测试」能收到消息再保存。
5. 回到监控项把通知挂上，然后去「状态页」建一个公开页，把要展示的项拖进去——这就是可以发给别人的那张"值班表"。

适合谁用 / 别用

适合：一个人或三五个人维护几台机器、几个站点，想要一个能发通知、能给外人看的状态页，且不想为监控单独付月费。

别用：需要多地探针判断"是不是只有我这个网络不通"、需要复杂告警升级策略（几点没人应就打电话给第二个人）、或者要监控上千个目标还要做容量分析。这些是商业产品的腹地。

另外看一组数：863 个 open issues，同时 v2.5.5 到 v2.5.9 在 9 月到 10 月之间连发了五个版本。这说明维护是活跃的，但也说明需求单积压不少——你提的功能请求大概率不会很快排上，选它之前先确认现有功能够用。

三个真实的坑

一、NFS 挂载明确不支持。 README 里有一条 WARNING 原文写着文件系统如 NFS 不被支持，要映射到本地目录或卷。把数据目录挂到 NAS 上，出问题会是数据损坏级别的。

二、没有分布式探针。 issue #84「Remote Executors」2021-07-19 提出，到今天仍然 open。也就是说所有探测都从你这台机器发出去，"我这边能通、用户那边不通"这类判断它给不了。

三、反代要记得开 WebSocket。 前端走 WebSocket（见上面第 3 条），Nginx 只配 proxy_pass 不配 Upgrade 头，页面会一直转圈，日志里看着还都是 200。

小结

它不解决"系统为什么会挂"，只解决"挂了之后谁先知道"。对个人项目和小团队，这已经是最划算的一层保险：装上、配好通知、把状态页发给该看的人，剩下的时间回去写代码。

真要把它用稳，记住三个动作：数据目录一定落本地盘、反代一定转 WebSocket、通知一定点一次"测试"再保存。前两个决定它会不会坏，第三个决定它在你要它喊人的时候张不张嘴。

参考资料

• 仓库：https://github.com/louislam/uptime-kuma
• README（部署与 NFS 警告原文）：https://github.com/louislam/uptime-kuma#readme
• 最新 release v2.5.9：https://github.com/louislam/uptime-kuma/releases/tag/2.5.9
• 分布式探针 issue #84：https://github.com/louislam/uptime-kuma/issues/84
• 安装与反代文档：https://github.com/louislam/uptime-kuma/wiki