ZFS ZED: Alertas que te avisan de fallos antes que los usuarios

Qué hace realmente ZED (y qué no hace)

ZFS es un sistema de ficheros y gestor de volúmenes con un sentido incorporado de autopreservación. Calcula checksums de los datos, valida lecturas,
detecta corrupción y registra información detallada de fallos. Pero ZFS no va a entrar en tu oficina y aclarar la garganta.
ZED es el mensajero.

A alto nivel, ZED escucha eventos de ZFS (originados en el módulo del kernel de ZFS y en herramientas de userland) y ejecuta pequeños scripts
manejadores llamados zedlets. Esos scripts pueden enviar correo, registrar en syslog/journald, activar un hot spare, registrar historial o integrarse con
el sistema de alertas en el que confíes a las 3 a.m.

La línea límite

• ZFS detecta y registra: errores, estado degradado, inicio/fin de resilver, inicio/fin de scrub, fallos de dispositivos, etc.
• ZED reacciona y notifica: “algo pasó, aquí están los detalles, esto es lo siguiente que hay que hacer”.
• Tu monitorización correlaciona y escala: llama a humanos, abre tickets, rastrea MTTR y convierte esto en responsabilidad de alguien.

ZED no es un sistema de monitorización completo. Es un motor de disparo y contexto. No deduplicará alertas en flotas ni te dará dashboards SLO.
Pero te dará señales tempranas, específicas y accionables — del tipo que te permiten reemplazar un disco un martes por la tarde en lugar de
hacer cirugía durante una caída de clientes un sábado por la noche.

Una cita operativa que vale la pena tener cerca de tus runbooks:
La esperanza no es una estrategia. — Gen. Gordon R. Sullivan

Broma #1: Los fallos de almacenamiento son como el dentista — si solo los ves cuando duele, ya estás pagando de más.

Hechos e historia que importan en ops

ZED no es solo “algún demonio”. Es la superficie operativa de ZFS. Unos cuantos hechos y puntos de contexto facilitan razonar
sobre lo que despliegas y por qué se comporta como lo hace:

1. ZFS se originó en Sun Microsystems a mediados de los 2000 con una filosofía de “almacenamiento como sistema”: checksums, pooling, snapshots, autocuración.
2. ZFS fue diseñado para desconfiar de los discos por defecto. Los checksums de extremo a extremo no son una característica; son la premisa.
3. OpenZFS surgió como esfuerzo multiplataforma después de que la línea original de Solaris ZFS se fragmentara; hoy Linux, FreeBSD y otros siguen OpenZFS.
4. ZED nació de la necesidad de operacionalizar eventos de fallo. Detectar un fallo no sirve de nada si nadie es avisado.
5. ZFS tiene un flujo interno de eventos (piensa: “cambios de estado e informes de fallos”), y ZED es un consumidor que convierte esos eventos en acciones.
6. Los scrubs son una primitiva de mantenimiento de primera clase en ZFS: lecturas completas periódicas para encontrar y reparar corrupción silenciosa mientras exista redundancia.
7. “Degradado” no es “caído” en ZFS, y eso es exactamente por lo que es peligroso: el servicio continúa, pero tu margen de seguridad ha desaparecido.
8. Resilver no es lo mismo que scrub: resilver es reparación/reconstrucción dirigida tras el reemplazo o la conexión de un dispositivo; scrub es verificación a nivel de pool.
9. Muchos “errores” de ZFS son en realidad la advertencia, no el incidente: los errores de checksum a menudo significan que el sistema detectó datos malos y los sanó.

La conclusión operativa: ZFS habla mucho en las formas que importan. ZED es cómo escuchas sin vivir en zpool status como si fuera una red social.

Cómo ZED ve el mundo: eventos, zedlets y estado

La tarea de ZED es simple: cuando ocurre un evento de ZFS, ejecutar manejadores. La complejidad está en los detalles: qué eventos, qué manejadores,
cómo limitar, y cómo incluir suficiente contexto en tus alertas para que puedas actuar sin tener que hacer espeleología.

Fuentes de eventos y forma de los datos

ZFS emite eventos por cambios de estado de pool, errores de dispositivos, actividad de scrub/resilver y acciones de gestión de fallos. ZED los recibe
y expone campos del evento a los zedlets como variables de entorno. El conjunto exacto varía según la plataforma y la versión de OpenZFS, pero verás
temas consistentes: nombre del pool, GUID del vdev, ruta del dispositivo, transiciones de estado y contadores de errores.

Zedlets: scripts diminutos con cuchillos afilados

