ZFS ZED : alertes qui vous préviennent d’une panne avant vos utilisateurs

Ce que ZED fait réellement (et ce qu’il ne fait pas)

ZFS est un système de fichiers et un gestionnaire de volumes doté d’un sens de préservation. Il calcule des sommes de contrôle, valide les lectures,
détecte la corruption, et enregistre des informations détaillées sur les fautes. Mais ZFS n’ira pas jusqu’à venir dans votre bureau pour se racler la gorge.
ZED est le messager.

À un niveau élevé, ZED écoute les événements ZFS (provenant du module noyau ZFS et des outils en espace utilisateur) et exécute de petits scripts gestionnaires
appelés zedlets. Ces scripts peuvent envoyer des e-mails, consigner dans syslog/journald, déclencher un spare chaud, enregistrer un historique, ou s’intégrer
à votre système d’alerte préféré à 3h du matin.

La ligne de séparation

• ZFS détecte et enregistre : erreurs, état dégradé, début/fin de resilver, début/fin de scrub, fautes de périphérique, etc.
• ZED réagit et notifie : « quelque chose s’est produit, voici les détails, faites ceci ensuite. »
• Votre supervision corrèle et escalade : réveille des humains, ouvre des tickets, suit le MTTR, et fait en sorte que ça devienne la responsabilité de quelqu’un.

ZED n’est pas un système de supervision complet. C’est un moteur de déclenchement et de contexte. Il ne dédupliquera pas les alertes à l’échelle d’une flotte
ni ne vous fournira des tableaux de bord SLO. Mais il vous donnera des signaux précoces, spécifiques et exploitables — le type qui vous permet de remplacer un disque
le mardi après-midi au lieu de pratiquer la chirurgie pendant une interruption client le samedi soir.

Une citation opérationnelle à garder près de vos runbooks :
L’espoir n’est pas une stratégie. — Gén. Gordon R. Sullivan

Blague n°1 : Les pannes de stockage sont comme les dentistes — si vous ne les voyez que quand ça fait mal, vous payez déjà plus cher.

Faits et historique importants pour l’exploitation

ZED n’est pas juste « un daemon quelconque ». C’est la surface opérationnelle de ZFS. Quelques faits et points de contexte facilitent la compréhension
de ce que vous déployez et pourquoi il se comporte ainsi :

1. ZFS est apparu chez Sun Microsystems au milieu des années 2000 avec une philosophie « stockage comme système » : sommes de contrôle, pool, snapshots, auto-réparation.
2. ZFS a été conçu pour se méfier des disques par défaut. Les sommes de contrôle de bout en bout ne sont pas une option ; c’est l’hypothèse de base.
3. OpenZFS a émergé comme effort multi-plateforme après la fragmentation de la lignée Solaris ; aujourd’hui Linux, FreeBSD et d’autres suivent OpenZFS.
4. ZED est né du besoin d’opérationnaliser les événements de faute. Détecter une faute est inutile si personne n’est informé.
5. ZFS possède un flux d’événements interne (pensez : « changements d’état et rapports de faute »), et ZED en est un consommateur qui transforme ces événements en actions.
6. Les scrubs sont une primitive de maintenance de première classe dans ZFS : lectures complètes périodiques pour détecter et réparer la corruption silencieuse tant que la redondance existe.
7. « Dégradé » n’est pas « hors service » dans ZFS, ce qui est précisément dangereux : le service continue, mais votre marge de sécurité a disparu.
8. Resilver n’est pas la même chose que scrub : resilver est la réparation ciblée après remplacement ou rattachement d’un périphérique ; scrub est une vérification à l’échelle du pool.
9. Beaucoup d’« erreurs » ZFS sont en fait l’avertissement, pas l’incident : les erreurs de checksum signifient souvent que le système a détecté des données corrompues et les a réparées.

La leçon opérationnelle : ZFS est bavard là où ça compte. ZED est la façon d’écouter sans vivre dans zpool status comme si c’était un réseau social.

Comment ZED perçoit le monde : événements, zedlets et état

