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:
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:
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_RAWIOySYS_ADMINson necesarios para quesmartctlfuncione 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.