Los zedlets son scripts ejecutables colocados en un directorio de zedlets (comúnmente bajo /usr/lib/zfs/zed.d en distribuciones Linux,
con enlaces simbólicos o conjuntos habilitados bajo /etc/zfs/zed.d). Son intencionalmente pequeños. Deben hacer una cosa bien:
formatear un correo, escribir en syslog, iniciar un spare, registrar una línea de historial o llamar a un script de integración local.

La disciplina: mantén los zedlets determinísticos y rápidos. Si necesitas “lógica real”, que el zedlet encole trabajo (escriba un archivo, emita a un socket local,
llame a un wrapper ligero) y deja que otro servicio haga el trabajo pesado. ZED forma parte de tu ruta de fallo. No lo inflés.

Estado y deduplicación

ZED puede generar eventos repetidos por dispositivos que fluctúan o errores continuos. Si envías páginas ante cada emisión, entrenarás a tu equipo
a ignorar alertas, y entonces merecerás lo que venga después. Las buenas configuraciones de ZED suelen hacer al menos una de estas cosas:

• Limitar notificaciones (por pool/vdev y por ventana temporal).
• Enviar alertas de “cambio de estado” (ONLINE→DEGRADED, DEGRADED→ONLINE) en lugar de cada incremento.
• Enviar scrubs como eventos resumidos (iniciado, finalizado, errores encontrados) con contexto.
• Almacenar un pequeño fichero de estado que rastree lo que ya se envió.

En qué deberías alertar

No alertes sobre todo. Alertar es un contrato con humanos somnolientos. Aquí tienes una línea base sensata:

• Cambios de estado de pool: ONLINE→DEGRADED, DEGRADED→FAULTED, dispositivo eliminado.
• Resultados de scrub: completado con errores, bytes reparados o “demasiados errores”.
• Errores de checksum/lectura/escritura más allá de un umbral o con una tasa creciente.
• Eventos de fallo de dispositivo: timeouts, fallos de I/O, “device removed”, cambios de ruta.
• Finalización de resilver: éxito/fallo, duración, si el pool volvió a ONLINE.

Alertas que deberían importarte (y qué hacer con ellas)

Una alerta de ZED debe responder tres preguntas: qué pasó, qué está en riesgo y qué hago a continuación.
Si tus alertas no incluyen el nombre del pool, el vdev afectado y una copia de zpool status -x o un fragmento relevante,
estás escribiendo novelas de misterio, no alertas.

Pool DEGRADED

“DEGRADED” significa que estás funcionando con redundancia reducida. Aún estás atendiendo, pero un fallo más te deja expuesto a pérdida de datos (dependiendo del nivel RAIDZ y del vdev).
La respuesta correcta es acotada en el tiempo: investigar inmediatamente; reemplazar pronto; no esperes la próxima ventana de mantenimiento a menos que te guste apostar.

Errores de checksum

Los errores de checksum son ZFS diciéndote “capté datos malos”. Eso es bueno y malo. Bueno: la detección funciona. Malo: algo está corrompiendo datos
en la cadena — disco, cable, HBA, firmware, RAM (si no usas ECC), o incluso inestabilidad de energía. Tu decisión depende de si los errores están
aislados (un solo disco, una sola ruta) o son sistémicos (a través de vdevs).

Errores de lectura/escritura

Los errores de lectura indican que el dispositivo no pudo devolver datos. ZFS puede reconstruir desde paridad/espejos; si no, verás errores permanentes.
Los errores de escritura a menudo apuntan a conectividad, reinicios del controlador o que el disco rehúsa escribir. Sea como sea, trata los contadores crecientes como “reemplazar o arreglar la ruta”.

Scrub finalizado con errores

Un scrub que reparó datos es una advertencia de que la redundancia te salvó esta vez. Si no actúas, la próxima vez puede que no.
Un scrub que encontró errores no reparados es un incidente de integridad de datos; tu trabajo se convierte en evaluar daño y estrategia de restauración.

Dispositivo eliminado / UNAVAIL

Esto a menudo no significa “el disco murió”, sino “la ruta murió”. Cable SAS suelto, expander fallando, bug de firmware del HBA, backplane inestable.
La forma más rápida de arruinar un fin de semana es reemplazar un disco que está bien cuando el backplane es el verdadero culpable.

Tareas prácticas: comandos, salidas y decisiones (12+)

Estos son los movimientos que harás en la vida real: verificar que ZED esté en ejecución, validar que puede enviar correo, disparar eventos de prueba,
interpretar la salud del pool y tomar acciones correctivas. Cada tarea abajo incluye: el comando, qué significa la salida y la decisión que tomas.

Task 1: Confirmar que el servicio ZED está en ejecución (systemd)

