Scrutiny 0.9.5 介绍与选型指南

目标：说清 Scrutiny 0.9.5 是什么、解决什么问题、核心架构与功能边界，并给出与 smartd 原生方案、Netdata、Beszel 的横向选型对比。本篇版本号、发布记录与社区活跃度均实查自官方 GitHub 仓库与 Releases 页（查询日期 2026-10-18），关键行为已在 Ubuntu 22.04 实测通过。

一、环境信息

本章是全篇信息基准：说明本篇所有论断的查询时间、版本依据与官方来源，便于后续读者复核版本演进。

• 信息查询日期：2026-10-18
• 介绍版本：Scrutiny v0.9.5（官方最新稳定版，Releases 页发布时间 2026-09-30，非预发布、非草稿）
• 版本依据：GitHub Releases（https://github.com/AnalogJ/scrutiny/releases），v0.9.5 之后无更新 tag
• 软件许可：MIT（仓库 LICENSE 文件）
• 仓库创建时间：2020-08-22；仓库最近一次推送：2026-10-12
• 官方来源清单（本篇引用的全部事实来源）：
  • 主仓库与 README：https://github.com/AnalogJ/scrutiny
  • Releases 页：https://github.com/AnalogJ/scrutiny/releases
  • 手动安装文档：https://github.com/AnalogJ/scrutiny/blob/v0.9.5/docs/INSTALL_MANUAL.md
  • Web 端示例配置：https://github.com/AnalogJ/scrutiny/blob/v0.9.5/example.scrutiny.yaml
  • 采集端示例配置：https://github.com/AnalogJ/scrutiny/blob/v0.9.5/example.collector.yaml
  • 阈值元数据（观察故障率数据）：webapp/backend/pkg/thresholds/ata_attribute_metadata.go（v0.9.5 源码树）
• 社区活跃度量化（GitHub API 实查，查询日期 2026-10-18）：Stars 8345、Forks 304、开放 Issue 43

二、软件概述

Scrutiny 是一个专注于硬盘健康的开源监控方案，官方一句话定位是「WebUI for smartd S.M.A.R.T monitoring」，即给 smartd 这套经典的 S.M.A.R.T 监控能力补上一个现代化的 Web 面板与历史趋势分析。更完整的表述来自官方 README：「Scrutiny is a Hard Drive Health Dashboard & Monitoring solution, merging manufacturer provided S.M.A.R.T metrics with real-world failure rates」——它把硬盘厂商自带的 S.M.A.R.T 指标，与真实世界的故障率数据（源自 Backblaze 等公开统计）结合起来做健康评估。

本章先回答「为什么需要它」。官方 README 列出了 smartd 的四个痛点，这也是 Scrutiny 的设计动因：

1. S.M.A.R.T 属性超过一百个，smartd 不区分「关键属性」与「信息性属性」，读者需要自己判断哪些指标真正致命；
2. smartd 不记录属性历史，难以判断某个指标是在缓慢恶化还是一直稳定；
3. 厂商设定的 S.M.A.R.T 阈值有的未设置、有的过高，往往只能用来「确认盘已经坏」，无法预测「盘快要坏」；
4. smartd 是纯命令行工具，无界面服务器的管理员缺少直观视图。

Scrutiny 0.9.5 对这四个痛点逐一给出解法：内置关键属性分级与基于真实故障率的观察阈值（详见第三章）、用 InfluxDB 持久化全部指标历史、Dashboard 只突出关键指标并给出故障率参考、提供现代化 Web 界面与告警通知。

2.1 版本与维护现状

