Scrutiny: monitoriza la salud de tus discos duros con S.M.A.R.T. y avisos antes de que fallen

El año pasado perdí un disco en mi servidor de almacenamiento. No fue un fallo catastrófico con chispas y humo, fue algo peor: el disco empezó a dar errores intermitentes durante semanas, los datos se corrompieron de forma silenciosa y me di cuenta tarde. Tardé tres días en recuperar todo desde el backup, y eso fue porque tenía backup. Muchos no lo tienen.

Desde entonces uso Scrutiny en todos mis servidores. Es un servicio Docker que recopila los datos S.M.A.R.T. de todos tus discos, los analiza y te manda una alerta cuando detecta valores que deberían preocuparte. No es infalible (los discos pueden fallar sin previo aviso S.M.A.R.T.) pero en mi experiencia la mayoría de fallos vienen precedidos de semanas o meses de señales que S.M.A.R.T. detecta si alguien está mirando.

Qué es S.M.A.R.T. y por qué importa

#

S.M.A.R.T. (Self-Monitoring, Analysis and Reporting Technology) es una tecnología que llevan incorporada los discos duros mecánicos y los SSD desde los años 90. El disco mismo va registrando métricas internas: sectores reasignados, errores de lectura, temperatura, horas de funcionamiento, ciclos de encendido, tiempo de spin-up y un buen número de métricas específicas de cada fabricante.

El problema de S.M.A.R.T. no es que no funcione. Es que los datos están ahí, en cada disco, pero nadie los mira. smartctl -a /dev/sda te da un volcado de texto con 30 atributos que hay que interpretar manualmente. Hacerlo en un disco es manejable. En un servidor con 8 o 10 discos, nadie lo hace con regularidad.

Scrutiny automatiza eso. Hay un agente (el “collector”) que corre periódicamente en cada servidor y lee los datos S.M.A.R.T. de todos los discos. Esos datos los envía a un servidor central (el “hub”) que los almacena y los analiza contra umbrales de referencia. Desde una interfaz web ves el estado de todos tus discos de un vistazo, con un semáforo simple: verde, amarillo o rojo.

Arquitectura: all-in-one vs hub+spoke

#

Scrutiny tiene dos modos de despliegue. El más sencillo es all-in-one, donde un único contenedor hace todo: collector y hub. Funciona bien si todos tus discos están en el mismo servidor.

Si tienes varios servidores con discos (un NAS, un servidor de backup, una máquina de almacenamiento separada), el modo hub+spoke tiene más sentido. El hub corre en una máquina central y cada servidor tiene un collector que envía datos al hub. Así ves el estado de todos los discos de toda tu infraestructura en un solo sitio.

Yo uso el modo hub+spoke porque tengo discos repartidos entre mi NAS y otro servidor. El hub corre en mi servidor principal junto con otros servicios de monitorización.

Instalación: modo all-in-one

#

Para empezar, el modo all-in-one es suficiente. Crea un directorio y dentro un docker-compose.yml:

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14
15
16
17
18
19

services:
  scrutiny:
    image: ghcr.io/analogj/scrutiny:master-omnibus
    container_name: scrutiny
    cap_add:
      - SYS_RAWIO
    ports:
      - "8080:8080"
      - "8086:8086"
    volumes:
      - /run/udev:/run/udev:ro
      - ./config:/opt/scrutiny/config
      - ./influxdb:/opt/scrutiny/influxdb
    devices:
      - /dev/sda
      - /dev/sdb
      - /dev/sdc
      - /dev/nvme0n1
    restart: unless-stopped

El punto crítico es la sección devices. Tienes que listar explícitamente cada disco que quieras monitorizar. Para saber qué discos tiene tu servidor:

1

lsblk -d -o NAME,SIZE,TYPE | grep disk

La imagen master-omnibus incluye InfluxDB embebida para almacenar los datos históricos. Para producción, la imagen que te recomiendo es esta, no la etiqueta latest (que a veces va por detrás en actualizaciones importantes).

Levanta el servicio:

1

docker compose up -d

Accede a http://tu-servidor:8080. Los primeros datos tardan unos minutos en aparecer porque el collector tiene que leer S.M.A.R.T. de todos los discos.

Instalación: modo hub+spoke

#

Para el modo hub+spoke necesitas un contenedor hub en el servidor central y un contenedor collector en cada servidor con discos.