cr0x@server:~$ systemctl status zfs-zed.service
● zfs-zed.service - ZFS Event Daemon (zed)
     Loaded: loaded (/lib/systemd/system/zfs-zed.service; enabled; vendor preset: enabled)
     Active: active (running) since Mon 2025-12-22 09:14:31 UTC; 2 days ago
   Main PID: 1189 (zed)
      Tasks: 3 (limit: 18982)
     Memory: 7.4M
        CPU: 1min 12s
     CGroup: /system.slice/zfs-zed.service
             └─1189 /usr/sbin/zed -F

Qué significa: “active (running)” es lo mínimo. Si está inactivo, los eventos de ZFS siguen ocurriendo; simplemente no te enteras.

Decisión: Si no está en ejecución, arregla ZED antes de confiar en cualquier “monitorización” que diga vigilar ZFS.

Task 2: Inspeccionar logs recientes de ZED en journald

cr0x@server:~$ journalctl -u zfs-zed.service -n 50 --no-pager
Dec 24 08:03:11 server zed[1189]: ZED: eid=402 class=sysevent.fs.zfs.scrub_finish pool=tank
Dec 24 08:03:11 server zed[1189]: ZED: executing zedlet: /usr/lib/zfs/zed.d/scrub.finish
Dec 24 08:03:11 server zed[1189]: ZED: eid=403 class=sysevent.fs.zfs.vdev_check pool=tank

Qué significa: Quieres ver eventos y líneas de ejecución de zedlet. Silencio durante eventos conocidos sugiere mala configuración o ausencia de eventos.

Decisión: Si ves eventos pero no notificaciones, enfócate en la configuración de zedlets (correo, permisos, PATH), no en ZFS en sí.

Task 3: Validar que el archivo de configuración de ZED es sensato

cr0x@server:~$ sudo egrep -v '^\s*(#|$)' /etc/zfs/zed.d/zed.rc
ZED_DEBUG_LOG="/var/log/zed.log"
ZED_EMAIL_ADDR="storage-alerts@example.com"
ZED_EMAIL_PROG="mail"
ZED_NOTIFY_INTERVAL_SECS=3600
ZED_NOTIFY_VERBOSE=1

Qué significa: ZED está configurado para registrar, enviar correo y limitar alertas. La falta de ajustes de correo es un problema común de “creíamos que teníamos alertas”.

Decisión: Si tu organización no usa correo, configura ZED para llamar a un script wrapper que hable con tu gestor de alertas, pero mantén el throttling.

Task 4: Confirmar que el mailer existe y funciona desde el host

cr0x@server:~$ command -v mail
/usr/bin/mail

cr0x@server:~$ echo "zed test message" | mail -s "zed smoke test" storage-alerts@example.com
...output...

Qué significa: El primer comando demuestra que el programa de correo configurado por ZED existe. El segundo prueba que el host puede entregar correo (en cola local o relé).

Decisión: Si el correo falla, arregla el envío saliente antes de culpar a ZED. ZED no puede notificar por una tubería inexistente.

Task 5: Listar zedlets habilitados (qué acciones estás tomando realmente)

cr0x@server:~$ ls -l /etc/zfs/zed.d
total 0
lrwxrwxrwx 1 root root 30 Dec 10 10:12 all-syslog.sh -> /usr/lib/zfs/zed.d/all-syslog.sh
lrwxrwxrwx 1 root root 31 Dec 10 10:12 checksum-email.sh -> /usr/lib/zfs/zed.d/checksum-email.sh
lrwxrwxrwx 1 root root 29 Dec 10 10:12 scrub.finish -> /usr/lib/zfs/zed.d/scrub.finish

Qué significa: Muchas distribuciones instalan zedlets en /usr/lib y habilitan un subconjunto vía enlaces simbólicos en /etc.

Decisión: Si nada está habilitado, no recibirás nada. Habilita solo lo que puedas gestionar; desactiva los ruidosos hasta que estés listo.

Task 6: Comprobar salud general del pool rápidamente (el comando “estamos en llamas”)

cr0x@server:~$ zpool status -x
all pools are healthy

Qué significa: Esto es ZFS siendo misericordioso y conciso. Si imprime otra cosa, tienes trabajo por hacer.

Decisión: Salida “healthy” no significa “sin riesgo”, pero sí que no estás activamente degradado/defectuoso.

Task 7: Estado profundo cuando algo está mal

cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an unrecoverable error.
action: Replace the device using 'zpool replace'.
  scan: scrub repaired 0B in 03:21:18 with 0 errors on Tue Dec 24 08:03:11 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz1-0                  DEGRADED     0     0     0
            ata-WDC_WD80EFAX-1      ONLINE       0     0     0
            ata-WDC_WD80EFAX-2      ONLINE       0     0     0
            ata-WDC_WD80EFAX-3      UNAVAIL      0     0     0  cannot open

errors: No known data errors

Qué significa: El pool está degradado porque un dispositivo está indisponible. “No known data errors” es bueno; la redundancia sigue sosteniendo.

Decisión: Trata UNAVAIL como urgente. Investiga ruta vs disco, luego reemplaza o restaura la conectividad antes de que ocurra un segundo fallo.

Task 8: Correlacionar nombres de dispositivo ZFS con hardware real

cr0x@server:~$ ls -l /dev/disk/by-id/ | grep WD80EFAX-3
lrwxrwxrwx 1 root root  9 Dec 25 01:12 ata-WDC_WD80EFAX-3 -> ../../sde

Qué significa: Puedes mapear la ruta estable by-id de ZFS a un nodo de dispositivo del kernel (/dev/sde), lo que ayuda con SMART y el mapeo de bahía física.

Decisión: Usa /dev/disk/by-id en los pools cuando sea posible; reduce incidentes de “sacaron el disco equivocado”.

Task 9: Revisar SMART del disco sospechoso

cr0x@server:~$ sudo smartctl -a /dev/sde | egrep 'SMART overall-health|Reallocated_Sector_Ct|Current_Pending_Sector|Offline_Uncorrectable'
SMART overall-health self-assessment test result: PASSED
  5 Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
197 Current_Pending_Sector  0x0012   100   100   000    Old_age   Always       -       8
198 Offline_Uncorrectable   0x0010   100   100   000    Old_age   Offline      -       2

Qué significa: “PASSED” no es una carta de libertad. Sectores pendientes e incorrigibles son señales malas incluso cuando el disco declara confianza.

Decisión: Si pending/uncorrectable es distinto de cero y crece, reemplaza el disco. Si ZFS ya marcó UNAVAIL, se acabó el debate.

Task 10: Inspeccionar mensajes recientes del kernel por resets de enlace o errores de transporte

cr0x@server:~$ dmesg -T | tail -n 20
[Wed Dec 25 01:10:22 2025] ata9.00: exception Emask 0x10 SAct 0x0 SErr 0x4050000 action 0x6 frozen
[Wed Dec 25 01:10:22 2025] ata9.00: irq_stat 0x08000000, interface fatal error
[Wed Dec 25 01:10:23 2025] ata9: hard resetting link
[Wed Dec 25 01:10:28 2025] ata9: link is slow to respond, please be patient (ready=0)
[Wed Dec 25 01:10:31 2025] ata9: COMRESET failed (errno=-16)
[Wed Dec 25 01:10:31 2025] ata9.00: disabled

Qué significa: Esto grita “problema de ruta”. Podría ser el disco, podría ser el cable/backplane, podría ser el controlador.

Decisión: Antes de reemplazar discos en masa, intercambia el cable/la bahía del backplane si puedes. Si los errores siguen la bahía, encontraste el dominio real de fallo.

Task 11: Mostrar contadores de error de ZFS y vigilar su crecimiento

cr0x@server:~$ zpool status -v tank
  pool: tank
 state: DEGRADED
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz1-0                  DEGRADED     0     0     0
            ata-WDC_WD80EFAX-1      ONLINE       0     0     0
            ata-WDC_WD80EFAX-2      ONLINE       0     0     0
            ata-WDC_WD80EFAX-3      UNAVAIL      3     1     0  cannot open

errors: No known data errors

Qué significa: Los contadores (READ/WRITE/CKSUM) son evidencia. Unos pocos errores históricos no siempre son catastróficos, pero contadores crecientes son tendencia.

Decisión: Si los contadores aumentan después de reinsertar cables o reiniciar, deja de “probar cosas” y reemplaza el componente en el dominio que falla.

Task 12: Reemplazar un disco fallado de la manera correcta

cr0x@server:~$ sudo zpool replace tank ata-WDC_WD80EFAX-3 /dev/disk/by-id/ata-WDC_WD80EFAX-NEW
...output...

Qué significa: ZFS comienza un resilver en el disco nuevo, dirigido a bloques asignados (típicamente más rápido que las reconstrucciones RAID clásicas).

Decisión: Monitorea el progreso del resilver. Si el pool sigue degradado tras el resilver, tienes problemas adicionales (dispositivo equivocado, múltiples fallos o inestabilidad de rutas).

Task 13: Monitorizar progreso de resilver/scrub

cr0x@server:~$ zpool status tank
  pool: tank
 state: DEGRADED
