Uptime Kuma：给全家桶服务装个心跳监控

摘要

家里服务越跑越多：博客、图床、文件站、密码库、导航页、nps 隧道……靠人肉一个个点开检查，早晚会漏。Uptime Kuma 就是干这个的：定时给每个服务发心跳，挂了就告警。这篇记录它在 CT702 上的 Docker 部署（lab-compose.yml，内网 :3001），以及监控项的完整规划：公网站点走 HTTPS 关键字监控、内网服务走 TCP/HTTP、nps 隧道走端口存活。首次管理员设置和监控项配置是待办，这篇把"配什么、怎么配、告警发到哪"的规划一次写清楚，照着做就行。

一、为什么需要心跳监控

这套家庭数据中心现在的服务清单：Halo 博客、EasyImage 图床、OpenList 文件站、vaultwarden 密码库、Dashy 导航页、Stirling PDF、nps 隧道十几条、WireGuard、qBittorrent……靠人肉巡检，一天点一遍都嫌多，还容易漏。更麻烦的是"静默故障"：服务挂了，但没人访问，就没人知道，等要用的时候才发现已经挂了三天。

心跳监控解决的就是这个问题：每隔一两分钟，自动给每个服务发一次请求，正常就记一笔，异常就告警。Uptime Kuma 轻量、好看、Docker 一把梭，是个人监控的首选。

二、部署：CT702 上的 Docker Compose

Uptime Kuma 跑在 CT702（docker-lab）上，和 Stirling PDF、Dashy 共用 /root/lab-compose.yml（在容器内，不在 PVE 宿主机）：

# /root/lab-compose.yml（uptime-kuma 片段，结构示意）
services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    ports:
      - "3001:3001"
    volumes:
      - /opt/uptime-kuma/data:/app/data

数据卷 /opt/uptime-kuma/data 持久化监控配置和历史数据。docker compose up -d 后，内网访问 http://192.168.0.127:3001，首次打开会跳转到设置页（HTTP 302），让设置管理员账号——这是正常的初始化流程，不是故障。

首次管理员设置是待办，需要用户亲自操作（账号密码用户自设，不记录明文）。设置完成后，才能开始配监控项。

三、纯内网：默认不配公网

按用户定的规矩（新增应用默认纯内网），Uptime Kuma 只有内网入口，没有公网域名，没有 nps 隧道。它的公网站点（status.028000.xyz）和隧道（28501/28502，nps 任务 11/12）在规则落地时已经删除，配置有备份。

这个决策的逻辑：监控面板本身不需要从公网访问——告警会主动推送到手机（见第六节），人只需要收告警，不需要随时打开面板看。面板纯内网，攻击面直接少一截。想看详细状态？回家，或者连 VPN。

四、监控项规划：先列清单，再配告警

监控项不要想到一个加一个，先把全家服务列成清单，再逐个配。清单如下（按优先级排序）：

P0：挂了立刻要知道的

服务	监控方式	检查目标
blog.028000.xyz	HTTPS + 关键字	首页返回 200 且含站点标题
img.028000.xyz	HTTPS + 关键字	首页返回 200
file.028000.xyz	HTTPS	首页返回 200
pwd.028000.xyz	HTTPS	登录页可达
nav.028000.xyz	HTTPS（basic auth）	401 即正常（说明认证生效）

P1：重要但可缓一会儿的

服务	监控方式	检查目标
nps 关键隧道	TCP 端口	22221（PVE SSH）、28006（PVE 面板）、28100（DSM）
WireGuard	UDP/接口状态	wg0 接口存活
CT702 Docker	Docker 宿主机	docker ps 正常（可用 push 方式上报）

P2：有空再看的

服务	监控方式	检查目标
Stirling PDF（内网）	HTTP	192.168.0.127:8080 返回 200
Dashy（内网）	HTTP	192.168.0.127:3002 返回 200
qBittorrent（内网）	HTTP	WebUI 可达