Le travail de ZED est simple : lorsqu’un événement ZFS survient, exécuter des gestionnaires. La complexité est dans les détails : quels événements, quels gestionnaires,
comment gérer le débit, et comment inclure suffisamment de contexte dans vos alertes pour permettre d’agir sans creuser.

Sources d’événements et forme des données

ZFS émet des événements pour les changements d’état de pool, les erreurs de périphérique, l’activité scrub/resilver, et les actions de gestion des fautes. ZED les reçoit
et expose des champs d’événement aux zedlets sous forme de variables d’environnement. L’ensemble exact varie selon la plateforme et la version d’OpenZFS, mais vous verrez
des thèmes constants : nom du pool, GUID du vdev, chemin du périphérique, transitions d’état, et compteurs d’erreurs.

Zedlets : petits scripts tranchants

Les zedlets sont des scripts exécutables placés dans un répertoire zedlet (souvent sous /usr/lib/zfs/zed.d sur les distributions Linux,
avec des liens symboliques ou des ensembles activés sous /etc/zfs/zed.d). Ils sont volontairement petits. Ils doivent faire une chose bien :
formater un e-mail, écrire dans syslog, initier un spare, enregistrer une ligne d’historique, ou appeler un script d’intégration local.

La discipline : garder les zedlets déterministes et rapides. Si vous avez besoin d’une « logique réelle », faites en sorte que le zedlet mette la tâche en file
(écrire un fichier, émettre sur une socket locale, appeler un wrapper léger) et laissez un autre service faire le gros du travail. ZED fait partie de votre chemin de panne.
Ne l’alourdissez pas.

État et déduplication

ZED peut générer des événements répétés pour des périphériques qui oscillent ou des erreurs persistantes. Si vous paginez à chaque émission, vous allez entraîner votre équipe
à ignorer les alertes, puis vous récolterez ce qui arrive ensuite. Une bonne configuration ZED fait habituellement au moins une des actions suivantes :

• Limiter les notifications (par pool/vdev et par fenêtre temporelle).
• Envoyer des alertes de « changement d’état » (ONLINE→DEGRADED, DEGRADED→ONLINE) plutôt que chaque incrément.
• Envoyer les scrubs comme événements de synthèse (démarré, terminé, erreurs trouvées) avec le contexte.
• Conserver un petit fichier d’état qui trace ce qui a déjà été envoyé.

Ce sur quoi vous devriez alerter

N’alertez pas sur tout. L’alerte est un contrat avec des humains endormis. Voici une base saine :

• Changements d’état du pool : ONLINE→DEGRADED, DEGRADED→FAULTED, périphérique retiré.
• Résultats de scrub : terminé avec erreurs, octets réparés, ou « trop d’erreurs ».
• Erreurs de checksum/lecture/écriture au-delà d’un seuil ou avec un taux croissant.
• Événements de faute de périphérique : timeouts, échecs d’E/S, « device removed », changements de chemin.
• Fin de resilver : succès/échec, durée, si le pool revient à ONLINE.

Alertes qui méritent votre attention (et quoi en faire)

Une alerte ZED doit répondre à trois questions : que s’est-il passé, qu’est-ce qui est à risque, et que dois-je faire ensuite.
Si vos alertes n’incluent pas le nom du pool, le vdev affecté, et un extrait de zpool status -x ou un snippet pertinent,
vous écrivez des romans policiers, pas des alertes.

Pool DEGRADED

« DEGRADED » signifie que vous êtes en train de fonctionner sur la redondance. Vous servez encore, mais une nouvelle panne vous rapproche de la perte de données
(selon le niveau RAIDZ et le vdev concerné). La bonne réponse est limitée dans le temps : enquêter immédiatement ; remplacer rapidement ; ne pas attendre la prochaine fenêtre
de maintenance à moins d’aimer jouer.

Erreurs de checksum

Les erreurs de checksum sont ZFS qui vous dit « j’ai détecté des données corrompues ». C’est à la fois une bonne et une mauvaise nouvelle. Bien : la détection fonctionne.
Mauvais : quelque chose corrompt les données dans la pile — disque, câble, HBA, firmware, RAM (si vous n’avez pas d’ECC), ou même instabilité d’alimentation.
Votre décision dépendra de si les erreurs sont isolées (un seul disque, un seul chemin) ou systémiques (à travers des vdevs).