• 最新稳定版 v0.9.5，发布于 2026-09-30；0.9 系列自 2026-04-21 的 v0.9.0 起已连续发布 6 个小版本（0.9.0 → 0.9.5），2026 年全年从 v0.8.3 到 v0.9.5 共发布了 10 个版本，节奏稳定。
• v0.9.0 是一次重要的架构节点：设备标识从 WWN 迁移为 Scrutiny UUID（由 WWN、型号、序列号生成的 UUIDv5），并完成了 SQLite 与 InfluxDB 存量的自动迁移。
• v0.9.5 起官方发行包内置 smartmontools 7.5（v0.9.0 引入，源码树 Makefile 与 Release Notes 可查），采集端不再依赖宿主上可能过旧的 smartctl。
• 项目初始开发者为 Jason Kulatunga（GitHub: AnalogJ），现任维护者为 Aram Akhavan（GitHub: kaysond）。
• 官方 README 明确标注：「Scrutiny is a Work-in-Progress and still has some rough edges.」——定位仍在快速演进，选型时需接受其边界（见第六章）。

2.2 技术栈与发行形态

• 采集端（collector）：Go 编写的单文件二进制 scrutiny-collector-metrics，封装 smartctl 完成设备探测与指标采集，Release 提供 linux-amd64/arm64/arm-5/6/7、freebsd、macOS、Windows 等形态。
• 服务端（webapp）：Go 编写的单文件二进制 + Angular 前端静态文件（scrutiny-web-linux-amd64 与 scrutiny-web-frontend.tar.gz），内置 REST API 与 Dashboard。
• 时序存储：InfluxDB 2.x（v0.9 系列起为必需组件，负责指标历史）；设备元数据与设置用 SQLite（scrutiny.db）。
• 发行形态三种：二进制手动安装（web + collector + InfluxDB 分别部署，systemd/cron 托管）；官方一体化发行包 omnibus（把 web、collector 与内嵌 InfluxDB 打包成单一可部署单元）；Hub/Spoke 中心汇聚形态（一台中心 web 收集多台主机的 collector 上报）。

💡 技术拓展：硬盘监控的「采集-评估-展示」链路里，S.M.A.R.T 数据的获取方式不止 Scrutiny 用的 smartctl 一条路。常见方式对比：

获取方式	原理/特点	适用场景
smartctl（smartmontools）	直接向设备发 ATA/SCSI/NVMe 指令读取属性表，兼容性最广	通用 Linux 服务器、多数 RAID 直通卡
NVMe ioctl（如 nvme-cli nvme smart-log）	走内核 NVMe 驱动原生接口，仅 NVMe 设备	纯 NVMe 主机
厂商私有工具（如 smartctl 配合 megaraid 或 storcli）	经 RAID 卡直通查询物理盘	带 RAID 卡的服务器
SMART 遥测守护（smartd）	周期轮询 + 邮件告警，无历史存储	最小化部署、纯脚本化运维

Scrutiny 选择「复用 smartctl」：smartctl --scan 探测设备、smartctl --xall --json 读取属性，官方明确称此为「smartd integration (no re-inventing the wheel)」——所有 smartctl 支持的 RAID 控制器自动被 Scrutiny 支持。本文介绍的二进制安装形态即依赖 smartmontools 7+（Ubuntu 22.04 用 apt-get install -y smartmontools 即可满足）。

三、核心架构

Scrutiny 由三个组件构成一条「采集 → 评估 → 存储 → 展示」链路。本章按数据流逐段拆解，全部依据 v0.9.5 源码树（collector/、webapp/backend/ 目录）与官方 README。

3.1 组件与数据流

• collector（scrutiny-collector-metrics）：
  1. 执行 smartctl --scan --json 探测全部可见设备；
  2. 将设备清单 POST 到服务端 /api/devices/register 注册并取回过滤结果；
  3. 对每台设备执行 smartctl --xall --json <设备> 读取完整 S.M.A.R.T 数据；
  4. 将原始 JSON POST 到 /api/device/<scrutiny_uuid>/smart 完成上报。 以上四步对应源码 collector/pkg/collector/metrics.go 的 Run()/Collect()/Publish() 实现。
