Uptime Kuma 的目标不是堆满绿色监控项，而是让故障发生时更快知道哪一层出了问题。

\n
Uptime Kuma 很适合 HomeLab，因为它部署轻、页面清楚、通知渠道多。但我不会把它当成“服务列表展示器”。一排绿色看起来舒服，真正故障时却可能回答不了问题：是域名解析坏了，反代坏了，应用挂了，数据库不可用，还是 NAS 磁盘满了？监控项设计要围绕排障路径，而不是围绕数量。

监控项按链路分层

我通常把监控分成四层：入口层、应用层、依赖层、宿主机资源层。入口层看域名和 HTTPS，例如 https://app.example.com/health；应用层看容器暴露的健康接口；依赖层看数据库、缓存或后台任务；资源层看 NAS、磁盘、关键端口和备份任务结果。

同一个服务可以有多个监控项，但每个监控项都要有目的。只监控首页 200，能证明入口可访问；监控健康接口，能证明应用内部状态；监控证书有效期，能提前发现续期问题。把这些层次写清楚，收到告警时才知道下一步该看哪份日志。

我会给监控项命名加上层级前缀，例如 edge-域名、app-服务名、dep-数据库、job-备份任务。名称看起来朴素，但手机上收到通知时很有用，不需要打开面板就能大概判断影响范围。

监控频率也要按服务重要性调整。核心入口可以一分钟一次，低频后台和备份任务不需要过度频繁。过密的探测会制造无意义负载，也会让短暂抖动被放大成连续提醒。家庭环境里，合适的安静程度和准确性一样重要。

我也会给每个重要告警写一句处理提示，例如“先查反代日志”或“先看磁盘空间”。提醒里带下一步动作，比单纯告诉我服务离线更有用。

告警恢复后也要看恢复耗时。短暂波动可以只记录，持续故障则要补进维护笔记，方便下次按同一路径排查。

这会让告警更可用。

services:
  uptime-kuma:
    image: louislam/uptime-kuma:1
    restart: unless-stopped
    ports:
      - "3001:3001"
    volumes:
      - ./data:/app/data

告警要减少噪音

家庭网络会有短暂波动，NAS 也可能在夜间备份时负载升高。如果每次 5 秒超时都推送，几天后人就会自动忽略告警。我会给不同服务设置不同阈值：入口页面可以敏感一些，低频后台服务可以延迟几次再提醒，夜间维护窗口可以适当静默。

通知渠道要定期试响。很多人配置完通知就不再碰，等真正故障时才发现令牌过期、通道被限流或手机没有提醒权限。我会在月度巡检里手动触发一次测试，并记录最近一次成功通知时间。告警系统自己也需要被验证。

状态页只放适合公开的信息

Uptime Kuma 的状态页很方便，但公开状态页要克制。适合放的是对外服务的可用性、维护公告和简单说明，不适合暴露内网服务名、数据库名称、管理路径、家庭网络结构或具体错误细节。状态页是给使用者看的，不是给攻击者看的资产清单。

如果状态页只给家人或内部使用，也要注意权限和入口。展示“NAS 数据库离线”“密码库异常”这类信息时，外部访客不需要知道。我的做法是公开状态页只保留低敏服务，内部状态页放在受控入口后面。

监控数据也要备份

Uptime Kuma 的 ./data:/app/data 保存监控项、通知配置、状态页、历史记录和账号。迁移时不能只截图监控列表，data 目录要进入备份。恢复后要抽查通知渠道、状态页地址和关键监控项，因为很多配置和密钥类信息不适合手工重填。

升级前我会导出或备份 data 目录，升级后看日志、页面、通知测试和几条关键监控。Uptime Kuma 本身如果挂了，当然不能指望它提醒自己，所以至少要在宿主机层面保留容器重启策略，或者让另一个简单巡检脚本检查它是否在线。

从告警回到操作手册

每条重要监控最好对应一条处理动作。证书告警对应检查续期日志，HTTP 502 对应查反代上游，数据库端口失败对应查数据库容器和磁盘空间，备份失败对应查目标路径和权限。没有处理动作的告警，只会制造焦虑。

Uptime Kuma 的价值在于把故障时间点提前暴露出来，而不是替代日志、指标和备份。监控项分层、告警降噪、状态页收敛、data 目录备份，这几件事做好以后，它会成为 HomeLab 的早期提醒系统。否则绿色再多，也只是一个好看的入口页。