Erreurs de lecture/écriture

Les erreurs de lecture indiquent que le périphérique n’a pas pu renvoyer les données. ZFS peut reconstruire à partir de la parité/miroirs ; sinon, vous voyez des erreurs permanentes.
Les erreurs d’écriture pointent souvent vers la connectivité, des réinitialisations de contrôleur, ou un disque qui refuse d’écrire. Quoi qu’il en soit, traitez les compteurs en hausse comme « remplacer ou réparer le chemin ».

Scrub terminé avec erreurs

Un scrub qui a réparé des données est un avertissement : la redondance vous a sauvé cette fois. Si vous n’agissez pas, la prochaine fois ce pourrait être pire.
Un scrub qui a trouvé des erreurs non réparées est un incident d’intégrité des données ; votre travail devient l’évaluation des dégâts et la stratégie de restauration.

Périphérique retiré / UNAVAIL

Il s’agit souvent non pas d’un disque mort, mais d’un chemin mort. Câble SAS desserré, expander défaillant, bug firmware HBA, backplane instable.
La façon la plus rapide de brûler un week-end est de remplacer un disque parfaitement sain alors que le backplane est le vrai coupable.

Tâches pratiques : commandes, sorties et décisions (12+)

Voici les actions que vous effectuerez en vraie vie : vérifier que ZED tourne, valider qu’il peut envoyer des mails, déclencher des événements de test,
interpréter la santé du pool, et prendre des mesures correctives. Chaque tâche ci-dessous inclut : la commande, ce que la sortie signifie, et la décision à prendre.