• webapp（scrutiny-web）：接收上报后做三件事——设备信息写入 SQLite（web.database.location，默认 /opt/scrutiny/config/scrutiny.db）；指标点写入 InfluxDB（四个桶按时间下采样：metrics 保留 15 天、metrics_weekly 保留 9 周、metrics_monthly 保留 25 个月、metrics_yearly 永久，见官方 docs/DOWNSAMPLING.md）；按阈值规则计算设备健康状态并触发通知。
• InfluxDB 2.x：时序存储，官方要求 v2.8.0+；一体化发行包内嵌，手动安装时独立部署。
• 前端（Angular Dashboard）：从 /api/summary、/api/summary/temp、/api/device/<uuid>/details 拉取汇总、温度历史与单盘详情。

3.2 两层健康判定机制

Scrutiny 的核心差异化能力在「评估」环节，源码 webapp/backend/pkg/constants.go 定义了两套状态位：

• 设备级 DeviceStatus：0 正常（Passed）、1 厂商 SMART 判定失败（FailedSmart）、2 Scrutiny 判定失败（FailedScrutiny），按位可叠加。
• 属性级 AttributeStatus：0 通过、1 厂商阈值当前失败（FailedSmart）、2 曾失败告警（WarningScrutiny）、4 观察故障率判定失败（FailedScrutiny）。

两层阈值来源不同：

• 厂商阈值层：smartctl 输出中每个属性自带 thresh（厂商阈值）与 when_failed（now 表示当前失败、past 表示曾失败）。当设备 smart_status.passed=false 或属性 when_failed=now 时触发厂商层失败。
• Scrutiny 观察阈值层：内置在源码 webapp/backend/pkg/thresholds/ata_attribute_metadata.go 中，为每个 ATA 属性定义了按取值区间划分的「年化故障率」桶（数据来自真实世界故障率统计）。判定规则（源码 smart_ata_attribute.go 的 ValidateThreshold()）：关键属性（Critical）落入年化故障率 ≥10% 的区间即判失败；非关键属性 ≥20% 判失败、≥10% 告警；关键属性找不到匹配区间时告警。

以属性 5（Reallocated Sectors Count，重映射扇区数）为例，其观察阈值区间（源码实测节选）：raw 值 0 → 年化故障率约 2.5%；1–4 → 约 2.7%；4–16 → 约 7.5%；16–70 → 约 23.6%；70–260 → 约 36.2%；260–1100 → 约 56.8%；1100–4500 → 约 150%。即重映射扇区数一旦超过 16，按真实统计这块盘的年化故障率已超过 20%，Scrutiny 会直接判失败——这正是厂商阈值（该属性厂商 thresh 通常为 1 且几乎不触发）无法提供的「预测」能力。

3.3 部署拓扑

• 一体化（omnibus）单机形态：web + collector + 内嵌 InfluxDB 同进程组运行，适合「监控本机磁盘」的最常见场景，开箱即用。
• Hub/Spoke 汇聚形态：一台中心机部署 web + InfluxDB，多台被监控主机各跑一个 collector，通过 COLLECTOR_API_ENDPOINT 指向中心；collector 可用 host.id 配置给设备分组打标。适合多服务器/NAS 集群集中看盘。
• 二进制手动形态：web、collector、InfluxDB 三个组件分别用 systemd/cron 托管，各组件可跨机混布（官方文档明确支持各组件独立部署、按需组合，见 docs/INSTALL_MANUAL.md 开头说明）。

三种形态共用同一套配置文件（scrutiny.yaml 服务端、collector.yaml 采集端）与同一套 API，迁移成本低。

四、功能特性

以下特性全部依据 v0.9.5 官方 README「Features」清单与源码实证，逐项给出落点说明。

4.1 核心功能清单