P0 是公网门面，挂了影响所有人，检查间隔设 60 秒；P1 是基础设施，5 分钟一次；P2 是内网应用，10 分钟一次。检查间隔和告警阈值（连续几次失败才告警）要匹配：P0 连续 2 次失败就告警，P2 可以放宽到 3-5 次，避免偶发抖动半夜扰民。

五、监控类型选型：HTTP、TCP 还是关键字

Uptime Kuma 支持多种监控类型，选型原则：能反映"真实可用"的最简方式。

类型	适用场景	例子
HTTPS + 关键字	公网 Web 站点	blog 首页含站点标题，才算真的活着
HTTPS（状态码）	有认证的站点	nav 返回 401 即正常，说明链路和认证都活着
TCP 端口	隧道、SSH、RDP	22221 能建连，说明 nps 隧道活着
HTTP（内网）	内网 Web 应用	Stirling PDF :8080 返回 200

关键字监控值得单独说：只看状态码 200 不够，CDN 报错页、反代故障页也可能是 200。关键字检查（页面包含预期文字）才能确认"服务真的在正常工作"。对博客这种内容站，关键字就是站点标题，一眼就能配。

TCP 监控 tunnel 端口有个细节：nps 隧道断了，VPS 上的端口可能还在监听（nps 服务端没挂，只是客户端掉了），这时 TCP 建连成功但后端是黑洞。更可靠的是端到端检查：比如 22221 不只看端口通，还要看能不能拿到 SSH banner。监控配得越接近真实使用，误报漏报越少。

六、通知渠道：告警发到哪（待办）

监控配好了，告警发到哪是关键。目前的规划（待实施）：

渠道	适用	说明
手机推送	P0 告警	首选，要求实时性
邮件	P1/P2 汇总	可以延迟，日报形式

通知渠道的配置等监控项配好后一起做。原则：P0 告警必须能叫醒人，P1/P2 可以攒成日报。告警风暴（比如家里断电全挂）要有去重/静默策略，不然手机会被轰炸到关掉通知，那就本末倒置了。

七、验收与踩坑

验收

测试项	结果
内网访问 :3001	302 跳转到设置页（正常，待用户设管理员）
容器状态	healthy，重启后自启
数据卷	/opt/uptime-kuma/data 持久化正常

踩坑

坑 1：302 不是故障。 Uptime Kuma 首次访问返回 302，是跳转到管理员初始化设置页。看到 3xx 先看 Location 头，别急着查日志。

坑 2：监控 Uptime Kuma 自己。 监控服务本身挂了，谁来告警？目前的解法是：VPS 上的 cron 定期检查内网 :3001（经 nps 或 Tailscale），异常发通知。监控的监控，至少要有一层。

坑 3：内网监控项走内网地址。 Uptime Kuma 跑在 CT702 上，和 Stirling PDF、Dashy 同一台机器，监控它们用内网地址（192.168.0.127:8080），别绕公网一圈。既快，又不消耗公网带宽，还能在外网断了时照样知道内网服务是好的（帮你定位故障在隧道还是在服务本身）。

部署后的第一周：调优告警阈值

监控项配好先别急着全开通知，第一周是"调优期"：

现象	调法
半夜被抖动吵醒	检查间隔拉长，或"连续 3 次失败才告警"
某个服务天天误报	看它的响应时间曲线，超时阈值放宽
告警风暴（断电/断网全挂）	配维护窗口或依赖关系，父节点挂了子节点静默

调优的目标：告警必须 actionable。收到告警，人知道要干什么；如果收到告警的第一反应是"哦这个又是误报"，阈值就是错的。宁可漏一次抖动，不可狼来三次——狼来了三次，第四次真来了也没人理了。

状态页：给家人看的公开版

Uptime Kuma 自带状态页功能，可以生成一个公开（或带密码）的服务状态页。用法：给家人一个地址，他们能看到"博客正常、文件站正常"，不用每次服务抽风都来问"是不是我手机坏了"。