Task 1: Confirm the ZED service is running (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

Ce que cela signifie : « active (running) » est le minimum requis. S’il est inactif, les événements ZFS se produisent toujours ; vous ne les entendez juste pas.

Décision : Si ce n’est pas en cours, corrigez ZED avant de faire confiance à toute « supervision » qui prétend surveiller ZFS.

Task 2: Inspect recent ZED logs in 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

Ce que cela signifie : Vous voulez voir des événements et des lignes d’exécution de zedlet. Le silence lors d’événements connus suggère une mauvaise configuration ou l’absence d’événements.

Décision : Si vous voyez des événements mais pas de notifications, concentrez-vous sur la configuration des zedlets (mail, permissions, PATH), pas sur ZFS lui-même.

Task 3: Validate ZED configuration file is sane

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

Ce que cela signifie : ZED est configuré pour consigner, envoyer des e-mails et limiter les alertes. L’absence de paramètres e-mail est un problème fréquent de type « on croyait avoir des alertes ».

Décision : Si votre organisation n’utilise pas l’e-mail, configurez ZED pour appeler un script wrapper qui parle à votre gestionnaire d’alertes, mais conservez la limitation.

Task 4: Confirm the mailer exists and works from the 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...

Ce que cela signifie : La première commande prouve que le programme mail configuré pour ZED existe. La seconde prouve que l’hôte peut effectivement livrer le mail (en file locale ou via relais).

Décision : Si le mail échoue, réparez la messagerie sortante avant d’accuser ZED. ZED ne peut pas notifier via un tuyau inexistant.

Task 5: List enabled zedlets (what actions you’re actually taking)

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

Ce que cela signifie : De nombreuses distributions fournissent des zedlets dans /usr/lib et activent un sous-ensemble via des liens symboliques dans /etc.

Décision : Si rien n’est activé, vous ne recevrez rien. Activez seulement ce sur quoi vous pouvez agir ; désactivez les zedlets bruyants jusqu’à ce que vous soyez prêt.

Task 6: Check overall pool health quickly (the “are we on fire” command)

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

Ce que cela signifie : C’est ZFS qui est concis. S’il affiche autre chose, vous avez du travail.

Décision : Un résultat healthy ne signifie pas « aucun risque », mais signifie que vous n’êtes pas activement dégradé/FAULTED.

Task 7: Deep status when something is wrong

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

Ce que cela signifie : Le pool est dégradé parce qu’un périphérique est indisponible. « No known data errors » est une bonne nouvelle ; la redondance tient encore.

Décision : Traitez UNAVAIL comme urgent. Investiguer chemin vs disque, puis remplacer ou restaurer la connectivité avant une seconde panne.

Task 8: Correlate ZFS device names to actual hardware

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

Ce que cela signifie : Vous pouvez mapper le chemin stable by-id de ZFS à un nœud de périphérique noyau (/dev/sde), ce qui aide pour SMART et le repérage physique d’emplacement.

Décision : Utilisez /dev/disk/by-id dans les pools autant que possible ; cela réduit les incidents de « mauvais disque retiré ».

Task 9: Check SMART health for the suspect disk

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

Ce que cela signifie : « PASSED » n’est pas une carte de sortie gratuite. Les secteurs en attente et les secteurs non récupérables sont des signes préoccupants même si le disque affiche confiance.

Décision : Si pending/uncorrectable est non nul et augmente, remplacez le disque. Si ZFS a déjà marqué UNAVAIL, il n’y a plus de débat.

Task 10: Inspect recent kernel messages for link resets or transport errors

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

Ce que cela signifie : Ça sent le « problème de chemin ». Cela peut être le disque, le câble/backplane, ou le contrôleur.

Décision : Avant de remplacer des disques en masse, changez de câble/emplacement si possible. Si les erreurs suivent l’emplacement, vous avez trouvé le vrai domaine de défaillance.

Task 11: Show ZFS error counters and watch for growth

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

Ce que cela signifie : Les compteurs (READ/WRITE/CKSUM) sont des preuves. Quelques erreurs historiques ne sont pas toujours catastrophiques, mais une augmentation est une tendance.

Décision : Si les compteurs augmentent après avoir reseaté les câbles ou redémarré, arrêtez de « tester des choses » et remplacez le composant dans le domaine en échec.

Task 12: Replace a failed disk the correct way

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

Ce que cela signifie : ZFS commence un resilver sur le nouveau disque, ciblé sur les blocs alloués (généralement plus rapide que la reconstruction RAID classique).

Décision : Surveillez la progression du resilver. Si le pool reste dégradé après resilver, vous avez d’autres problèmes (mauvais périphérique, pannes multiples, instabilité du chemin).

Task 13: Monitor resilver/scrub progress

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)

Ce que cela signifie : « issued at » reflète le débit d’écriture réel. « scanned at » peut être plus élevé à cause du parcours des métadonnées et du read-ahead.

Décision : Si le resilver traîne, ne devinez pas. Vérifiez les goulets d’étranglement I/O, les erreurs sur d’autres disques, ou les problèmes de contrôleur.

Task 14: Verify scrub scheduling and last results

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

Ce que cela signifie : Vous avez un enregistrement de la dernière fin de scrub. Si cela manque depuis des mois, vous roulez sans phares.

Décision : Si vous n’avez pas de scrubs périodiques, planifiez-les. Si vous en avez mais que vous n’alertez pas sur les échecs, configurez ZED maintenant.

Task 15: Confirm ZFS event delivery to ZED (sanity check)

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

Ce que cela signifie : Lancer un scrub produit un événement. Le voir dans les logs ZED prouve le flux d’événements.

Décision : Si vous ne voyez pas l’événement, dépannez le service ZED, les permissions, ou l’infrastructure d’événements ZFS sur cette plateforme.

Task 16: Check that ZED is not blocked by permissions or missing directories

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

Ce que cela signifie : ZED incapable d’écrire les logs ou d’exécuter les zedlets est ennuyeux, courant, et dévastateur pour l’alerte.

Décision : Corrigez les permissions et l’intégrité des paquets. Ne faites pas un « chmod 777 » pour vous en sortir ; gardez cela minimal et auditable.

Blague n°2 : ZED est comme un détecteur de fumée — les gens se plaignent qu’il est bruyant jusqu’au jour où il leur sauve leur week-end.

Playbook de diagnostic rapide