Hub (servidor central):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11

services:
  scrutiny-web:
    image: ghcr.io/analogj/scrutiny:master-web
    container_name: scrutiny-web
    ports:
      - "8080:8080"
      - "8086:8086"
    volumes:
      - ./config:/opt/scrutiny/config
      - ./influxdb:/opt/scrutiny/influxdb
    restart: unless-stopped

Collector (en cada servidor con discos):

 1
 2
 3
 4
 5
 6
 7
 8
 9
10
11
12
13
14

services:
  scrutiny-collector:
    image: ghcr.io/analogj/scrutiny:master-collector
    container_name: scrutiny-collector
    cap_add:
      - SYS_RAWIO
    volumes:
      - /run/udev:/run/udev:ro
    devices:
      - /dev/sda
      - /dev/sdb
    environment:
      - COLLECTOR_API_ENDPOINT=http://ip-del-hub:8080
    restart: unless-stopped

Sustituye ip-del-hub por la IP o dominio donde esté el hub. Si el collector está en la misma red que el hub, puedes usar la IP interna de la red de Docker o la IP del servidor.

El collector por defecto ejecuta cada 15 minutos. Para el primer arranque hace una lectura inmediata, así que los datos aparecen rápido.

Interpretando los datos: qué mirar

#

La interfaz de Scrutiny te muestra cada disco con su estado. Los colores tienen un significado concreto:

Verde (passed): Todos los atributos S.M.A.R.T. están dentro de umbrales normales.

Amarillo (warn): Uno o más atributos están fuera del rango normal pero no en valores críticos. Puede ser algo menor (temperatura ligeramente alta) o el inicio de algo peor.

Rojo (failed): Hay atributos en estado crítico. Si tienes un disco en rojo, empieza a preparar el reemplazo. No mañana, hoy.

Scrutiny usa una combinación de dos fuentes de referencia para los umbrales: los valores que cada fabricante define como “prefail” en la especificación S.M.A.R.T. estándar, y la base de datos de Backblaze (la empresa de backup en la nube que lleva más de diez años publicando estadísticas de fallos de disco de su flota de más de 200.000 unidades). Esa combinación hace que los umbrales sean más fiables que simplemente mirar si el valor actual supera el umbral que dice el fabricante.

Los atributos que más importan en discos mecánicos son:

• Reallocated Sectors Count (ID 5): sectores con errores que el disco ha reasignado a sectores de reserva. Cualquier valor distinto de cero merece atención. Si sube con el tiempo, el disco está deteriorándose activamente.

• Pending Sector Count (ID 197): sectores que el disco ha detectado como potencialmente defectuosos y está esperando verificar. Si esto sube, mal asunto.

• Uncorrectable Sector Count (ID 198): sectores que el disco no pudo leer ni corregir. Esto es serio directamente.

• Power-On Hours (ID 9): horas de funcionamiento total. No es un indicador de fallo por sí solo, pero junto con los demás da contexto. Un disco con 50.000 horas y sectores reasignados está en peor posición que uno con 1.000 horas.

En SSDs los atributos cambian. Los más relevantes son el Wear Leveling Count (cuánto desgaste de escrituras lleva el disco) y el Media Wearout Indicator (porcentaje de vida restante según el fabricante).

Configurar notificaciones

#

Scrutiny soporta notificaciones a través de varios canales. La configuración va en el archivo scrutiny.yaml dentro del directorio de config que montaste en el volumen.

Un ejemplo básico con notificaciones por email:

1
2
3

notify:
  urls:
    - "smtp://usuario:contraseñ[email protected]:587/[email protected]&[email protected]"

Scrutiny usa la librería Shoutrrr para notificaciones, que soporta una lista larga de destinos: Slack, Discord, Telegram, Gotify, ntfy, email, Matrix y varios más. El formato de la URL de notificación sigue el esquema de Shoutrrr, que puedes consultar en su documentación.

Yo lo tengo conectado a ntfy (del que ya hablamos en otro artículo). Cuando un disco cambia a estado amarillo o rojo, me llega una notificación push en el móvil. La configuración es:

1
2
3

notify:
  urls:
    - "ntfy://tu-servidor-ntfy:80/scrutiny-alerts"

El nivel de alerta por defecto es solo para estados “failed” (rojo). Si quieres recibir avisos también para el estado “warn” (amarillo), añade esto:

