企业官网建设流程全解析

从静默劣化到主动告警：在群晖与 Unraid 上部署 Scrutiny 的 NAS 硬盘监控指南

【免费下载链接】scrutinyHard Drive S.M.A.R.T Monitoring, Historical Trends & Real World Failure Thresholds项目地址: https://gitcode.com/GitHub_Trending/sc/scrutiny

RAID 里某块盘悄悄劣化参数，smartd 日志无人问津，等系统告警时阵列已岌岌可危。Scrutiny 是一款 S.M.A.R.T. 监控工具：它记录硬盘参数的历史趋势，并用真实故障数据设定报警线，让 NAS 硬盘监控在数据丢失前发出信号。

一、先选定部署模式

选型只看一件事：你的盘在几台机器上。

它与传统 smartd 的核心差别就两点：数据进 Web 界面可视化，阈值参考真实世界的故障统计。

二、各平台落地步骤

通用路径：跑官方 omnibus 镜像

先在宿主机建好 config 与 influxdb 数据目录，然后运行官方 omnibus 镜像——记得加SYS_RAWIO权限、用--device逐块挂盘、映射 8080 端口，compose 样例见 docker/example.omnibus.docker-compose.yml。最后浏览器打开主机IP:8080，容器启动时会自动跑一次 collector，盘就出现在仪表盘上。

群晖：Collector 与 Container Manager 两条路线

路线 A（Entware + Collector）：先在 DSM 7 装好 Entware 以获得新版 smartmontools，用opkg install smartmontools装上工具。然后下载与你架构（arm64/amd64）匹配的 collector 二进制，放入固定目录并赋予执行权限，把示例配置存为collector.yaml，改好 host id、devices 列表和 api endpoint。最后在 DSM 控制面板 → 任务计划程序新建用户自定义脚本，以 root 身份每日执行，让 collector 定期把数据推给你另一处部署的 omnibus Hub。完整步骤在 INSTALL_SYNOLOGY_COLLECTOR.md。

路线 B（Container Manager）：DSM 装了 Container Manager 或 Docker Package 的话，直接按通用路径建一个 omnibus 容器——挂盘、开权限、映射端口，省掉 Entware 的全部折腾。

Unraid：模板一键部署

先在 Plugins 页装 Community Applications 插件，然后在应用库搜 scrutiny，选一个镜像（作者维护的 ghcr omnibus 版，或 linuxserver 的 alpine 版，镜像问题找各自维护者）。最后点 Install 即可，模板参数基本不用动。细节见 INSTALL_UNRAID.md。

其余平台

TrueNAS、QNAP、PFSense、RockStor、Windows 均有现成指引，对照 SUPPORTED_NAS_OS.md 列表查即可，步骤大同小异。

三、两个必须落地的配置

手动指定设备类型。RAID 卡后面的盘smartctl --scan常常认不出类型，数据会残缺。在 collector 配置的devices段加覆盖规则，改完重启 collector：

devices: - device: /dev/sda type: 'sat' - device: /dev/bus/0 type: - megaraid,14 - megaraid,15

完整键位说明在 example.collector.yaml。

通知渠道。Web 端scrutiny.yaml里的notify.urls基于 shoutrrr 协议：smtp://发邮件、discord:///telegram://走机器人、slack:///mattermost://推团队频道，也能用script://或普通 URL 接 Webhook。配好之后在界面上点一次"测试通知"，别等真报警时才发现渠道是死的。

四、避坑与调优

排查清单，按顺序过：

• 盘没被识别：先在宿主机跑smartctl --scan确认设备与类型正常；宿主机正常而 Scrutiny 不正常，多半是--device漏挂或权限不够。NVMe 要挂控制器/dev/nvme0而不是块设备/dev/nvme0n1，并加SYS_ADMIN。
• 数据残缺：核对 collector 配置文件路径，用DEBUG=true加COLLECTOR_LOG_FILE看日志定位。
• 报smartctl returned an error code (2)：多为设备打不开或盘处于休眠态；UAS 模式的 USB 外盘读不到 SMART 时，尝试强制切回 usb-storage 模式。
• 盘被标 failed 但 SMART 显示通过：Scrutiny 叠加了 BackBlaze 故障统计作为报警线，这是设计行为；Seagate 的 Seek/Read Error Rate 自 v0.4.13 起已豁免，历史遗留的 failed 状态可用数据库脚本重置。详见 TROUBLESHOOTING_DEVICE_COLLECTOR.md。

调优建议：

• 收集频率每日一次即可，趋势靠积累，不必高频采样。
• 阈值默认基于 BackBlaze 统计，先跑一两个月观察，再决定是否微调。
• 时序库自带周/月/年降采样桶，长期运行不用担心数据库膨胀，机制见 DOWNSAMPLING.md。
• 监控是预警不是救援：关键数据的备份不能省，Scrutiny 的告警只是给你换盘争取时间。

Scrutiny 做的事只有一件：把埋在日志里的硬盘参数变成看得懂的趋势图，并在危险逼近时先于人一步发出警报。对 NAS 用户而言，它的价值不是发现某块盘坏了，而是让备份、迁移、换盘这些动作发生在数据仍然安全的时间窗里。

【免费下载链接】scrutinyHard Drive S.M.A.R.T Monitoring, Historical Trends & Real World Failure Thresholds项目地址: https://gitcode.com/GitHub_Trending/sc/scrutiny