Voici la séquence « débloquez-vous vite ». Pas parfaite. Pas élégante. Optimisée pour : que vérifier en premier, deuxième, troisième pour trouver le goulot
et décider si vous avez affaire à un disque, un chemin, un problème au niveau du pool, ou un mauvais branchement d’alerte.

Premier : est-ce un vrai problème de pool ou juste des alertes manquantes ?

1. Vérifier la santé du pool : zpool status -x. S’il est healthy, vous déboguez peut-être ZED, pas ZFS.
2. Vérifier que ZED est vivant : systemctl status zfs-zed.service et journalctl -u zfs-zed.service.
3. Déclencher un événement inoffensif : lancer un scrub sur un pool de test ou faire un cycle de démarrage/arrêt de scrub (si tolérable). Confirmer que ZED journalise un événement.

Deuxième : si le pool est dégradé/FAULTED, localiser le domaine de défaillance

1. Identifier le vdev et le périphérique : zpool status POOL et noter les compteurs READ/WRITE/CKSUM.
2. Mapper by-id vers le périphérique réel : ls -l /dev/disk/by-id/ pour obtenir le nœud noyau.
3. Vérifier les logs noyau : dmesg -T pour les réinitialisations de lien, timeouts, erreurs de transport. Les problèmes de chemin apparaissent souvent ici en premier.
4. Vérifier SMART : smartctl -a pour les secteurs en attente/non récupérables et les logs d’erreur.

Troisième : décider si vous pouvez stabiliser sans remplacement

1. Si ça ressemble à un problème de chemin : reseater/remplacer le câble, déplacer le disque vers une autre baie, mettre à jour le firmware HBA (avec précaution), vérifier l’alimentation.
2. Si ça ressemble au média du disque : remplacer le disque. Ne négociez pas avec les secteurs en attente.
3. Après changement : surveiller le resilver et re-vérifier les compteurs. Si les compteurs continuent d’augmenter, arrêtez et élargissez le champ au contrôleur/backplane.

Quatrième : vérifier la qualité d’alerte

1. Assurer des alertes exploitables : inclure le nom du pool, l’identifiant du périphérique, le zpool status actuel, et les derniers résultats de scrub.
2. Limiter et dédupliquer : pager sur les transitions d’état ; e-mail ou ticket sur les avertissements répétés avec seuils de taux.
3. Faire un exercice trimestriel : simuler un événement (démarrage/fin de scrub, zedlet de test) et confirmer que la bonne équipe le reçoit.

Trois mini-récits d’entreprise issus du terrain stockage

Mini-récit 1 : L’incident causé par une mauvaise hypothèse

Une entreprise SaaS de taille moyenne utilisait ZFS sur Linux pour quelques nœuds de stockage « durables ». Ils avaient migré depuis un ancien contrôleur RAID et
étaient confiants : sommes de contrôle, scrubs, snapshots — tout y était. Ils pensaient aussi avoir de la supervision. Ou du moins c’est ce que tout le monde croyait.

La mauvaise hypothèse était subtile : « les alertes ZFS font partie du paquet ZFS ». Quelqu’un avait installé OpenZFS, créé des pools, planifié des scrubs,
et s’en était allé. ZED était installé mais pas activé. Personne ne l’avait remarqué car, au quotidien, ZFS est silencieux quand tout va bien.

Des mois plus tard, un disque commença à journaliser des timeouts intermittents. ZFS a retenté, réparé depuis la parité, et a continué à servir. Le pool est passé brièvement en DEGRADED,
puis est revenu ONLINE quand le disque est réapparu. Pas d’alerte, pas de ticket, pas de remplacement. Les compteurs d’erreurs ont augmenté doucement comme une fuite derrière un mur.

L’incident réel est arrivé lors d’une seconde panne disque pendant une période de lecture intensive. Le pool est devenu sévèrement DEGRADED et l’application a subi des pics de latence.
Les utilisateurs ont signalé des « uploads lents ». Les ops ont commencé par le mauvais bout du problème (tuning appli, load balancers) parce qu’ils n’avaient pas de signal précoce.