status: One or more devices is currently being resilvered.
  scan: resilver in progress since Wed Dec 25 01:22:10 2025
        312G scanned at 1.12G/s, 44.8G issued at 164M/s, 3.21T total
        44.8G resilvered, 1.36% done, 05:20:11 to go
config:

        NAME                             STATE     READ WRITE CKSUM
        tank                             DEGRADED     0     0     0
          raidz1-0                       DEGRADED     0     0     0
            ata-WDC_WD80EFAX-1           ONLINE       0     0     0
            ata-WDC_WD80EFAX-2           ONLINE       0     0     0
            ata-WDC_WD80EFAX-NEW         ONLINE       0     0     0  (resilvering)

Qué significa: “issued at” refleja la tasa real de escritura. “scanned at” puede ser mayor debido a recorrido de metadatos y read-ahead.

Decisión: Si el resilver va muy lento, no adivines. Revisa cuellos de botella de I/O, errores en otros discos o problemas del controlador.

Task 14: Verificar programación de scrub y últimos resultados

cr0x@server:~$ zpool status -s tank
  pool: tank
 state: ONLINE
scan: scrub repaired 0B in 03:21:18 with 0 errors on Tue Dec 24 08:03:11 2025

Qué significa: Tienes un registro de la última finalización de scrub. Si esto falta durante meses, estás volando sin faros.

Decisión: Si no tienes scrubs periódicos, prográmalos. Si los tienes pero no alertas en fallos, conecta ZED ahora.

Task 15: Confirmar entrega de eventos ZFS a ZED (chequeo de cordura)

cr0x@server:~$ sudo zpool scrub tank
...output...

cr0x@server:~$ journalctl -u zfs-zed.service -n 20 --no-pager
Dec 25 01:30:02 server zed[1189]: ZED: eid=510 class=sysevent.fs.zfs.scrub_start pool=tank
Dec 25 01:30:02 server zed[1189]: ZED: executing zedlet: /usr/lib/zfs/zed.d/scrub.start

Qué significa: Iniciar un scrub produce un evento. Verlo en los logs de ZED prueba el flujo de eventos.

Decisión: Si no ves el evento, depura el servicio ZED, permisos o la infraestructura de eventos ZFS en esa plataforma.

Task 16: Comprobar que ZED no está bloqueado por permisos o directorios faltantes

cr0x@server:~$ sudo -u root test -w /var/log && echo "log dir writable"
log dir writable

cr0x@server:~$ sudo -u root test -x /usr/lib/zfs/zed.d/scrub.finish && echo "zedlet executable"
zedlet executable

Qué significa: Que ZED falle al escribir logs o ejecutar zedlets es aburrido, común y devastador para el sistema de alertas.

Decisión: Arregla permisos de archivos e integridad del paquete. No soluciones con “chmod 777”; manténlo mínimo y auditable.

Broma #2: ZED es como una alarma de humo — la gente solo se queja de que es ruidosa hasta el día que les salva el fin de semana.

Playbook de diagnóstico rápido

Esta es la secuencia “salirse rápido del atasco”. No es perfecta. No es elegante. Está optimizada para: ¿qué verifico primero, segundo, tercero para encontrar el cuello de botella
y decidir si trato con un disco, una ruta, un problema a nivel de pool o un cableado de alertas mal hecho?

Primero: ¿es un problema real del pool o solo alertas faltantes?

1. Comprueba la salud del pool: zpool status -x. Si está sano, podrías estar depurando ZED, no ZFS.
2. Verifica que ZED esté vivo: systemctl status zfs-zed.service y journalctl -u zfs-zed.service.
3. Dispara un evento inocuo: inicia un scrub en un pool de prueba o realiza un ciclo de inicio/fin de scrub (si lo puedes tolerar). Confirma que ZED registre el evento.

Segundo: si el pool está degradado/faulted, localiza el dominio de fallo

1. Identifica el vdev y el dispositivo: zpool status POOL y anota contadores READ/WRITE/CKSUM.
2. Mapea by-id al dispositivo real: ls -l /dev/disk/by-id/ para obtener el nodo del kernel.
3. Revisa logs del kernel: dmesg -T por resets de enlace, timeouts, errores de transporte. Los problemas de ruta suelen aparecer aquí primero.
4. Revisa SMART: smartctl -a por sectores pendientes/incorrigibles y registros de error.

Tercero: decide si puedes estabilizar sin reemplazo

