外观
监控与告警
监控的唯一目的是：在问题变成事故之前，让你知道。 没有送达的告警等于没有监控。
第一步：把通知渠道配通
这是所有监控的前提，也是最容易被跳过的一步。
- 在系统通知设置中配置渠道（邮件、推送等）。用邮件的话，见开启邮件通知并完成发送测试——注意那里填的是授权码，不是邮箱登录密码。
- 发一条测试通知，确认能在手机上收到。
- 确认通知不会被归类到垃圾邮件——如果会，它和没配一样。
定期验证通知还活着
邮箱密码变更、推送服务下线、应用被卸载，都会让告警静默失效。每隔几个月手动触发一次测试，比出事时才发现要好。
邮件通道还承担着双重验证紧急验证码和重置密码邮件，所以它的优先级比「告警」本身更高，建议装好系统后就配掉。
第二步：该监控什么
按重要性排序：
| 监控项 | 为什么重要 | 阈值建议 |
|---|---|---|
| 存储空间剩余容量 | 空间写满会让所有服务一起故障 | 剩余 15% 时告警 |
| 硬盘 SMART 异常 | 提前几周发现硬盘劣化 | 任何新增的重映射或待定扇区 |
| 存储空间状态 | 降级意味着冗余已经用掉了 | 任何非正常状态 |
| 备份任务结果 | 静默失败最常见 | 每次失败都通知 |
| 系统温度 | 长期高温缩短硬件寿命 | 硬盘 45 °C，CPU 按平台 |
| 关键服务是否在线 | 容器可能悄悄退出 | 连续两次探测失败 |
系统内置的告警覆盖前五项，第六项需要额外的工具。
第三步：服务可用性监控
内置监控关注的是硬件和系统，但「容器还在运行」不等于「服务还能用」——一个卡住的应用，容器状态可能一直是正常的。
Uptime Kuma 是一个轻量的解法：定期请求每个服务的地址，失败时推送通知。配置要点：
- 检测间隔 60 秒左右即可，太频繁只会增加负载。
- 设置「连续失败 N 次才告警」，避免网络抖动导致误报。
- 把它自己的通知渠道和系统的分开——如果 NAS 整体故障，它也发不出通知，所以最好把它部署在别处，或者接受这个局限。
告警疲劳是真实的问题
如果每天收到十条通知，你很快会开始忽略它们，然后错过真正重要的那一条。控制方法：
- 只对需要你采取行动的事件告警。CPU 偶尔飙高不需要通知。
- 设置合理的阈值和连续失败次数。
- 定期回顾：过去一个月收到的告警里，有几条你实际做了处理？没做处理的那些，把它们关掉。
更进一步
需要历史曲线和趋势分析时，可以上 Prometheus + Grafana 的组合。但对家庭 NAS 来说，这套东西的维护成本往往高于它带来的价值。先把基础告警做扎实，确实需要看趋势时再考虑。
检查结果
- 手动触发一次测试通知，在手机上收到。
- 制造一次真实的失败（例如临时改掉备份任务的目标路径），确认收到告警。
- 列出当前启用的所有告警项，确认每一项你都会采取行动。