Les actions post-mortem furent ennuyeuses et correctes : activer ZED, câbler les notifications à la rotation on-call, pager sur la dégradation du pool, et inclure
les noms de périphériques by-id pour que quelqu’un puisse retirer le bon disque sans séance de spiritisme.

Mini-récit 2 : L’optimisation qui s’est retournée contre eux

Une équipe d’ingénierie des données voulait moins d’e-mails. Ils étaient fatigués des notes « scrub démarré » et « scrub terminé » qui encombraient les boîtes, et ils avaient raison :
les alertes n’étaient pas priorisées et personne ne les lisait attentivement.

L’« optimisation » a été de désactiver complètement les zedlets liés aux scrubs. Leur raisonnement : « nous faisons déjà des scrubs mensuels ; si quelque chose ne va pas, le pool sera dégradé ».
Cette dernière clause est une mine. Les résultats de scrub peuvent révéler des corruptions que ZFS a réparées silencieusement. Ce n’est pas un pool dégradé. C’est un coup d’avertissement.

Quelques mois plus tard, un scrub aurait détecté et réparé des erreurs de checksum sur un vdev, pointant vers un mauvais câble SAS. À la place, personne n’a vu le signal précoce.
Le câble a empiré. Finalement le disque est tombé pendant un resilver déclenché par une opération de maintenance non liée, prolongeant le resilver et augmentant le risque opérationnel.
L’équipe avait conçu un « système silencieux » qui a échoué bruyamment.

Ils ont corrigé cela en réactivant les alertes scrub mais en modifiant la politique : les événements de démarrage de scrub allaient dans des logs basse priorité ; les finitions de scrub avec réparations ou erreurs
généraient un ticket et une revue humaine. Le bruit a diminué. Le signal est revenu. C’est le bon compromis.

Mini-récit 3 : La pratique ennuyeuse qui a sauvé la situation

Un groupe IT d’entreprise gérait une flotte d’hôtes VM sur ZFS. Leur plateforme de stockage n’était pas excitante ; elle était volontairement terne. Ils avaient une norme stricte :
nommage by-id, vérification trimestrielle des scrubs, et un runbook on-call « remplacement disque » tenant sur une page.

Un jeudi, ZED a pagé « pool DEGRADED » avec le vdev affecté et le mapping du slot physique. L’hôte servait toujours les VM correctement.
La tentation en environnement corporate est de repousser le travail parce que « pas de panne ». Ils ne l’ont pas fait.

L’on-call a suivi le runbook : confirmer le statut, vérifier SMART, consulter les logs noyau, et remplacer le disque. Le resilver s’est terminé, le pool est revenu ONLINE,
et ils ont bouclé en vérifiant le scrub suivant. Pas d’escalade directionnelle, pas d’impact client, pas de salle de crise dramatique.

Deux jours plus tard, un autre hôte du même rack a eu un incident d’alimentation qui a provoqué une réinitialisation du contrôleur. Si le premier hôte était encore dégradé,
ce second événement aurait pu transformer un remplacement matériel routinier en restauration compliquée. La pratique ennuyeuse leur a acheté une marge.

Erreurs courantes : symptômes → cause racine → correction

1) Symptom: “We never get ZFS alerts”

Cause racine : Service ZED non activé/en cours d’exécution, ou zedlets non activés via /etc/zfs/zed.d.

Correction : Activer et démarrer ZED ; vérifier le flux d’événements avec un démarrage de scrub et contrôler journald pour les lignes d’exécution.

2) Symptom: “ZED logs events but no emails arrive”

Cause racine : Programme mail manquant, SMTP sortant bloqué, ou ZED_EMAIL_ADDR/ZED_EMAIL_PROG mal configurés.

Correction : Exécuter la même commande mail manuellement depuis l’hôte ; corriger relais/firewall/DNS ; puis retester ZED.

3) Symptom: “Pager storm during a flaky disk event”

Cause racine : Pas de throttling/dédoublonnage ; alerte sur chaque incrément d’erreur plutôt que sur le changement d’état.

Correction : Configurer l’intervalle de notification ; pager sur les transitions d’état du pool ; ouvrir un ticket sur les erreurs molles récurrentes avec seuils de taux.