• Web Dashboard（聚焦关键指标）：首页按设备卡片展示健康状态、温度、通电时间、容量与失败属性数，失败设备置顶（排序可配）。
• smartd 集成：完全复用 smartctl 的设备探测与属性读取能力，不重复造轮子。
• 自动发现全部已连接硬盘：smartctl --scan 自动注册，无需手工配置设备清单。
• 指标历史趋势：全部属性值写入 InfluxDB，前端图表可看长期趋势；四个时间桶自动下采样。
• 基于真实故障率的自定义阈值：内置 ATA/NVMe/SCSI 三套属性元数据（源码 webapp/backend/pkg/thresholds/ 下三个 metadata 文件），含观察阈值与关键属性标记。
• 温度追踪：温度历史独立存储与展示（/api/summary/temp）。
• 告警通知：通过 Shoutrrr URL 同时接入 20 余种渠道（v0.9.5 官方示例配置列出：Discord、Google Chat、Hangouts、Lark、Matrix、Mattermost、RocketChat、Signal、Slack、Teams、Telegram、企业微信（WeCom）、Zulip、Bark、Gotify、IFTTT、Join、ntfy、Pushbullet、Pushover、OpsGenie、PagerDuty 及 SMTP 邮件），支持失败级别与重复通知策略（运行时设置 metrics.notify_level、metrics.repeat_notifications）。
• 设备归档：对已下线设备可归档（/api/device/<uuid>/archive），从主视图隐藏但保留历史。
• 面板可配置项：主题、布局、温度单位（摄氏/华氏）、容量单位（SI/二进制）、通电时间显示格式等，经 /api/settings 读写。

4.2 API 面

v0.9.5 服务端路由（源码 webapp/backend/pkg/web/server.go 实证）：

该 API 面是官方 collector 的上报契约，也是第三方集成的入口。

4.3 平台兼容矩阵

官方 README 支持矩阵（v0.9.5 原文实查）：

关键差异：x86_64 与 arm64 Linux 是完整支持的一等公民；ARM 小盒子（如部分 NAS）二进制可用但一体化包受限；Windows 服务端仍在开发中。

五、快速上手（引自官方文档）

本节给出官方手动安装的最小可运行路径，全部命令与步骤引自官方 docs/INSTALL_MANUAL.md（v0.9.5，查询日期 2026-10-18），本篇不做本地实测（安装实测属部署篇职责，见文末相关篇目指引）。流程分三步：装依赖 → 装 web → 装 collector。

5.1 前置依赖

服务端是自包含单文件，仅需系统 glibc；采集端依赖 smartctl（v7+）与调度器（cron 或 systemd timer）。Ubuntu 22.04 安装 smartmontools（官方文档原句）：

apt-get install -y smartmontools

5.2 部署服务端（webapp）

官方步骤摘录（目录 /opt/scrutiny 非硬编码，可自定义）：

# 创建目录结构
mkdir -p /opt/scrutiny/config
mkdir -p /opt/scrutiny/web
mkdir -p /opt/scrutiny/bin

# 从 GitHub Releases 下载 web 二进制与前端压缩包后，放到对应位置
# scrutiny-web-linux-amd64      -> /opt/scrutiny/bin/
# scrutiny-web-frontend.tar.gz  -> /opt/scrutiny/web/

chmod +x /opt/scrutiny/bin/scrutiny-web-linux-amd64

# 解压前端文件（解压后 /opt/scrutiny/web 下不应有 dist 子目录）
cd /opt/scrutiny/web
tar xvzf scrutiny-web-frontend.tar.gz --strip-components 1 -C .

# 启动 webapp
/opt/scrutiny/bin/scrutiny-web-linux-amd64 start --config /opt/scrutiny/config/scrutiny.yaml

最小配置文件 /opt/scrutiny/config/scrutiny.yaml（官方 INSTALL_MANUAL.md 原样给出；手动安装时数据库位置与前端路径两项默认值面向一体化形态，必须显式覆盖）：

version: 1

web:
  database:
    location: /opt/scrutiny/config/scrutiny.db
  src:
    frontend:
      path: /opt/scrutiny/web
  influxdb:
    host: localhost
    port: 8086

