Scrutiny: Monitorización S.M.A.R.T. de discos

Introducción
Este artículo documenta el uso de Scrutiny como sistema de monitorización de discos dentro del stack de infraestructura, integrándose como servicio auxiliar junto a otros contenedores de observabilidad. Su función es centralizar y dar visibilidad al estado S.M.A.R.T. de discos HDD, SSD y NVMe, evitando depender de consultas manuales con 
smartctl.
El despliegue se realiza mediante Docker para simplificar mantenimiento, persistencia y actualizaciones, manteniendo separación clara respecto al sistema base.
Enfoque general
Scrutiny actúa como una capa de observabilidad preventiva: no gestiona discos ni datos, pero permite detectar degradación progresiva antes de que aparezcan fallos reales. Resulta especialmente útil en entornos con:
Múltiples discos físicos.
Mezcla de HDD antiguos, SSD y NVMe.
Discos USB externos.
Servidores sin NAS comercial con panel propio.
La arquitectura se apoya en tres componentes principales:
Scrutiny Web: interfaz de visualización.
Scrutiny Collector: recolección periódica de métricas S.M.A.R.T.
InfluxDB: almacenamiento histórico de métricas.
Características relevantes
Panel web unificado
Visualización centralizada del estado de todos los discos: salud, temperatura, horas de uso y errores relevantes.
Interpretación de métricas S.M.A.R.T.
Identificación de valores anómalos y métricas problemáticas sin necesidad de interpretar datos en bruto.
Histórico y evolución temporal
Seguimiento de degradación progresiva (sectores reasignados, errores crecientes, temperaturas anómalas).
Compatibilidad amplia
Soporte para discos SATA, NVMe y USB, siempre que el host permita acceso a bajo nivel.
Persistencia desacoplada
Métricas almacenadas en InfluxDB mediante volúmenes Docker, independientes del ciclo de vida del contenedor.
Estado del proyecto y fork utilizado
El proyecto original de Scrutiny sigue siendo funcional y válido, pero a partir de 2024 su desarrollo se ralentizó notablemente, mientras que las contribuciones de la comunidad y las solicitudes de nuevas funcionalidades continuaron creciendo.
Por este motivo se optó por utilizar un fork mantenido activamente, que retoma el desarrollo donde quedó el proyecto original y consolida mejoras pendientes.
En esta infraestructura se utiliza el fork:
https://github.com/Starosdev/scrutiny
Motivos del cambio:
Desarrollo activo y continuo.
Integración de PRs de la comunidad que quedaron pendientes en el proyecto original.
Corrección de errores históricos y mejoras de compatibilidad.
Evolución del frontend y del backend sin romper el modelo original.
A nivel práctico, el fork mantiene la misma filosofía y arquitectura, pero reduce el riesgo de estancamiento a medio y largo plazo.
Funcionalidades añadidas en el fork
El fork introduce mejoras relevantes respecto a la última versión del proyecto original (v0.8.1):
Monitorización de pools ZFS
Permite supervisar el estado de pools ZFS además de los discos individuales.
Exportación de métricas a Prometheus
Posibilidad de exponer métricas para sistemas de monitorización más avanzados.
Archivado de dispositivos
Permite ocultar discos retirados sin perder el histórico asociado.
Control de notificaciones por dispositivo
Silenciado selectivo de alertas en discos concretos.
Etiquetas personalizadas por disco
Facilita la identificación lógica de dispositivos dentro del panel.
Gráficas de temperatura con resolución diaria
Mayor granularidad en el histórico térmico.
Soporte mejorado para discos SAS
Lectura correcta de temperaturas en entornos SAS.
Control de historial SCT y ajustes ERC
Gestión más precisa del comportamiento térmico y de recuperación de errores.
Mejor compatibilidad con discos Seagate
Manejo más robusto de timeouts y respuestas anómalas.
Verificación de binarios mediante SHA256
Comprobación de integridad de los binarios distribuidos.
Actualmente el fork se encuentra en la rama v1.9.x, con desarrollo activo y actualizaciones regulares.
Desarrollo
Qué se hizo y por qué
Uso de Docker para aislar permisos sensibles y facilitar mantenimiento.
Separación clara entre recolección de métricas y frontend.
InfluxDB como backend para disponer de histórico real, no solo estado instantáneo.
Scrutiny se mantiene como herramienta de diagnóstico y visualización, no como sistema de alertas u orquestación.
Configuración utilizada (solo enlaces)
Toda la configuración se mantiene versionada en Gitea:
Scrutiny en Gitea
Incluye:
docker-compose.yml
.env
Definición de volúmenes y dispositivos
Validación
Comprobaciones mínimas tras el despliegue:
Acceso correcto a la interfaz web.
Aparición de todos los discos configurados.
Actualización periódica de métricas.
Persistencia del histórico tras reinicios de contenedores.
Ausencia de errores relevantes en logs del collector.
Recomendaciones y consideraciones
Verificar que los dispositivos definidos en 
devices: existen en el host.
En discos NVMe o USB, revisar permisos y acceso al bus correspondiente.
Los permisos 
SYS_RAWIO y 
SYS_ADMIN son necesarios para que 
smartctl funcione correctamente.
Scrutiny no sustituye backups ni scrubs: es una capa de alerta temprana, no de protección de datos.
Resumen breve
Scrutiny aporta visibilidad real al estado de los discos mediante S.M.A.R.T., con histórico y panel web. El uso de un fork mantenido activamente garantiza continuidad del proyecto sin modificar su filosofía. Es una pieza ligera pero crítica para anticiparse a fallos de hardware.
Referencias
Proyecto original
Fork activo utilizado
Repositorio en Gitea