Docker 新手家庭实战:4 个轻量容器搭一套“故障自动提醒”闭环
很多家庭 Docker 用户都有同一个痛点:服务平时能跑,但真出故障时,往往是“家人说不能用”你才知道。这篇不讲大而全监控平台,直接给你一套新手能跑、长期能用、维护成本低的闭环方案:
- Uptime Kuma:监测服务在线状态
- Beszel:看主机与容器资源占用
- Dozzle:快速看容器日志
- ntfy:手机秒收告警通知
目标很明确:服务挂了,30 秒内手机收到提醒;5 分钟内定位到问题点。
图1:家庭告警闭环拓扑图

一、为什么选这 4 个,而不是 Prometheus 全家桶?
不是 Prometheus 不好,而是家庭场景常见问题是:
1. 机器性能有限,不想为监控本身付太高成本;
2. 使用者不是全职运维,不想维护复杂规则;
3. 要的是“快定位、快恢复”,不是做企业级报表。
这 4 个容器正好覆盖“可用性 + 资源 + 日志 + 通知”,而且部署和迁移都简单。
二、你会得到什么效果?
落地后,至少有这 4 个结果:
- 容器挂掉:Kuma 立刻标红 + ntfy 推送到手机;
- 性能异常:Beszel 看 CPU/内存/磁盘变化趋势;
- 快速排障:Dozzle 直接看容器实时日志;
- 闭环恢复:先告警,再定位,再验证恢复。
图2:异常触发到手机提醒流程图

三、最小可用 docker-compose(直接改后开跑)
yaml
version: "3.9"
services:
uptime-kuma:
image: louislam/uptime-kuma:1
container_name: uptime-kuma
ports:
- "3001:3001"
volumes:
- ./data/kuma:/app/data
restart: unless-stopped
dozzle:
image: amir20/dozzle:latest
container_name: dozzle
ports:
- "8088:8080"
volumes:
- /var/run/docker.sock:/var/run/docker.sock:ro
restart: unless-stopped
ntfy:
image: binwiederhier/ntfy:latest
container_name: ntfy
command: serve
ports:
- "8090:80"
volumes:
- ./data/ntfy:/var/lib/ntfy
restart: unless-stopped
beszel:
image: henrygd/beszel:latest
container_name: beszel
ports:
- "8091:8090"
volumes:
- ./data/beszel:/beszel_data
- /var/run/docker.sock:/var/run/docker.sock:ro
restart: unless-stopped
> 注:端口冲突时按 +10 步进递增(如 8091→8101)。
四、部署后只做这 3 件事
1)Uptime Kuma 加监控项
- 监控家庭关键服务 URL(如 NAS、下载器、照片服务)
- 间隔建议 30~60 秒
- 通知渠道接入 ntfy topic
2)ntfy 手机端订阅 topic
- 安卓/iOS 都有客户端
- 先发一条测试消息确认可达
3)Dozzle / Beszel 建立排障入口
- Dozzle:看日志关键词(error/timeout/refused)
- Beszel:看是否资源打满(CPU 100%、内存耗尽、磁盘 IO 异常)
图3:Kuma 监控面板示意

图4:Dozzle 日志排障示意

五、真实排障路径(家庭版)
举个最常见例子:家庭照片服务打不开。
1. ntfy 推送:`photo-service DOWN`;
2. 打开 Kuma:确认不是单次抖动;
3. 打开 Dozzle:看到数据库连接超时;
4. 打开 Beszel:发现主机内存接近 100%;
5. 处理(重启异常容器 / 释放资源);
6. Kuma 恢复绿色,业务恢复。
这就是闭环价值:从“被动等反馈”变成“主动发现问题”。
六、适用人群
适合:
- 家庭 NAS / Docker 常驻用户;
- 想低成本建立基础运维能力的人;
- 追求“够用 + 稳定 + 易维护”的用户。
图5:被动排障 vs 主动告警对比图

结论
这套 4 容器方案,本质是把家庭 Docker 运维从“出事再看”升级到“先告警再处理”。它不复杂,但非常实用,尤其适合新手长期跑。
作者声明本文无利益相关,欢迎值友理性交流,和谐讨论~