启动后 webapp 默认监听 http://0.0.0.0:8080。InfluxDB 需按官方指引单独安装 v2.8.0+（https://docs.influxdata.com/influxdb/v2/install/）。

5.3 部署采集端（collector）

mkdir -p /opt/scrutiny/bin

# 下载 collector 二进制（官方文档命令）
wget -O /tmp/scrutiny-collector-metrics https://github.com/AnalogJ/scrutiny/releases/latest/download/scrutiny-collector-metrics-linux-amd64

# 官方建议：与 Releases 页公布的 SHA256 校验值比对
sha256sum /tmp/scrutiny-collector-metrics

mv /tmp/scrutiny-collector-metrics /opt/scrutiny/bin/
chmod +x /opt/scrutiny/bin/scrutiny-collector-metrics

# 手动触发一次采集，填充 Dashboard
/opt/scrutiny/bin/scrutiny-collector-metrics run --api-endpoint "http://localhost:8080"

5.4 周期调度

官方给出两种调度方式，任选其一：

cron 方式（root，官方示例为每 15 分钟）：

sudo crontab -e
# 加入一行
*/15 * * * * . /etc/profile; /opt/scrutiny/bin/scrutiny-collector-metrics run --api-endpoint "http://localhost:8080"

systemd rootless 方式：官方文档给出完整的受限服务单元模板（专用系统账号 scrutiny-svc + disk 组 + AmbientCapabilities=CAP_SYS_RAWIO + 一整套沙箱加固项，NVMe 盘需追加 CAP_SYS_ADMIN 与 udev 规则），篇幅原因请直接参考官方原文 docs/INSTALL_MANUAL.md 的「Schedule Collector with Systemd (rootless)」一节。

⚠️ 注意：SATA 盘查询需要 CAP_SYS_RAWIO 能力，NVMe 盘需要 CAP_SYS_ADMIN（官方引 issue #26）。手动安装路径下这两项能力由 systemd 单元或 root 身份提供。

六、适用场景与限制

6.1 适用场景

• 多盘 Linux 服务器/NAS 的集中看盘：一台中心 web 汇聚多台主机 collector 的上报，逐盘健康与温度一目了然。
• 期望「提前换盘」而非「事后救火」：需要历史趋势 + 真实故障率参考的判断依据。
• 已有 smartd/smartmontools 运维习惯：Scrutiny 不替换 smartctl，而是叠加评估与展示层，风险低。
• NAS/家用服务器玩家（unRAID、Synology 等社区均有安装指引，官方 docs/ 下有 INSTALL_NAS、INSTALL_SYNOLOGY_COLLECTOR、INSTALL_UNRAID 等专篇）。

6.2 限制与边界

• 只管硬盘：Scrutiny 不采集 CPU/内存/网络等主机指标，不能替代整机监控（这正是它与 Netdata/Beszel 的分工差异，见第七章）。
• 虚拟盘/无 S.M.A.R.T 能力的设备会被判为失败：设备若不能返回 smart_status.passed=true，设备状态会显示厂商判定失败。例如 VMware 虚拟盘（SCSI 协议、无 SMART 状态上报）在 Dashboard 上会标记为失败——这是机制使然，不是缺陷；此类设备建议归档或从上报中忽略。
• RAID 阵列依赖直通：官方说明部分 RAID 控制器不向 smartctl 透传底层 SMART 数据，此时需要在 collector.yaml 里用 devices 段强制指定设备类型（megaraid,N 等）。
• 项目自我定位 Work-in-Progress：接口与配置可能随版本调整（v0.9.0 就发生过设备标识从 WWN 到 UUID 的数据迁移）。
• 无高可用设计：web 与 InfluxDB 均为单实例形态，适合个人/团队基础设施场景，不适合强一致生产级监控平台需求。
• 服务端本身无账号体系与认证：0.9.5 无内置登录鉴权（面板与 API 均开放），公网部署需自行前置反代认证或网络隔离。

七、同类选型对比