1. Si parece un problema de ruta: reinsertar/reemplazar cable, mover el disco a otra bahía, actualizar firmware del HBA (con cuidado), verificar alimentación.
2. Si parece medio del disco: reemplaza el disco. No negocies con sectores pendientes.
3. Después del cambio: vigila el resilver y vuelve a comprobar contadores. Si los contadores siguen subiendo, detente y amplía el alcance al controlador/backplane.

Cuarto: verifica la calidad de las alertas

1. Asegura que las alertas sean accionables: incluye nombre del pool, id del dispositivo, zpool status actual y últimos resultados de scrub.
2. Throttle y dedupe: pagina por transiciones de estado; correo o ticket por advertencias blandas repetidas.
3. Realiza un simulacro trimestral: simula un evento (inicio/fin de scrub, zedlet de prueba) y confirma que el equipo correcto lo recibe.

Tres mini-historias corporativas desde las trincheras de almacenamiento

Mini-historia 1: El incidente causado por una suposición equivocada

Una empresa SaaS mediana ejecutaba ZFS en Linux para un puñado de nodos de almacenamiento “durables”. Habían migrado desde una vieja configuración con controlador RAID y
se sentían confiados: checksums, scrubs, snapshots — todo. También creían tener monitorización. O al menos eso pensaba todo el mundo.

La suposición equivocada fue sutil: “las alertas de ZFS vienen con el paquete de ZFS”. Alguien instaló OpenZFS, creó pools, programó scrubs
y siguió con su trabajo. ZED estaba instalado pero no habilitado. Nadie lo notó porque, día a día, ZFS es silencioso cuando las cosas están sanas.

Meses después, un disco empezó a registrar timeouts intermitentes. ZFS reintentó, sanó desde la paridad y siguió atendiendo. El pool pasó a DEGRADED brevemente,
luego volvió a ONLINE cuando el disco regresó. Sin alerta, sin ticket, sin reemplazo. Los contadores de error subieron como una fuga lenta detrás de una pared.

El incidente real llegó con un segundo fallo de disco durante un periodo de lecturas intensas. Ahora el pool quedó severamente DEGRADED y la aplicación notó picos de latencia.
Los usuarios informaron “subidas lentas”. Ops empezó por el extremo equivocado del problema (ajuste de la aplicación, balanceadores) porque no tuvieron señal temprana.

Las acciones del postmortem fueron aburridas y correctas: habilitar ZED, cablear notificaciones a la rotación on-call, paginar por degradación de pool e incluir
nombres by-id para que alguien pueda sacar el disco correcto sin necesidad de una sesión espiritual.

Mini-historia 2: La optimización que salió mal

Un equipo de ingeniería de datos quiso menos correos. Estaban cansados de notas “scrub iniciado” y “scrub finalizado” que llenaban bandejas, y tenían razón:
las alertas no estaban priorizadas y nadie las leía con atención.

La “optimización” fue desactivar por completo los zedlets relacionados con scrub. Su razonamiento: “ya ejecutamos scrubs mensuales; si algo va mal, el pool se degradará.”
Esa cláusula final es la mina. Los resultados de scrub pueden revelar corrupción que ZFS reparó silenciosamente. Eso no es un pool degradado. Es un aviso.

Unos meses más tarde, un scrub habría detectado y reparado errores de checksum en un vdev, señalando un cable SAS defectuoso. En su lugar, nadie vio la señal temprana.
El cable empeoró. Finalmente el disco cayó durante un resilver provocado por una operación de mantenimiento no relacionada, alargando el resilver y
aumentando el riesgo operativo. El equipo había diseñado un “sistema silencioso” que falló a lo grande.

Lo arreglaron re-habilitando alertas de scrub pero cambiando la política: eventos de inicio de scrub fueron a logs de baja prioridad; finalización de scrub con reparaciones o errores
generó un ticket y una revisión humana. Redujeron el ruido. Restauraron la señal. Esa es la compensación correcta.

Mini-historia 3: La práctica aburrida que salvó el día

Un grupo de IT empresarial gestionaba una flota de hosts VM con respaldo ZFS. Su plataforma de almacenamiento no era emocionante; era deliberadamente aburrida. Tenían un estándar estricto:
nombres de dispositivo by-id, verificación trimestral de scrub y un runbook on-call de “reemplazo de disco” que cabía en una página.

Un jueves, ZED pagó “pool DEGRADED” con el vdev afectado y el mapeo de bahía física. El host seguía sirviendo VMs sin problemas.
La tentación en entornos corporativos es posponer el trabajo porque “no hay caída”. No lo hicieron.

El on-call siguió el runbook: confirmar estado, revisar SMART, revisar logs del kernel y reemplazar el disco. El resilver terminó, el pool volvió a ONLINE,
y cerraron el bucle verificando el siguiente scrub. Sin escalado a liderazgo, sin impacto al cliente, sin sala de guerra dramática.