1
2

notify:
  filter_attributes: SCRUTINY_STATUS_FAILED_SCRIPT|SCRUTINY_STATUS_WARN_SCRIPT

Integración con sistemas de backup

#

Scrutiny monitoriza, pero no hace nada por ti cuando un disco empieza a fallar. La respuesta correcta cuando ves un disco en amarillo o rojo es revisar tus backups y planificar el reemplazo antes de que el fallo sea total.

Lo que yo hago cuando un disco pasa a amarillo:

1. Verifico el último backup de ese servidor (fecha, integridad)
2. Si el disco es parte de un RAID, verifico que el RAID está degradado pero operativo
3. Encargo el disco de reemplazo
4. Si el estado empeora a rojo, hago backup inmediato antes del reemplazo

Para discos que están fuera de RAID (discos de datos sueltos en un servidor), la urgencia es mayor porque no hay redundancia.

Comparativa con alternativas

#

Antes de Scrutiny probé varias opciones:

smartmontools con cron y email: Es la opción clásica. smartd puede monitorizar discos y enviar emails. Funciona, pero la configuración es más compleja y los emails de texto plano con volcados de atributos son difíciles de interpretar rápido.

Grafana con node_exporter: Node exporter expone algunos datos S.M.A.R.T. como métricas de Prometheus. Puedes construir dashboards en Grafana. El problema es que la cobertura de atributos es incompleta y tienes que definir tú los umbrales de alerta. Más potente pero más trabajo de configuración.

CheckMK / Nagios / Zabbix: Herramientas de monitorización general que también pueden monitorizar S.M.A.R.T. Tienen curvas de aprendizaje más pronunciadas y consumen más recursos. Para homelab suele ser overkill.

Scrutiny es la opción que mejor balance tiene entre funcionalidad y esfuerzo de configuración. La base de datos de umbrales de Backblaze es un diferenciador real: no te fías solo de los umbrales del fabricante (que a veces son demasiado permisivos) sino de datos estadísticos reales de millones de discos.

Lo que Scrutiny no hace

#

Para ser justo, hay cosas que Scrutiny no cubre:

No monitoriza discos detrás de controladoras RAID hardware (las que tienen su propio firmware y ocultan los discos individuales al sistema operativo). Si tienes una controladora RAID de servidor con batería, los discos aparecen como /dev/sda pero en realidad son un volumen virtual. En ese caso necesitas la herramienta específica del fabricante de la controladora para acceder a S.M.A.R.T.

No predice fallos con certeza. S.M.A.R.T. tiene una tasa de falsos negativos real: un porcentaje de discos fallan sin haber mostrado señales previas. Es una herramienta de ayuda, no una garantía. El backup sigue siendo imprescindible.

No monitoriza tarjetas SD ni almacenamiento eMMC en SBCs como Raspberry Pi o ZimaBoard. Esos dispositivos no implementan S.M.A.R.T. de la misma manera.

Recursos consumidos

#

El hub con InfluxDB embebida consume algo de RAM, especialmente si tienes muchos discos o un historial largo. En mi configuración (hub con datos de 12 discos en dos servidores, historial de 3 meses) el contenedor usa unos 300-400 MB de RAM en reposo.

El collector es muy ligero: apenas 30-50 MB de RAM y CPU casi nula entre ejecuciones.

Para el almacenamiento, el directorio de InfluxDB crece lentamente. Con 12 discos y lecturas cada 15 minutos, lleva 6 meses funcionando y ocupa menos de 500 MB.

Conclusión

#

Scrutiny resuelve un problema real del homelab que mucha gente ignora hasta que ya es tarde. Los datos S.M.A.R.T. han estado siempre disponibles en los discos. El problema era que nadie los miraba. Scrutiny automatiza eso, añade una capa de análisis inteligente con umbrales basados en datos estadísticos reales y te avisa cuando necesitas actuar.

No es una herramienta glamurosa. No tiene miles de estrellas en GitHub ni sale en todos los vídeos de “best homelab apps”. Pero desde que la monté no he vuelto a tener una sorpresa desagradable con un disco. Y eso vale mucho.

Si tienes discos en tu homelab (y si tienes homelab, los tienes), deberías tener Scrutiny corriendo. Es una tarde de trabajo para montarlo y funciona solo a partir de ahí.