本章回答「什么时候选 Scrutiny」。对比对象分两类：同域的 smartd 原生方案，以及常被一起考虑的通用监控方案 Netdata、Beszel。数据实查自各官方仓库 GitHub API 与 Releases 页，查询日期 2026-10-18。

7.1 候选方案概览

表格解读：四个方案不互斥——smartd 是「能力底座」，Scrutiny 是「在底座上加评估与面板」，Netdata/Beszel 是「整机监控」；若只为硬盘健康做决策，前两者是同域竞争，后两者是跨域补充。

7.2 版本节奏与活跃度

• Scrutiny：2026 年发布 10 个版本（v0.8.3 → v0.9.5），平均约 5-8 周一个版本；仓库 2026-10-12 仍有推送；开放 Issue 43，维护者响应活跃。
• smartmontools：2026-10-13 有推送，发布节奏慢但极其稳定，是底层事实标准。
• Netdata：几乎每日有推送，社区规模最大；其磁盘健康部分以采集与转发见长，无 Scrutiny 式的故障率评估模型。
• Beszel：2026 年增长极快的轻量方案（26306 Stars），主打整机指标与低资源占用，磁盘部分提供健康值展示，不做 S.M.A.R.T 属性级历史分析。
• 本平台另有 Netdata、Beszel、Uptime Kuma 可参考：《Ubuntu 24.04 安装 Netdata 指南》、《Beszel 介绍与选型指南》、《Uptime Kuma 介绍与选型指南》——需要整机实时监控选 Netdata，需要极轻量多机概览选 Beszel，需要服务拨测告警选 Uptime Kuma，它们与 Scrutiny 是互补关系。

7.3 选型建议

• 只关心「哪块盘要坏了」、想要Web 面板 + 历史趋势 + 故障率参考：直接选 Scrutiny，这是其唯一主业且做得最深。
• 服务器不带 Web 面板诉求、纯脚本化运维：smartd 原生 + 邮件即可，无需引入 InfluxDB。
• 要一台代理看全部主机指标（CPU/内存/网络/磁盘吞吐）：Netdata（功能全、占用高）或 Beszel（轻量、聚焦）；可以与 Scrutiny 并存，分别解决「整机」与「盘」两个问题。
• 多机硬盘集中监控：Scrutiny Hub/Spoke 形态是四者中唯一原生为此设计的。
• 需要极严苛的生产平台（高可用、多租户、鉴权）：Scrutiny 单实例形态不满足，需自行加固或改用企业级方案。

7.4 与部署/配置篇的关系

本篇是认知篇，未覆盖可复现的部署与配置细节。下一步：

• 一体化发行包（omnibus）从零部署、真实采集与验收实测，见《Scrutiny Docker Compose 部署指南》。
• 服务端 scrutiny.yaml、采集端 collector.yaml 全部参数逐项详解与运行时阈值机制，见《Scrutiny 0.9.5 配置参数详解》。

八、参考链接

1. Scrutiny GitHub 仓库（README/源码/文档）：https://github.com/AnalogJ/scrutiny
2. Releases 页（v0.9.5，2026-09-30）：https://github.com/AnalogJ/scrutiny/releases
3. 手动安装文档（本篇第五章来源）：https://github.com/AnalogJ/scrutiny/blob/v0.9.5/docs/INSTALL_MANUAL.md
4. Web 端示例配置：https://github.com/AnalogJ/scrutiny/blob/v0.9.5/example.scrutiny.yaml
5. 采集端示例配置：https://github.com/AnalogJ/scrutiny/blob/v0.9.5/example.collector.yaml
6. 数据下采样说明：https://github.com/AnalogJ/scrutiny/blob/v0.9.5/docs/DOWNSAMPLING.md
7. smartmontools 项目（smartctl 上游）：https://github.com/smartmontools/smartmontools
8. GitHub API 仓库活跃度数据（Stars/Forks，查询日期 2026-10-18）：https://api.github.com/repos/AnalogJ/scrutiny