Dos días después, otro host en la misma fila tuvo un evento de energía que causó un reset del controlador. Si el primer host aún hubiera estado degradado,
ese segundo evento podría haber convertido un reemplazo rutinario en una restauración caótica. La práctica aburrida les dio margen.

Errores comunes: síntomas → causa raíz → solución

1) Síntoma: “Nunca recibimos alertas de ZFS”

Causa raíz: Servicio ZED no habilitado/ejecutándose, o zedlets no habilitados vía /etc/zfs/zed.d.

Solución: Habilita e inicia ZED; verifica flujo de eventos con un inicio de scrub y comprueba journald para líneas de ejecución.

2) Síntoma: “ZED registra eventos pero no llegan correos”

Causa raíz: Programa de correo faltante, SMTP saliente bloqueado o ZED_EMAIL_ADDR/ZED_EMAIL_PROG mal configurados.

Solución: Ejecuta el mismo comando de correo manualmente desde el host; arregla relé/firewall/DNS; luego prueba ZED de nuevo.

3) Síntoma: “Tormenta de pagers durante un evento de disco inestable”

Causa raíz: Sin throttling/dedupe; alertar por cada incremento de error en lugar de cambio de estado.

Solución: Configura intervalo de notificación; pagina en transiciones de estado de pool; crea tickets en errores blandos repetidos con umbrales de tasa.

4) Síntoma: “Pool muestra errores de checksum en varios discos a la vez”

Causa raíz: Dominio de fallo compartido (HBA, backplane, expander, cable, alimentación) o corrupción de memoria en sistemas sin ECC.

Solución: Deja de reemplazar discos al azar. Inspecciona dmesg por resets de transporte, valida firmware/driver del HBA, intercambia cables y evalúa la postura de RAM/ECC.

5) Síntoma: “Scrub finalizó, bytes reparados, pero todos lo ignoraron”

Causa raíz: Política de alertas trata resultados de scrub como ruido; no hay workflow para investigar corrupciones reparadas.

Solución: Enruta “scrub finalizado con reparaciones/errores” a un ticket con revisión obligatoria y comprobaciones de seguimiento (SMART, cableado, contadores).

6) Síntoma: “Resilver tarda una eternidad y el pool sigue frágil”

Causa raíz: Cuello de botella de I/O subyacente, discos marginales adicionales o problemas de controlador que causan reintentos.

Solución: Revisa contadores de error de otros vdevs, dmesg por resets y SMART por sectores lentos. Si múltiples discos están enfermos, estabiliza hardware antes de forzar el resilver.

7) Síntoma: “ZED ejecuta zedlets pero fallan en silencio”

Causa raíz: Permisos, bits ejecutables faltantes, dependencias ausentes en PATH o scripts que dependen de comportamiento interactivo del shell.

Solución: Haz zedlets autocontenidos: rutas absolutas, entorno explícito, manejo estricto de errores, registra fallos en journald/syslog.

8) Síntoma: “Ops reemplazó el disco equivocado”

Causa raíz: Pools construidos sobre nombres /dev/sdX; alerta no incluye identificadores estables; no hay proceso de mapeo de bahías.

Solución: Usa /dev/disk/by-id en los pools, incluye by-id en las alertas y mantiene un mapeo de bay/WWN al inventario del host.

Listas de verificación / plan paso a paso

Lista de verificación A: ZED mínimo viable (haz esto esta semana)

1. Confirma que ZED está instalado y en ejecución: systemctl status zfs-zed.service.
2. Habilita ZED en el arranque: systemctl enable zfs-zed.service.
3. Escoge un destino de notificación (correo o script de integración local).
4. Establece ZED_EMAIL_ADDR (o wrapper) y ZED_NOTIFY_INTERVAL_SECS en /etc/zfs/zed.d/zed.rc.
5. Habilita solo los zedlets que piensas atender (scrub finish, cambios de estado de pool, errores de checksum).
6. Dispara un scrub en un pool no crítico y verifica que ves eventos de ZED en journald.
7. Asegúrate de que on-call recibe la alerta y puede identificar el disco por nombre estable.

Lista de verificación B: Cuando recibes una alerta “pool DEGRADED”

1. Ejecuta zpool status POOL. Captúrala en el ticket.
2. Identifica vdev afectado y dispositivo by-id; mapea al nodo de kernel.
3. Revisa dmesg -T por errores de transporte y resets.
4. Ejecuta smartctl -a en el dispositivo; busca pending/uncorrectable y logs de error.
5. Decide: reparación de ruta (cable/backplane/HBA) vs reemplazo de disco.
6. Realiza el cambio y luego vigila resilver y vuelve a comprobar contadores.
7. Tras volver a ONLINE, programa/verifica un scrub y vigila nuevas reparaciones.

