Skip to main content

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_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

Back to top