4) Symptom: “Pool shows checksum errors on multiple disks at once”

Cause racine : Domaine de défaillance partagé (HBA, backplane, expander, câble, alimentation) ou corruption mémoire sur systèmes sans ECC.

Correction : Arrêtez de remplacer des disques au hasard. Inspectez dmesg pour les réinitialisations de transport, validez le firmware/driver HBA, échangez les câbles, et évaluez la posture RAM/ECC.

5) Symptom: “Scrub finished, repaired bytes, but everyone ignored it”

Cause racine : La politique d’alerte traite les résultats de scrub comme du bruit ; pas de workflow pour enquêter sur la corruption réparée.

Correction : Acheminer « scrub terminé avec réparations/erreurs » vers un ticket avec revue obligatoire et contrôles de suivi (SMART, câblage, compteurs).

6) Symptom: “Resilver takes forever and the pool stays fragile”

Cause racine : Goulet d’I/O sous-jacent, disques marginaux additionnels, ou problèmes de contrôleur provoquant des tentatives répétées.

Correction : Vérifier les compteurs d’erreurs des autres vdevs, dmesg pour les réinitialisations, et SMART pour les secteurs lents. Si plusieurs disques sont malades, stabilisez le matériel avant de forcer le resilver.

7) Symptom: “ZED runs zedlets but they fail silently”

Cause racine : Permissions, bits exécutables manquants, dépendances absentes dans le PATH, ou scripts dépendant d’un shell interactif.

Correction : Rendre les zedlets autonomes : chemins absolus, environnement explicite, gestion stricte des erreurs, journaliser les échecs dans journald/syslog.

8) Symptom: “Ops replaced the wrong disk”

Cause racine : Pools construits sur des noms /dev/sdX ; l’alerte n’inclut pas d’identifiants stables ; pas de processus de mapping des baies.

Correction : Utiliser /dev/disk/by-id dans les pools, inclure by-id dans les alertes, et maintenir un mapping bay/WWN vers l’inventaire hôte.

Listes de contrôle / plan étape par étape

Checklist A: Minimum viable ZED alerting (do this this week)

1. Confirmer que ZED est installé et en cours d’exécution : systemctl status zfs-zed.service.
2. Activer ZED au démarrage : systemctl enable zfs-zed.service.
3. Choisir une destination de notification (e-mail ou script d’intégration local).
4. Définir ZED_EMAIL_ADDR (ou wrapper) et ZED_NOTIFY_INTERVAL_SECS dans /etc/zfs/zed.d/zed.rc.
5. Activer uniquement les zedlets sur lesquels vous comptez agir (scrub finish, changements d’état du pool, erreurs de checksum).
6. Déclencher un scrub sur un pool non critique et vérifier que vous voyez les événements ZED dans journald.
7. Vérifier que l’on-call reçoit l’alerte et peut identifier le disque par un nom stable.

Checklist B: When you get a “pool DEGRADED” alert

1. Exécuter zpool status POOL. Capturer la sortie dans le ticket.
2. Identifier le vdev affecté et le périphérique by-id ; mapper vers le nœud de périphérique noyau.
3. Vérifier dmesg -T pour erreurs de transport et réinitialisations.
4. Exécuter smartctl -a sur le périphérique ; rechercher pending/uncorrectable et les logs d’erreur.
5. Décider : correction de chemin (câble/backplane/HBA) vs remplacement disque.
6. Effectuer le changement, puis surveiller le resilver et re-vérifier les compteurs.
7. Après retour à ONLINE, planifier/vérifier un scrub et surveiller de nouvelles réparations.

Checklist C: Quarterly alerting fire drill (so you trust it)

1. Choisir un hôte par classe de stockage (miroir NVMe, RAIDZ, etc.).
2. Lancer un scrub et confirmer que ZED voit scrub_start.
3. Confirmer que les alertes de fin de scrub incluent les octets réparés et le résumé des erreurs.
4. Confirmer que votre politique de paging se déclenche sur un état dégradé simulé (pool de test non productif si possible).
5. Revoir le throttling : s’assurer qu’il n’y a pas de pager storm pour des erreurs molles répétées.
6. Mettre à jour les runbooks avec tout nouveau champ d’événement émis par votre version de ZED.