状态页和监控面板分开：面板是管理员的（纯内网），状态页是给家人看的（可公开，只显示状态不暴露细节）。这个分工和导航页的"常用/管理"分组逻辑一致：家人看结果，管理员看原因。

监控的边界：什么不该监控

监控不是越多越好。监控项的边际效用递减，过了某个点，加的每个监控项都在制造噪音。什么不该监控？

一不监控"没人看的"。 监控项配了，告警发了，没人处理，等于没有。每个监控项都要有"主人"：谁收到告警、收到后干什么。没主人的监控项，删掉。Uptime Kuma 里躺着半年没响过的监控项，定期清理。

二不监控"处理不了的"。 比如"法兰克福网络路径抖动"，监控到了，你能干什么？打电话给运营商吗？处理不了的异常，监控它只是制造焦虑。记下来（知道有这回事），但别配告警。告警的铁律：每条告警都要有对应的处理动作。

三不监控"太细的"。 "CPU 5 分钟均值超 80%"这种，虚机跑个备份就超，天天误报。监控要抓"业务影响"，不抓"指标抖动"。服务能用，CPU 90% 又怎样？服务不能用，CPU 10% 照样告警。指标是手段，可用性是目的。

四不重复监控。 nps 隧道断了，表现为"22221 不通"和"博客打不开"两个告警，其实是一个故障。配依赖关系：隧道是父，博客是子，父挂了子静默。告警风暴时，手机只响一次，而不是十次。去重和依赖，是监控成熟度的分水岭。

监控的终极目标：告警响起时，人知道"出什么事了、要干什么"，而不是"又响了，先静音"。前者是监控，后者是噪音。P0/P1/P2 分级、调优期、状态页，都是为了这个目标。监控配得少而精，胜过多而滥。

告警的心理学：狼来了

"狼来了"是监控的终极敌人。告警响三次没事，第四次真有事，没人理了。告警疲劳不是"人的问题"，是"设计的问题"。

疲劳的来源：阈值太紧（抖一下就响）、分级不明（P2 和 P0 一个铃声）、无主告警（响了没人处理）。三个来源，三个解法：阈值按"连续 N 次"设、分级按"铃声/推送/日报"分、每个告警有主人。Uptime Kuma 的通知可以按监控分组配不同的渠道，P0 走手机推送，P2 走邮件日报。

值班的艺术：家庭场景没有"值班"，但有"谁在管"。告警发给"管事的人"，别群发。群发等于没发——每个人都以为别人会处理。指定一个人（就是你），手机常开推送。出去玩时，告诉家人"这几天告警我来看"，责任到人。

安静的价值：好的监控系统，大部分时间是安静的。安静不是"没工作"，是"一切正常"。一个月响一次，响一次就处理一次，这是健康的状态。一天响十次，九次是误报，这是生病的状态。监控的目标，是"响一次，准一次"。宁可漏一次抖动，不可狼来三次——这句话值得贴在墙上。

监控的起点：先监控"监控自己"

Uptime Kuma 监控全家，它自己挂了谁知道？答案是：VPS 上的 cron，每 5 分钟 curl 一下内网的 :3001（经 Tailscale 或 nps），不通就发通知。监控的监控，至少要有一层。这一层可以很糙：curl 通就行。但不能没有。没有它，Uptime Kuma 静默挂掉，全家"被监控"但"没人看"，等于裸奔。监控配好，调优跟上，告警分级。然后，享受安静。安静的系统，是健康的系统。响一次，准一次。这就是这套监控想要的样子，也是这篇想讲的全部。写完这篇，监控的事，告一段落。

八、总结

Uptime Kuma 的部署很简单（compose 一把梭），真正的工程量在监控项规划：P0/P1/P2 分级、检查间隔匹配、关键字确认真实可用、通知渠道分级。这篇把规划一次写清楚，待办就两件事：用户设管理员账号、按清单配监控项 + 通知。配好之后，这套家庭数据中心就有了"眼睛"，再也不用靠人肉巡检了。

摘要

目录