Lista de verificación C: Simulacro trimestral de alertas (para confiar en ellas)

1. Escoge un host por clase de almacenamiento (mirror NVMe, RAIDZ, etc.).
2. Inicia un scrub y confirma que ZED ve scrub_start.
3. Confirma que las alertas de finalización de scrub incluyen bytes reparados y resumen de errores.
4. Confirma que la política de paginación se dispara en un estado degradado simulado (pool de prueba si es posible).
5. Revisa el throttling: asegura que no haya tormentas de pagers por errores blandos repetidos.
6. Actualiza runbooks con cualquier nuevo campo de evento que emita tu versión de ZED.

Preguntas frecuentes

1) ¿Qué es exactamente ZED?

ZED es el demonio de eventos de ZFS. Escucha eventos de ZFS y ejecuta scripts manejadores (zedlets) para notificar a humanos o activar acciones automatizadas.

2) ¿ZED es obligatorio para que ZFS funcione con seguridad?

ZFS puede detectar y corregir muchos problemas sin ZED. ZED es necesario para que tú funciones con seguridad: convierte riesgo silencioso en trabajo visible.

3) ¿Qué eventos deberían paginar a humanos y cuáles crear tickets?

Pagina por transiciones de estado que reducen redundancia (DEGRADED/FAULTED, dispositivo eliminado, errores no reparados). Crea ticket por reparaciones de scrub y errores blandos recurrentes.

4) ¿Por qué veo errores de checksum si ZFS “se autocura”?

Porque ZFS detectó datos malos y los reparó desde la redundancia. El error de checksum es la pista de que algo en la cadena falló.
Trátalo como una advertencia para investigar, especialmente si los errores aumentan.

5) ¿Con qué frecuencia debería ejecutar scrubs?

La práctica común es mensual para pools grandes, a veces semanal para flotas pequeñas o de alto riesgo. La cadencia adecuada depende del tiempo de reconstrucción,
tamaño de discos y tolerancia al riesgo. Sea cual sea tu elección, alerta en fallos y reparaciones.

6) ¿Puede ZED enviar alertas directamente a Slack/PagerDuty?

Normalmente se hace mediante un script wrapper invocado por un zedlet (o modificando/agregando un zedlet) que llame a tu canal de alertas interno.
Mantén la lógica en el lado de ZED mínima y resistente.

7) ¿Por qué mi pool quedó DEGRADED y luego volvió a ONLINE?

Los dispositivos pueden fluctuar: desconexiones breves, resets de controlador o tormentas de timeouts. ZFS puede marcar un dispositivo como UNAVAIL y luego reintegrarlo.
Eso no es “está bien”. Es un problema de confiabilidad de ruta o dispositivo.

8) ¿Debo fiarme de SMART “PASSED” para no reemplazar un disco?

No. SMART overall health es un heurístico grosero. Sectores pendientes, incorrigibles y logs de error importan más. También importan los contadores de error de ZFS.

9) ¿Cuál es la diferencia entre scrub y resilver para alertas?

Scrub es un escaneo planificado de integridad; alerta en la finalización y si hubo reparaciones/errores. Resilver es una reconstrucción/reparación tras cambios de dispositivo; alerta en inicio, anomalías de progreso y finalización.

10) ¿Y si ZED es demasiado ruidoso?

No lo silencies globalmente. Afínalo: limita, pagina solo en transiciones de estado y envía eventos informativos a logs. El ruido es un fallo de política, no una razón para quedarse ciego.

Próximos pasos prácticos

Si solo haces tres cosas después de leer esto, haz estas:

1. Asegúrate de que ZED se ejecute en todos lados donde uses ZFS, que arranque al inicio y registre en un lugar que realmente revises.
2. Haz que los resultados de scrub sean accionables: alerta en la finalización de scrub con reparaciones/errores y crea un workflow para investigar y cerrar el ciclo.
3. Pagina por pérdida de redundancia: DEGRADED/FAULTED no es una sugerencia. Es ZFS diciendo que tu margen de seguridad desapareció.

Luego haz la versión adulta: realiza un simulacro trimestral de alertas, mantén los zedlets pequeños y aburridos, y crea alertas que incluyan suficiente contexto
para que un humano pueda decidir en un minuto si cambiar un disco, un cable o un controlador.

ZFS ya está haciendo el trabajo de detección. ZED es cómo evitas que ese trabajo muera en silencio dentro de la máquina.