Scrutiny：让硬盘在真的坏掉之前就告诉你
一句话结论
NAS 系统自带的 SMART 界面通常只能看个”正常/不正常”，而硬盘出事前的关键信号往往藏在具体属性里。Scrutiny 做的是把 SMART 数据长期存下来、画出趋势、并在越线时主动通知你。它最有价值的一点：能在硬盘自己的 SMART 总体评估仍显示”通过”时，就根据会预示故障的具体属性把它标记出来。
它比系统自带 SMART 强在哪
| 能力 | 系统自带 | Scrutiny |
|---|---|---|
| 看到当前 SMART 值 | 能 | 能 |
| 历史趋势 | 基本没有 | 有，按周按月看曲线 |
| 多块硬盘集中看 | 分散 | 一屏全览 |
| 故障预判 | 只报”已坏” | 按属性阈值提前预警 |
| 主动通知 | 部分系统有 | 支持 Telegram / 邮件 / Webhook 等 |
| 多台机器汇总 | 不支持 | 支持（收集器模式） |
最关键的是”趋势”这一项。 单次看数值意义有限，真正能预警的是”这个值在持续变差”。没有历史数据，你根本看不出趋势。
部署（单机全合一版）
一台 NAS 用一个容器搞定，官方叫 omnibus 版：
services:
scrutiny:
image: ghcr.io/analogj/scrutiny:master-omnibus
container_name: scrutiny
restart: unless-stopped
ports:
- "8080:8080"
volumes:
- /run/udev:/run/udev:ro
- ./config:/opt/scrutiny/config
- ./influxdb:/opt/scrutiny/influxdb
cap_add:
- SYS_RAWIO
- SYS_ADMIN
devices:
- /dev/sda
- /dev/sdb
environment:
- TZ=Asia/Shanghai启动后访问 `http://NAS的IP:8080`。
几个参数为什么必须这么写
这段是部署里最容易出错的部分，值得单独说：
`devices` 要显式列出每块盘。 Scrutiny 底层靠 smartctl 读盘，需要打开原始设备句柄，所以每块要监控的盘都得列出来。盘多的话可以用 `privileged: true` 加 `/dev:/dev` 映射代替，但显式列出更安全，建议坚持显式。
`cap_add: SYS_RAWIO` 必须有。 这是读取 SMART 数据所需的能力。`SYS_ADMIN` 只在有 NVMe 盘时才需要。
`/run/udev` 只读挂载。 用来获取硬盘序列号等硬件元数据，没有它仪表盘上的设备信息会不完整。
两个目录要备份：`config`（配置）和 `influxdb`（历史数据）。历史趋势数据全在 influxdb 里，这个目录丢了趋势就断了。
怎么看你该盯哪几个值
Scrutiny 会给每块盘一个状态：Passed（正常）、Failed (SMART)（硬盘自己报失败）、Failed (Scrutiny)（硬盘自评正常，但 Scrutiny 判断有风险）。
第三种状态是它最有价值的输出。日常真正需要盯的属性，按与故障的相关程度排：
| 属性 | ID | 该怎么看 |
|---|---|---|
| Reallocated Sector Count | 5 | 任何非零值都值得关注，持续上升是很强的信号 |
| Current Pending Sector Count | 197 | 疑似坏道但还没重映射，持续不清零是坏信号 |
| Reported Uncorrectable Errors | 187 | 纠错都救不回来的读取失败 |
| Uncorrectable Sector Count | 198 | 同上，盘在打一场赢不了的仗 |
| Command Timeout | 188 | 响应超时。偶发可能是线材或供电问题，不一定是盘坏了 |
一条重要经验：看这些值要看趋势和组合，不要看到非零就立刻换盘。比如 5 号属性稳定在个位数不增长，通常是早期已经处理过的问题；而 197 持续存在且多次采集都不清零，才真的要紧张。
采集频率：默认是每天一次
容器起来后默认每天采集一次。想改频率，加环境变量：
environment:
- COLLECTOR_CRON_SCHEDULE=0 */6 * * *不想等的话可以手动跑一次：
docker exec scrutiny /opt/scrutiny/bin/scrutiny-collector-metrics run第一次部署完建议手动跑一次，这样立刻能看到盘，不用等到第二天。
通知一定要配，否则等于没装
跟所有监控类应用一样：不配通知，你不会天天去打开仪表盘看。
在 `config/scrutiny.yaml` 里配置，它用的是 apprise 风格的 URL，一条搞定一种渠道：
notify:
urls:
- "tgram://你的bottoken/chatid"配完建议测一下：温度超过阈值或 Pending Sector 增加时，你会立刻收到消息。一次没响过的告警，先怀疑通知没配通，而不是怀疑硬盘太健康。
多台 NAS 怎么处理
如果你有不止一台机器，用收集器模式更合理：一台机器跑 Web 界面做中心，其他机器只跑收集器，把数据推到中心。
其他机器上只需要跑收集器容器，配 `COLLECTOR_API_ENDPOINT` 指向中心机的地址，并列出本机的硬盘设备。这样所有盘在一张仪表盘上看，不用挨个 SSH 进去跑 smartctl。
常见坑
仪表盘是空的。 先手动跑一次采集命令，再等一两分钟刷新。omnibus 版第一次启动会自动跑，但如果设备没列对就不会有数据。
看不到盘或看不到温度。 大概率是 `devices` 没列全，或者 `SYS_RAWIO` 没加。NVMe 盘还额外需要 `SYS_ADMIN`。
容器起不来。 检查 `devices` 里写的设备路径是否真实存在，可以用 `lsblk` 先确认盘符。
权限不足。 它需要直接读块设备，权限给不到位就读不到数据。安全原则上是只给它需要的设备，不要图省事直接开 privileged。
小结
硬盘是 NAS 上唯一会”物理性死亡”的部件，而它的死法通常是渐进的——SMART 值在几周甚至几个月里慢慢恶化。Scrutiny 的价值就是把这条恶化曲线画出来，并在越线时喊你一声。 装它的成本不高，但它可能是你 NAS 上唯一一个能在数据丢失前救你一次的应用。