FAQ

1) What exactly is ZED?

ZED est le ZFS Event Daemon. Il écoute les événements ZFS et exécute des scripts gestionnaires (zedlets) pour notifier des humains ou déclencher des actions automatisées.

2) Is ZED required for ZFS to function safely?

ZFS peut détecter et corriger de nombreux problèmes sans ZED. ZED est requis pour vous afin de fonctionner en sécurité : il transforme un risque silencieux en travail visible.

3) What events should page humans vs create tickets?

Pager sur les transitions d’état qui réduisent la redondance (DEGRADED/FAULTED, périphérique retiré, erreurs non réparées). Créer un ticket pour les réparations de scrub et les erreurs molles récurrentes.

4) Why do I see checksum errors if ZFS “self-heals”?

Parce que ZFS a détecté des données corrompues et les a réparées à partir de la redondance. L’erreur de checksum est la trace de preuves qu’il y a eu un comportement anormal dans la pile.
Traitez-la comme un avertissement à enquêter, surtout si les erreurs augmentent.

5) How often should I run scrubs?

Pratique courante : mensuel pour les grands pools, parfois hebdomadaire pour des flottes plus petites ou à risque élevé. La cadence dépend du temps de rebuild,
de la taille des disques et de la tolérance au risque. Quelle que soit votre fréquence, alertez sur les échecs et réparations.

6) Can ZED send alerts to Slack/PagerDuty directly?

Typiquement on le fait via un script wrapper invoqué par un zedlet (ou en modifiant/ajoutant un zedlet) qui appelle votre pipeline d’alerte interne.
Gardez la logique côté ZED minimale et résiliente.

7) Why did my pool go DEGRADED and then return to ONLINE?

Les périphériques peuvent osciller : déconnexions brèves, réinitialisations de contrôleur, ou orages de timeout. ZFS peut marquer un périphérique UNAVAIL puis le réintégrer.
Ce n’est pas « acceptable ». C’est un problème de fiabilité du chemin ou du périphérique.

8) Should I rely on SMART “PASSED” to decide not to replace a disk?

Non. Le statut global SMART est un heuristique grossier. Les secteurs en attente, les non-récupérables, et les logs d’erreur comptent davantage. Les compteurs d’erreur ZFS comptent aussi.

9) What’s the difference between scrub and resilver for alerting?

Scrub est un scan d’intégrité planifié ; alertez sur la fin et si des réparations/erreurs ont eu lieu. Resilver est une reconstruction/réparation après des changements de périphérique ; alertez sur le début, les anomalies de progression, et la fin.

10) What if ZED is too noisy?

Ne le mettez pas en sourdine globalement. Réglez-le : throttle, pager seulement sur les transitions d’état, et envoyer les événements d’information vers les logs. Le bruit est un bug de politique, pas une raison pour aveugler l’équipe.

Prochaines étapes pratiques

Si vous ne faites que trois choses après avoir lu ceci, faites celles-ci :

1. Veillez à ce que ZED fonctionne partout où vous exécutez ZFS, qu’il démarre au boot, et qu’il consigne à un endroit que vous consultez réellement.
2. Rendez les résultats de scrub exploitables : alerter sur la fin de scrub avec réparations/erreurs, et créer un workflow pour enquêter et clore la boucle.
3. Pager sur la perte de redondance : DEGRADED/FAULTED n’est pas une suggestion. C’est ZFS qui vous dit que votre marge de sécurité a disparu.

Ensuite faites la version mûre : organisez un exercice trimestriel d’alerte, gardez les zedlets petits et ennuyeux, et construisez des alertes qui incluent suffisamment de contexte
pour qu’un humain puisse décider en une minute s’il faut remplacer un disque, un câble, ou un contrôleur.

ZFS fait déjà le travail de détection. ZED est la façon d’empêcher ce travail de mourir silencieusement à l’intérieur de la machine.