Scrutiny 硬盘健康监控使用 Ansible Playbook 一键自动化部署scrutiny-playbook 实战指南【免费下载链接】scrutinyHard Drive S.M.A.R.T Monitoring, Historical Trends Real World Failure Thresholds项目地址: https://gitcode.com/GitHub_Trending/sc/scrutiny导读本文介绍如何利用社区维护的 Ansible Playbookscrutiny-playbook在目标机器上自动化部署 Scrutiny——一个以 S.M.A.R.T 数据为基础、结合真实世界故障率阈值来监控硬盘健康状态的 Web 监控方案。相比于 手动安装指南 中逐组件手工配置 InfluxDB、Webapp/API 与 Collector 的方式Ansible 方案将整个过程收敛为一条ansible-playbook site.yml命令。读完本文你将掌握通过 Ansible 快速搭建 Scrutiny、理解其自动化背后覆盖的组件与配置、验证部署结果并了解每日自动采集指标的调度机制。一、为什么选择 Ansible 方式部署 ScrutinyScrutiny 不是一个单一二进制程序它由三个核心组件构成详见 手动安装文档InfluxDB 数据库持久化存储各硬盘的 S.M.A.R.T 时序指标需要 v2.2.0 版本Webapp/API提供 Web 前端与后端 API监听8080端口Collector 采集器调用smartctlv7读取硬盘 S.M.A.R.T 数据并上报给 Webapp/API。手动安装需要依次完成 InfluxDB 安装、Webapp 目录结构与配置文件准备、二进制与前端资源下载、Collector 部署以及 cron 调度配置等大量重复性工作。社区成员 Zorlin 开发并持续维护的scrutiny-playbook正是为了将这些手工步骤自动化而生的 Ansible 角色/Playbook。它适用于希望在多台机器上以可重复、可版本化的方式部署 Scrutiny 的场景尤其适合需要管理多台服务器、希望将部署配置纳入基础设施即代码IaC体系的用户。二、使用 Playbook 的完整步骤根据 INSTALL_ANSIBLE.md 的说明整个过程非常简单只有四步步骤 1获取 Playbook 副本首先需要把 scrutiny-playbook 仓库克隆或拷贝到你的控制节点上。这是唯一需要手动完成的准备工作。步骤 2按照 Playbook 仓库中的说明进行配置获取 Playbook 后需要阅读其仓库自带的说明文档完成必要的前置配置。结合 Scrutiny 本身的部署要求这些配置通常至少涉及目标主机清单Inventory声明要部署 Scrutiny 的目标机器地址、SSH 登录凭据InfluxDB 相关设置Scrutiny 要求 InfluxDB v2.2.0见 手动安装文档Playbook 需要能访问或安装该版本设备与权限设置Collector 需要访问/dev/*下的硬盘设备并具备读取 S.M.A.R.T 数据的权限手动部署时smartctl需要 root 或相应能力参见 example.collector.yaml 中的commands配置API 端点配置Collector 必须知道 Webapp/API 的地址才能上报数据对应 Collector 配置中的api.endpoint默认值为http://localhost:8080见 collector 配置源码。步骤 3运行 Playbook配置完成后在控制节点上执行ansible-playbook site.yml该命令会按照 Playbook 的定义在目标机器上依次完成 Scrutiny 全部组件的安装与配置。如果后续需要重新部署或更新配置重新运行同一条命令即可。步骤 4访问部署结果部署完成后打开浏览器访问http://your-machine:8080将 your-machine 替换为实际的目标机器地址。此时即可看到 Scrutiny 的仪表盘其中会列出所有被检测到的硬盘及其当前 S.M.A.R.T 状态。手动安装文档也确认了这一点Webapp 默认监听http://0.0.0.0:8080见 手动安装文档 的Start Scrutiny Webapp章节。三、Playbook 背后自动化了什么与手动安装流程的对照要真正理解 Ansible 方案的价值最好把它与手动安装流程逐项对照。Playbook 自动化的正是 手动安装文档 中描述的全部步骤主要包括手动安装步骤Ansible Playbook 自动化后的效果安装并初始化 InfluxDB v2.2Playbook 自动安装/配置 InfluxDBScrutiny 会自行完成数据库 setup 并回写 token、org、bucket 信息创建/opt/scrutiny/{config,web,bin}目录结构Playbook 自动创建标准目录结构编写 scrutiny.yaml 配置文件数据库位置、前端资源路径、InfluxDB 连接信息Playbook 自动生成配置并落到正确位置从 Release 下载scrutiny-web-linux-amd64与scrutiny-web-frontend.tar.gz并解压Playbook 自动下载、赋予执行权限chmod x并解压前端资源以scrutiny-web-linux-amd64 start --config ...启动 WebappPlaybook 将 Webapp 注册为系统服务并启动下载scrutiny-collector-metrics-linux-amd64Playbook 自动安装 Collector 二进制以scrutiny-collector-metrics run --api-endpoint http://localhost:8080手动触发采集Playbook 自动配置调度任务无需手动触发通过crontab -e手工添加定时任务Playbook 自动写入并启用 cron 调度从 Collector 入口源码 可以看到Collector 默认会从/opt/scrutiny/config/collector.yaml读取配置因此 Playbook 将配置文件放置在该标准路径下即可被自动识别run子命令支持--api-endpoint、--host-id、--config、--debug、--log-file等参数并支持通过COLLECTOR_API_ENDPOINT、COLLECTOR_HOST_ID等环境变量注入这些都为 Playbook 的变量化配置提供了接口。四、自动采集机制每天凌晨 1 点拉取指标安装文档特别强调了一个开箱即用的行为部署完成后Scrutiny 会自动每天一次从目标机器拉取指标时间点为凌晨 1:00at 1am。这一行为本质上是通过 cron 调度 Collector 实现的。从仓库中的 cron 模板 可以看到其实现细节{COLLECTOR_CRON_SCHEDULE} root . /env.sh; /opt/scrutiny/bin/scrutiny-collector-metrics run /proc/1/fd/1 2/proc/1/fd/2即每条调度任务实际执行的是scrutiny-collector-metrics run命令不加任何参数时使用配置文件中默认的api.endpoint。容器镜像默认的调度表达式是0 0 * * *每天午夜并可通过COLLECTOR_CRON_SCHEDULE环境变量覆盖见 README.md 的 Cron Schedule 章节而 Ansible Playbook 则进一步将调度时间设定为文档所述的每天凌晨 1:00。需要特别说明的两点首次采集需要手动触发或等待调度无论是 Ansible 还是手动部署Collector 的职责都是被调度器周期性触发它本身不常驻后台。手动部署时文档明确建议先用run命令手动触发一次让仪表盘尽快有数据可看见 手动安装文档 的Start Scrutiny Collector, Populate Webapp章节cron 是 Collector 的硬依赖Collector 的依赖只有smartctlv7与cron或其他进程调度器。Ansible 方案自动完成了这两项依赖的安装与调度写入。五、部署后验证与日常使用5.1 验证安装是否成功访问仪表盘打开http://your-machine:8080首次访问时若 Collector 尚未运行仪表盘可能为空待第一次采集完成后应能看到全部硬盘列表及 S.M.A.R.T 状态此行为在 README.md 的 Usage 章节有明确描述。查看采集日志Collector 支持通过--debug/DEBUGtrue环境变量开启调试日志或通过--log-file/COLLECTOR_LOG_FILE将日志写入文件见 Collector 源码便于排查采集异常。5.2 确认指标确实来自目标机器在多主机Hub/Spoke场景下每台机器可以部署一个 Collector 采集本机硬盘数据并上报到中央 Webapp。此时可通过 Collector 配置中的host.id字段为不同主机打标签用于区分设备归属参见 example.collector.yaml 的host.id说明。手动安装时可通过--host-id参数或COLLECTOR_HOST_ID环境变量设置Ansible Playbook 场景下则应作为变量注入 Collector 配置。六、与 Docker 方式的选择建议如果不想引入 AnsibleScrutiny 也提供了开箱即用的 Docker 方案官方提供了 omnibus 一体化部署示例 与 Hub/Spoke 拆分部署两种模式一条docker run或docker-compose up即可启动。三种方式的对比如下部署方式适用场景关键点Ansible Playbook本文多台机器、需要可重复/可版本化的部署、无 Docker 环境一条ansible-playbook site.yml完成全部部署自动调度每日采集Dockeromnibus 镜像单机快速体验需要--cap-add SYS_RAWIO、挂载/run/udev并透传/dev/sd*设备NVMe 盘还需SYS_ADMIN能力手动安装已具备 Docker 环境但仍希望拆分部署、或深度定制需自行完成 InfluxDB、Webapp、Collector 三部分配置见 手动安装文档Ansible 方案特别适合那些没有 Docker、或者希望完全掌控每台机器上组件安装细节的运维场景它与手动安装共用同一套配置体系因此 example.scrutiny.yamlWebapp 配置与 example.collector.yamlCollector 配置中列出的全部参数在 Playbook 部署后同样适用。七、部署后的配置要点速查Playbook 完成基础部署后你仍然可以通过两个配置文件对 Scrutiny 做深度定制文件位于/opt/scrutiny/config/目录下scrutiny.yamlWebapp/API 配置。包括监听地址与端口默认0.0.0.0:8080、SQLite 数据库位置默认/opt/scrutiny/config/scrutiny.db、前端静态资源路径、InfluxDB 连接host/port复用已有 InfluxDB 实例时需提供token、org、bucket、日志级别以及notify.urls通知渠道支持 Discord、Telegram、Slack、SMTP 邮件等十余种见 example.scrutiny.yamlcollector.yamlCollector 配置。包括host.id主机标签、devices设备覆盖如强制/dev/sda使用sat类型、忽略某块盘、处理 RAID 虚拟盘megaraid,N/3ware,N类型、按设备覆盖smartctl参数、commands全局smartctl参数metrics_smartctl_bin、metrics_scan_args、metrics_info_args、metrics_smart_args、metrics_smartctl_wait以及api.endpoint见 example.collector.yaml。需要提醒的是配置文件中的commands参数是经过校验的Collector 在加载配置时会强制要求metrics_scan_args、metrics_info_args、metrics_smart_args必须包含--json标志且不得包含--device/-d标志否则会抛出配置校验错误见 配置校验实现。修改配置后重新运行ansible-playbook site.yml或手动重启相应服务即可生效。八、常见问题与排查方向访问:8080无响应确认 Webapp 是否已启动、防火墙是否放行 8080 端口InfluxDB 不可用时 Webapp 通常也无法正常工作可参考 InfluxDB 排查文档。仪表盘为空 / 无设备Collector 尚未运行或采集失败。先手动执行一次scrutiny-collector-metrics run --api-endpoint http://localhost:8080验证链路再检查smartctl是否安装且为 v7 版本设备识别与采集的通用问题可参考 TROUBLESHOOTING_DEVICE_COLLECTOR.md。通过反向代理访问时路径异常若在 nginx/apache 后面以子路径提供服务需要配置web.listen.basepath见 example.scrutiny.yaml并同步调整 Collector 的api.endpoint详见 TROUBLESHOOTING_REVERSE_PROXY.md。结语Ansible Playbook 把 Scrutiny 原本分散在 InfluxDB、Webapp、Collector 三处的部署工作收敛为一条命令并自动完成每日定时采集的调度配置是运维多台服务器时最省心的部署路径。无论选择 Ansible、Docker 还是手动安装Scrutiny 的底层组件与配置体系都是一致的本文给出的验证方式、配置要点与排查思路在任何部署方式下都同样适用。【免费下载链接】scrutinyHard Drive S.M.A.R.T Monitoring, Historical Trends Real World Failure Thresholds项目地址: https://gitcode.com/GitHub_Trending/sc/scrutiny创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考 Scrutiny 硬盘健康监控：使用 Ansible Playbook 一键自动化部署（scrutiny-playbook 实战指南）
Scrutiny 硬盘健康监控使用 Ansible Playbook 一键自动化部署scrutiny-playbook 实战指南【免费下载链接】scrutinyHard Drive S.M.A.R.T Monitoring, Historical Trends Real World Failure Thresholds项目地址: https://gitcode.com/GitHub_Trending/sc/scrutiny导读本文介绍如何利用社区维护的 Ansible Playbookscrutiny-playbook在目标机器上自动化部署 Scrutiny——一个以 S.M.A.R.T 数据为基础、结合真实世界故障率阈值来监控硬盘健康状态的 Web 监控方案。相比于 手动安装指南 中逐组件手工配置 InfluxDB、Webapp/API 与 Collector 的方式Ansible 方案将整个过程收敛为一条ansible-playbook site.yml命令。读完本文你将掌握通过 Ansible 快速搭建 Scrutiny、理解其自动化背后覆盖的组件与配置、验证部署结果并了解每日自动采集指标的调度机制。一、为什么选择 Ansible 方式部署 ScrutinyScrutiny 不是一个单一二进制程序它由三个核心组件构成详见 手动安装文档InfluxDB 数据库持久化存储各硬盘的 S.M.A.R.T 时序指标需要 v2.2.0 版本Webapp/API提供 Web 前端与后端 API监听8080端口Collector 采集器调用smartctlv7读取硬盘 S.M.A.R.T 数据并上报给 Webapp/API。手动安装需要依次完成 InfluxDB 安装、Webapp 目录结构与配置文件准备、二进制与前端资源下载、Collector 部署以及 cron 调度配置等大量重复性工作。社区成员 Zorlin 开发并持续维护的scrutiny-playbook正是为了将这些手工步骤自动化而生的 Ansible 角色/Playbook。它适用于希望在多台机器上以可重复、可版本化的方式部署 Scrutiny 的场景尤其适合需要管理多台服务器、希望将部署配置纳入基础设施即代码IaC体系的用户。二、使用 Playbook 的完整步骤根据 INSTALL_ANSIBLE.md 的说明整个过程非常简单只有四步步骤 1获取 Playbook 副本首先需要把 scrutiny-playbook 仓库克隆或拷贝到你的控制节点上。这是唯一需要手动完成的准备工作。步骤 2按照 Playbook 仓库中的说明进行配置获取 Playbook 后需要阅读其仓库自带的说明文档完成必要的前置配置。结合 Scrutiny 本身的部署要求这些配置通常至少涉及目标主机清单Inventory声明要部署 Scrutiny 的目标机器地址、SSH 登录凭据InfluxDB 相关设置Scrutiny 要求 InfluxDB v2.2.0见 手动安装文档Playbook 需要能访问或安装该版本设备与权限设置Collector 需要访问/dev/*下的硬盘设备并具备读取 S.M.A.R.T 数据的权限手动部署时smartctl需要 root 或相应能力参见 example.collector.yaml 中的commands配置API 端点配置Collector 必须知道 Webapp/API 的地址才能上报数据对应 Collector 配置中的api.endpoint默认值为http://localhost:8080见 collector 配置源码。步骤 3运行 Playbook配置完成后在控制节点上执行ansible-playbook site.yml该命令会按照 Playbook 的定义在目标机器上依次完成 Scrutiny 全部组件的安装与配置。如果后续需要重新部署或更新配置重新运行同一条命令即可。步骤 4访问部署结果部署完成后打开浏览器访问http://your-machine:8080将 your-machine 替换为实际的目标机器地址。此时即可看到 Scrutiny 的仪表盘其中会列出所有被检测到的硬盘及其当前 S.M.A.R.T 状态。手动安装文档也确认了这一点Webapp 默认监听http://0.0.0.0:8080见 手动安装文档 的Start Scrutiny Webapp章节。三、Playbook 背后自动化了什么与手动安装流程的对照要真正理解 Ansible 方案的价值最好把它与手动安装流程逐项对照。Playbook 自动化的正是 手动安装文档 中描述的全部步骤主要包括手动安装步骤Ansible Playbook 自动化后的效果安装并初始化 InfluxDB v2.2Playbook 自动安装/配置 InfluxDBScrutiny 会自行完成数据库 setup 并回写 token、org、bucket 信息创建/opt/scrutiny/{config,web,bin}目录结构Playbook 自动创建标准目录结构编写 scrutiny.yaml 配置文件数据库位置、前端资源路径、InfluxDB 连接信息Playbook 自动生成配置并落到正确位置从 Release 下载scrutiny-web-linux-amd64与scrutiny-web-frontend.tar.gz并解压Playbook 自动下载、赋予执行权限chmod x并解压前端资源以scrutiny-web-linux-amd64 start --config ...启动 WebappPlaybook 将 Webapp 注册为系统服务并启动下载scrutiny-collector-metrics-linux-amd64Playbook 自动安装 Collector 二进制以scrutiny-collector-metrics run --api-endpoint http://localhost:8080手动触发采集Playbook 自动配置调度任务无需手动触发通过crontab -e手工添加定时任务Playbook 自动写入并启用 cron 调度从 Collector 入口源码 可以看到Collector 默认会从/opt/scrutiny/config/collector.yaml读取配置因此 Playbook 将配置文件放置在该标准路径下即可被自动识别run子命令支持--api-endpoint、--host-id、--config、--debug、--log-file等参数并支持通过COLLECTOR_API_ENDPOINT、COLLECTOR_HOST_ID等环境变量注入这些都为 Playbook 的变量化配置提供了接口。四、自动采集机制每天凌晨 1 点拉取指标安装文档特别强调了一个开箱即用的行为部署完成后Scrutiny 会自动每天一次从目标机器拉取指标时间点为凌晨 1:00at 1am。这一行为本质上是通过 cron 调度 Collector 实现的。从仓库中的 cron 模板 可以看到其实现细节{COLLECTOR_CRON_SCHEDULE} root . /env.sh; /opt/scrutiny/bin/scrutiny-collector-metrics run /proc/1/fd/1 2/proc/1/fd/2即每条调度任务实际执行的是scrutiny-collector-metrics run命令不加任何参数时使用配置文件中默认的api.endpoint。容器镜像默认的调度表达式是0 0 * * *每天午夜并可通过COLLECTOR_CRON_SCHEDULE环境变量覆盖见 README.md 的 Cron Schedule 章节而 Ansible Playbook 则进一步将调度时间设定为文档所述的每天凌晨 1:00。需要特别说明的两点首次采集需要手动触发或等待调度无论是 Ansible 还是手动部署Collector 的职责都是被调度器周期性触发它本身不常驻后台。手动部署时文档明确建议先用run命令手动触发一次让仪表盘尽快有数据可看见 手动安装文档 的Start Scrutiny Collector, Populate Webapp章节cron 是 Collector 的硬依赖Collector 的依赖只有smartctlv7与cron或其他进程调度器。Ansible 方案自动完成了这两项依赖的安装与调度写入。五、部署后验证与日常使用5.1 验证安装是否成功访问仪表盘打开http://your-machine:8080首次访问时若 Collector 尚未运行仪表盘可能为空待第一次采集完成后应能看到全部硬盘列表及 S.M.A.R.T 状态此行为在 README.md 的 Usage 章节有明确描述。查看采集日志Collector 支持通过--debug/DEBUGtrue环境变量开启调试日志或通过--log-file/COLLECTOR_LOG_FILE将日志写入文件见 Collector 源码便于排查采集异常。5.2 确认指标确实来自目标机器在多主机Hub/Spoke场景下每台机器可以部署一个 Collector 采集本机硬盘数据并上报到中央 Webapp。此时可通过 Collector 配置中的host.id字段为不同主机打标签用于区分设备归属参见 example.collector.yaml 的host.id说明。手动安装时可通过--host-id参数或COLLECTOR_HOST_ID环境变量设置Ansible Playbook 场景下则应作为变量注入 Collector 配置。六、与 Docker 方式的选择建议如果不想引入 AnsibleScrutiny 也提供了开箱即用的 Docker 方案官方提供了 omnibus 一体化部署示例 与 Hub/Spoke 拆分部署两种模式一条docker run或docker-compose up即可启动。三种方式的对比如下部署方式适用场景关键点Ansible Playbook本文多台机器、需要可重复/可版本化的部署、无 Docker 环境一条ansible-playbook site.yml完成全部部署自动调度每日采集Dockeromnibus 镜像单机快速体验需要--cap-add SYS_RAWIO、挂载/run/udev并透传/dev/sd*设备NVMe 盘还需SYS_ADMIN能力手动安装已具备 Docker 环境但仍希望拆分部署、或深度定制需自行完成 InfluxDB、Webapp、Collector 三部分配置见 手动安装文档Ansible 方案特别适合那些没有 Docker、或者希望完全掌控每台机器上组件安装细节的运维场景它与手动安装共用同一套配置体系因此 example.scrutiny.yamlWebapp 配置与 example.collector.yamlCollector 配置中列出的全部参数在 Playbook 部署后同样适用。七、部署后的配置要点速查Playbook 完成基础部署后你仍然可以通过两个配置文件对 Scrutiny 做深度定制文件位于/opt/scrutiny/config/目录下scrutiny.yamlWebapp/API 配置。包括监听地址与端口默认0.0.0.0:8080、SQLite 数据库位置默认/opt/scrutiny/config/scrutiny.db、前端静态资源路径、InfluxDB 连接host/port复用已有 InfluxDB 实例时需提供token、org、bucket、日志级别以及notify.urls通知渠道支持 Discord、Telegram、Slack、SMTP 邮件等十余种见 example.scrutiny.yamlcollector.yamlCollector 配置。包括host.id主机标签、devices设备覆盖如强制/dev/sda使用sat类型、忽略某块盘、处理 RAID 虚拟盘megaraid,N/3ware,N类型、按设备覆盖smartctl参数、commands全局smartctl参数metrics_smartctl_bin、metrics_scan_args、metrics_info_args、metrics_smart_args、metrics_smartctl_wait以及api.endpoint见 example.collector.yaml。需要提醒的是配置文件中的commands参数是经过校验的Collector 在加载配置时会强制要求metrics_scan_args、metrics_info_args、metrics_smart_args必须包含--json标志且不得包含--device/-d标志否则会抛出配置校验错误见 配置校验实现。修改配置后重新运行ansible-playbook site.yml或手动重启相应服务即可生效。八、常见问题与排查方向访问:8080无响应确认 Webapp 是否已启动、防火墙是否放行 8080 端口InfluxDB 不可用时 Webapp 通常也无法正常工作可参考 InfluxDB 排查文档。仪表盘为空 / 无设备Collector 尚未运行或采集失败。先手动执行一次scrutiny-collector-metrics run --api-endpoint http://localhost:8080验证链路再检查smartctl是否安装且为 v7 版本设备识别与采集的通用问题可参考 TROUBLESHOOTING_DEVICE_COLLECTOR.md。通过反向代理访问时路径异常若在 nginx/apache 后面以子路径提供服务需要配置web.listen.basepath见 example.scrutiny.yaml并同步调整 Collector 的api.endpoint详见 TROUBLESHOOTING_REVERSE_PROXY.md。结语Ansible Playbook 把 Scrutiny 原本分散在 InfluxDB、Webapp、Collector 三处的部署工作收敛为一条命令并自动完成每日定时采集的调度配置是运维多台服务器时最省心的部署路径。无论选择 Ansible、Docker 还是手动安装Scrutiny 的底层组件与配置体系都是一致的本文给出的验证方式、配置要点与排查思路在任何部署方式下都同样适用。【免费下载链接】scrutinyHard Drive S.M.A.R.T Monitoring, Historical Trends Real World Failure Thresholds项目地址: https://gitcode.com/GitHub_Trending/sc/scrutiny创作声明：本文部分内容由AI辅助生成（AIGC），仅供参考