Événements zpool ZFS : le journal que vous ignorez jusqu’à ce qu’il vous sauve

Ce que sont réellement les événements zpool (et ce qu’ils ne sont pas)

zpool events est le flux d’événements de ZFS. Il affiche une chronologie des événements importants liés au pool :
erreurs d’E/S disque, problèmes de checksum, changements d’état des vdev, démarrages et terminaisons de scrub, resilvers, et divers rapports de gestion des fautes (« ereports »).
C’est ce que vous auriez voulu conserver quand quelqu’un demande : « Quand est-ce que ça a commencé ? »

Ce n’est pas un remplacement de zpool status. Pensez-y ainsi :

• zpool status vous dit l’état actuel et un résumé historique (erreurs récentes, resilver/scrub en cours, etc.).
• zpool events vous raconte la séquence d’événements qui vous y a conduit, souvent avec plus de contexte et l’heure exacte.
• Les journaux système (messages kernel, journalctl) vous donnent les symptômes au niveau OS : réinitialisations, délais, interférences de lien.

Sous le capot, sur de nombreuses plateformes, ZFS s’intègre à une chaîne de gestion des fautes. Sur illumos/Solaris vous verrez
le vocabulaire de la Fault Management Architecture (FMA) plus explicitement. Sur Linux, ZED (ZFS Event Daemon) et la réalité udev-ish
fournissent le pont « quelque chose s’est produit » vers des scripts, des e‑mails et des systèmes de tickets. Les mots diffèrent ; l’intention opérationnelle
est la même : transformer des bizarreries bas niveau en page d’alerte avant que les données soient en danger.

Votre travail n’est pas de mémoriser chaque classe d’événement. Votre travail est de construire l’habitude de corréler :
événement → périphérique → symptôme de charge → risque → action. Faites cela, et zpool events cesse d’être un détail anecdotique pour devenir un levier.

Première plaisanterie sèche, comme promis : ZFS a un grand sens de l’humour—chaque « erreur de checksum » est une chute dont votre fournisseur de stockage est la mise en place.

Faits intéressants et un peu d’histoire

Ce n’est pas de la nostalgie. Ce sont des indices sur pourquoi les outils ressemblent à ce qu’ils sont et pourquoi certains comportements surprennent.

1. ZFS est né chez Sun Microsystems et a été conçu pour traiter l’intégrité des données comme une fonctionnalité de première classe, pas comme un accessoire au mieux-disant.
2. Le checksum de bout en bout signifie que ZFS vérifie les données du disque à la mémoire puis au chemin de lecture de l’application ; il peut détecter une corruption silencieuse que des contrôleurs RAID acceptent volontiers comme « terminée ».
3. Le langage « ereport » vient de FMA (Fault Management Architecture), où les fautes et diagnostics sont structurés, pas du spam de logs libre.
4. zpool scrub est une vérification proactive ; ce n’est pas de la « défragmentation » ni du « théâtre de maintenance ». C’est une manière contrôlée de trouver des erreurs latentes avant qu’un disque ne tombe en panne.
5. Le resilvering est incrémental dans OpenZFS moderne : il peut copier uniquement ce qui est utilisé (surtout avec des fonctions comme le resilver séquentiel), réduisant le temps de reconstruction par rapport aux anciens rebuild RAID.
6. ZFS privilégie volontairement la correction à l’optimisme ; il dégradera un pool plutôt que de faire semblant que tout va bien si la lecture d’un périphérique n’est pas fiable.
7. Le démon ZED existe parce que les événements nécessitent des actions ; la sortie de commande est utile, mais opérationnellement vous voulez des hooks : alertes, workflows de remplacement et exportations automatiques pour les événements de retrait.
8. Historiquement, les piles de stockage cachaient les erreurs derrière des « retries » et des caches de contrôleur ; ZFS a rendu les erreurs visibles, ce qui est excellent—à condition de ne pas ignorer la visibilité.
9. OpenZFS est devenu multi-plateforme (Linux, FreeBSD, illumos), et la tuyauterie des événements diffère selon l’OS, d’où la nécessité de nommer les hypothèses de plateforme lorsque l’on donne des conseils.

Une implication opérationnelle réelle : les personnes migrantes depuis du RAID matériel supposent souvent que le contrôleur « s’en chargera ».
ZFS suppose le contraire : la pile est peu fiable jusqu’à preuve du contraire. Ce n’est pas de la paranoïa. C’est de l’expérience.

Un modèle mental pratique : symptômes → événements → décisions

1) Les événements sont des signaux ; le status est le résumé diagnostique

Quand un vdev passe en DEGRADED, zpool status vous dit ce qu’il est maintenant. Mais zpool events peut vous dire s’il s’agissait de :
tempêtes de réinitialisations de lien, un simple câble défectueux, des délais firmware, un problème d’alimentation, ou une vraie défaillance média. Ces cas ont des corrections différentes.

2) Toutes les erreurs ne se valent pas

Trois catégories comptent opérationnellement :

• Erreurs de transport transitoires (délais, réinitialisations) : souvent câblage/HBA/backplane/alimentation. Remplacer les disques et vous resterez cassé.
• Erreurs de lecture persistantes : probablement une défaillance média. Remplacez le périphérique ; vérifiez votre redondance et lancez un resilver.
• Erreurs de checksum : peuvent venir du disque, du câble, du contrôleur, de la RAM (moins courant avec ECC), ou du firmware. Vous avez besoin de corrélation, pas de conjectures.

3) « Le scrub a trouvé des erreurs » signifie « vous venez d’apprendre quelque chose », pas « panique »

Les erreurs trouvées par le scrub sont de la télémétrie d’alerte précoce. Votre réponse doit être calme et méthodique :
identifiez quels périphériques, quel type d’erreur, si les erreurs se répètent, et si la redondance a couvert les dégâts.
La chronologie des événements vous aide à déterminer s’il s’agit d’un incident isolé ou d’une tendance.

4) Opérationnellement, vous poursuivez deux questions

• Les données sont-elles en risque maintenant ? (pool faulted, pas de redondance, erreurs pendant scrub/resilver)
• La plateforme ment-elle ? (instabilité du transport, réinitialisations intermittentes, erreurs de checksum « aléatoires » sur plusieurs disques)

La première question détermine l’urgence. La seconde décide si votre correction réparera réellement le problème.

Une citation qui devrait figurer dans chaque rotation on-call, d’une voix notable de la fiabilité :
« L’espoir n’est pas une stratégie. » — Gene Kranz

Feuille de route pour diagnostic rapide (quoi vérifier 1er/2e/3e)

Voici la séquence que j’utilise quand un pool a l’air malade, que les performances chutent, ou que quelqu’un poste une capture d’écran de DEGRADED dans le chat
sans autre contexte. Elle est conçue pour la rapidité et pour éviter l’erreur classique : échanger des disques avant de savoir ce qui a échoué.

Premier : établir le risque actuel et si vous êtes déjà en mode « arrêter l’hémorragie »

• Vérifier l’état du pool (zpool status -x, zpool status) : êtes-vous dégradé, faulted, suspended, resilvering, ou scrubbing ?
• Vérifier si la redondance est intacte : combien de vdevs, quel niveau de parité, périphériques manquants ?
• Vérifier si les erreurs augmentent encore : des compteurs de lecture/écriture/checksum qui montent indiquent un problème actif.

Deuxième : extraire la chronologie des événements et identifier la classe de défaillance

• Regarder les événements récents (zpool events -v) : voyez‑vous des délais, des suppressions, des ereports de checksum, un scrub terminé avec des erreurs ?
• Corréler les horodatages avec les journaux kernel : les réinitialisations de lien et les erreurs SCSI racontent souvent l’histoire du transport.
• Chercher la dispersion : un seul disque contre plusieurs disques sur le même HBA/backplane. Plusieurs disques qui échouent en même temps n’est généralement pas de la « malchance ».

Troisième : décider la voie—remplacement matériel, stabilisation du transport, ou confinement de la charge

• Dispositif unique avec erreurs de lecture persistantes : préparer le remplacement, mettre hors ligne/remplacer, surveiller le resilver.
• Plusieurs dispositifs avec problèmes intermittents : vérifier câbles, firmware/driver HBA, backplane, alimentation ; éviter les défaillances en cascade pendant une reconstruction lourde.
• Scrub/resilver lent : inspecter la saturation I/O, incompatibilité recordsize/workload, problèmes de vdev spéciaux, comportement SMR, ou un périphérique malade qui bride le vdev.

Si vous ne retenez qu’une chose : la façon la plus rapide de perdre une journée est de remplacer du matériel avant de classer la défaillance.
Les événements vous aident à la classifier.

Tâches pratiques : commandes, sorties et la décision que vous prenez

Ce sont des tâches réelles que vous pouvez exécuter pendant un incident ou comme hygiène de routine. Chacune inclut :
la commande, un exemple de ce que vous pourriez voir, ce que cela signifie, et ce que vous décidez ensuite.
Les noms d’hôtes et des pools sont volontairement fades ; les systèmes de production le sont rarement.

Task 1: “Is anything actually wrong?” quick check

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

Signification : ZFS ne voit pas de fautes connues pour l’instant.
Décision : Si les utilisateurs rapportent une lenteur malgré tout, pivotez vers le triage performance (iostat, latence, profondeur de file d’attente). Vérifiez quand même les événements pour des problèmes transitoires récents.

Task 2: Get the full current health picture (don’t be lazy)

cr0x@server:~$ zpool status
  pool: tank
 state: DEGRADED
status: One or more devices has experienced an error resulting in data corruption.
action: Replace the device using 'zpool replace'.
  scan: scrub repaired 0B in 03:12:11 with 2 errors on Sun Dec 21 01:10:44 2025
config:

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          raidz1-0                  DEGRADED     0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     0
            ata-WDC_WD80...-part1   ONLINE       0     0     2

errors: Permanent errors have been detected in the following files:
        tank/data/vmstore/guest42.img

Signification : Un scrub a trouvé une corruption irrécupérable affectant au moins un fichier ; des erreurs de checksum pointent vers un chemin de disque précis.
Décision : Traiter comme incident d’intégrité des données. Identifier si la corruption est limitée à ce fichier, restaurer depuis sauvegarde/snapshot, et enquêter immédiatement sur le disque/le transport.

Task 3: Pull recent events with verbose details

cr0x@server:~$ zpool events -v | tail -n 40
time: 2025-12-21.01:10:44
eid: 1876
class: scrub_finish
pool: tank
pool_guid: 1234567890123456789
scrub_errors: 2
scrub_repaired: 0
scrub_time_secs: 11531

time: 2025-12-21.00:58:19
eid: 1869
class: ereport.fs.zfs.checksum
pool: tank
vdev_guid: 9876543210987654321
vdev_path: /dev/disk/by-id/ata-WDC_WD80...-part1
zio_err: 52
zio_objset: 54
zio_object: 102938
zio_level: 0

Signification : Vous avez un ereport de checksum lié à un chemin de vdev spécifique avant la fin du scrub avec erreurs.
Décision : Corréler cet horodatage avec les journaux kernel ; décider si le disque est défectueux ou si le transport est instable. Commencez par vérifier le transport si des événements similaires existent pour plusieurs disques.

Task 4: Follow events live during a rebuild or suspected flapping

cr0x@server:~$ zpool events -f
time: 2025-12-25.09:14:03
eid: 2101
class: resilver_start
pool: tank
vdev_path: /dev/disk/by-id/ata-WDC_WD80...-part1

time: 2025-12-25.09:16:27
eid: 2104
class: ereport.fs.zfs.io
pool: tank
vdev_path: /dev/disk/by-id/ata-WDC_WD80...-part1
zio_err: 5

Signification : Les erreurs pendant un resilver sont particulièrement dangereuses : vous stressez le système alors que la redondance est réduite.
Décision : Si les erreurs persistent, mettez en pause et stabilisez : vérifiez câbles/HBA, envisagez de mettre hors ligne le périphérique suspect pour éviter la suspension du pool, et réduisez la charge pendant le resilver.

Task 5: Confirm pool properties that affect behavior during incidents

cr0x@server:~$ zpool get -o name,property,value,source autoreplace,failmode,autotrim tank
NAME  PROPERTY     VALUE     SOURCE
tank  autoreplace  off       default
tank  failmode     wait      default
tank  autotrim     on        local

Signification : failmode=wait peut bloquer les I/O quand le pool ne peut pas procéder en toute sécurité ; autoreplace=off signifie que vous devez remplacer explicitement.
Décision : Pour des flottes, standardisez ces paramètres. Pour un incident, connaître failmode explique « pourquoi tout a gelé » et informe si vous devez exporter/importer ou basculer.

Task 6: Identify the exact disk behind a vdev path

cr0x@server:~$ ls -l /dev/disk/by-id/ata-WDC_WD80...-part1
lrwxrwxrwx 1 root root 10 Dec 25 08:59 /dev/disk/by-id/ata-WDC_WD80...-part1 -> ../../sdc1

Signification : Le chemin « friendly » by-id correspond actuellement à /dev/sdc1.
Décision : Utilisez les chemins by-id dans la configuration ZFS pour réduire la « roulette sdX » après les redémarrages. Pour le remplacement, confirmez l’emplacement physique avec des outils d’armoire si disponibles.

Task 7: Correlate ZFS events with OS-level resets/timeouts (Linux)

cr0x@server:~$ journalctl -k --since "2025-12-21 00:50" --until "2025-12-21 01:05" | egrep -i "sd[cde]|ata|sas|reset|timeout|I/O error" | tail -n 20
Dec 21 00:58:11 server kernel: ata7.00: exception Emask 0x0 SAct 0x0 SErr 0x0 action 0x6 frozen
Dec 21 00:58:12 server kernel: ata7.00: failed command: READ FPDMA QUEUED
Dec 21 00:58:12 server kernel: ata7: hard resetting link
Dec 21 00:58:17 server kernel: sd 7:0:0:0: [sdc] tag#12 FAILED Result: hostbyte=DID_OK driverbyte=DRIVER_SENSE
Dec 21 00:58:17 server kernel: sd 7:0:0:0: [sdc] Sense Key : Medium Error [current]
Dec 21 00:58:17 server kernel: blk_update_request: I/O error, dev sdc, sector 771920896 op 0x0:(READ) flags 0x0 phys_seg 1 prio class 0

Signification : Cela ressemble à un vrai problème média (Medium Error) plus des réinitialisations. Ce n’est pas juste un « léger coup de câble ».
Décision : Remplacez le disque. Pendant que vous y êtes, inspectez aussi le câblage/backplane si vous voyez des réinitialisations sur plusieurs ports.

Task 8: Verify scrub schedule and last scrub result

cr0x@server:~$ zpool status tank | sed -n '1,20p'
  pool: tank
 state: ONLINE
  scan: scrub repaired 0B in 02:44:09 with 0 errors on Sun Dec 14 03:12:33 2025
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0

Signification : Un scrub récent s’est terminé proprement ; bonne ligne de base.
Décision : Si l’incident d’aujourd’hui est « soudain », comparez avec le timing des événements. Un scrub propre la semaine dernière rend « des mois de corruption silencieuse » moins probable.

Task 9: Trigger a scrub intentionally (and watch for trouble)

cr0x@server:~$ sudo zpool scrub tank
cr0x@server:~$ zpool status tank | egrep -i "scan|scrub"
  scan: scrub in progress since Thu Dec 25 09:22:10 2025
        312G scanned at 1.12G/s, 74.2G issued at 273M/s, 4.21T total
        0B repaired, 1.72% done, no estimated completion time

Signification : Le scrub est en cours ; le débit « issued » montre les lectures soumises. S’il rampe, quelque chose bride.
Décision : Si la vitesse du scrub s’effondre, vérifiez un disque malade, des disques SMR ou un système surchargé. Envisagez de programmer les scrubs hors‑pic ou de réduire temporairement la charge.

Task 10: Find whether errors are concentrated on one vdev (quick per-vdev view)

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

        NAME                        STATE     READ WRITE CKSUM
        tank                        DEGRADED     0     0     0
          mirror-0                  DEGRADED     0     0     0
            /dev/disk/by-id/ata-ST4000...  ONLINE       0     0     0
            /dev/disk/by-id/ata-ST4000...  DEGRADED     0     0    34

errors: No known data errors

Signification : Beaucoup d’erreurs de checksum d’un côté d’un mirror, mais ZFS a pu les corriger en utilisant l’autre côté (pas d’erreurs permanentes).
Décision : C’est malgré tout un défaut matériel/de transport. Prévoyez le remplacement ; ne vous félicitez pas seulement parce que la redondance vous a sauvé cette fois.

Task 11: Replace a failed disk safely (mirror example)

cr0x@server:~$ sudo zpool offline tank /dev/disk/by-id/ata-ST4000...bad
cr0x@server:~$ sudo zpool replace tank /dev/disk/by-id/ata-ST4000...bad /dev/disk/by-id/ata-ST4000...new
cr0x@server:~$ zpool status tank | egrep -i "state|scan|resilver"
 state: DEGRADED
  scan: resilver in progress since Thu Dec 25 09:31:02 2025
        98.4G scanned at 1.02G/s, 21.7G issued at 231M/s, 98.4G total
        21.7G resilvered, 22.06% done, 0:05:09 to go

Signification : Remplacement initié ; le resilver progresse.
Décision : Surveillez les nouveaux événements pendant le resilver. Si d’autres périphériques tombent en erreur, arrêtez et réévaluez la plateforme (HBA/backplane/alimentation) avant de transformer une panne en trois.

Task 12: Check ZED is installed and running (Linux systemd)

cr0x@server:~$ systemctl status zfs-zed.service --no-pager
● zfs-zed.service - ZFS Event Daemon (zed)
     Loaded: loaded (/lib/systemd/system/zfs-zed.service; enabled; preset: enabled)
     Active: active (running) since Thu 2025-12-25 07:12:09 UTC; 2h 19min ago
       Docs: man:zed(8)
   Main PID: 1124 (zed)
      Tasks: 2 (limit: 38454)
     Memory: 4.3M
        CPU: 1.221s

Signification : ZED tourne, donc les événements peuvent déclencher notifications et scripts.
Décision : Si ZED n’est pas actif, vous comptez sur des humains pour remarquer zpool status. Corrigez cela—aujourd’hui, pas « après la fin du trimestre ».

Task 13: Inspect ZED’s recent activity for missed alerts

cr0x@server:~$ journalctl -u zfs-zed.service --since "2025-12-21 00:00" | tail -n 25
Dec 21 00:58:20 server zed[1124]: eid=1869 class=ereport.fs.zfs.checksum pool=tank
Dec 21 00:58:20 server zed[1124]: Executing ZEDLET: /usr/lib/zfs/zed.d/zed.rc
Dec 21 00:58:20 server zed[1124]: Executing ZEDLET: /usr/lib/zfs/zed.d/all-syslog.sh
Dec 21 00:58:20 server zed[1124]: Executing ZEDLET: /usr/lib/zfs/zed.d/zed.email
Dec 21 00:58:20 server zed[1124]: email: to=storage-oncall@example.internal subject="ZFS checksum error on tank"

Signification : ZED a vu l’ereport de checksum et a exécuté les hooks d’alerte.
Décision : Si l’astreinte prétend « n’avoir reçu aucune alerte », vérifiez le routage mail/l’ingestion du monitoring. ZFS a fait sa partie ; votre chaîne de notification peut être le maillon faible.

Task 14: Check for pool suspension symptoms (the “everything hangs” incident)

cr0x@server:~$ zpool status tank | egrep -i "state|suspend|status"
 state: ONLINE
status: One or more devices has been removed by the administrator.
        Sufficient replicas exist for the pool to continue functioning in a degraded state.
action: Online the device using 'zpool online' or replace the device with 'zpool replace'.

Signification : Pas de suspension ici, mais c’est l’endroit où vous la verrez. Si le pool est suspendu, les applications bloquent souvent sur les I/O.
Décision : Si suspendu, cessez de le marteler avec des retries. Stabilisez le matériel, envisagez d’exporter/importer, et priorisez l’évacuation des données ou le basculement.

Task 15: Get a clean “what changed recently” list from events

cr0x@server:~$ zpool events | egrep "vdev_(add|remove)|config_sync|scrub_start|scrub_finish|resilver_(start|finish)" | tail -n 20
time: 2025-12-25.09:14:03 class: resilver_start
time: 2025-12-25.09:20:11 class: config_sync
time: 2025-12-25.09:37:18 class: resilver_finish
time: 2025-12-25.09:40:00 class: scrub_start

Signification : Vous pouvez voir le cycle de vie des opérations : début/fin de resilver, config sync, début de scrub.
Décision : Utilisez ceci pour expliquer cause/effet dans les notes d’incident et pour détecter « quelqu’un a lancé un scrub en heures de pointe » sans supposer.

Task 16: Extract events since a known bad time for incident timelines

cr0x@server:~$ zpool events -v | awk '/time: 2025-12-21/{p=1} p{print}'
time: 2025-12-21.00:58:19
eid: 1869
class: ereport.fs.zfs.checksum
pool: tank
vdev_path: /dev/disk/by-id/ata-WDC_WD80...-part1
zio_err: 52

Signification : Une façon rapide d’extraire des blocs d’événements pertinents pour un postmortem ou un ticket.
Décision : Conservez cette sortie pendant les incidents. Les événements peuvent défiler ou être éphémères selon la plateforme et les outils ; votre ticket ne doit pas compter sur « on le reproduira ».

Trois mini-histoires d’entreprise (erreurs à éviter)

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

L’entreprise exploitait un cluster de virtualisation de taille moyenne sur des mirrors ZFS. Bon choix : rebuilds simples et rapides, domaines de défaillance clairs.
Le runbook on-call disait : « Si un disque montre des erreurs de checksum, remplacez-le. » Ce n’est pas un mauvais conseil. C’est aussi incomplet.

Un mardi, des erreurs de checksum ont commencé à apparaître sur deux hôtes—pools différents, disques différents, même modèle de HBA. L’on-call a remplacé un disque sur l’hôte A.
Le resilver a démarré, puis l’hôte A a généré plus d’erreurs de checksum, puis des délais, puis le pool s’est bloqué suffisamment longtemps pour déclencher les watchdogs des guests.
« Lot défectueux de disques », a‑t‑on dit, parce que c’est l’histoire que tout le monde a déjà entendue.

La trace d’événements—ignorée jusqu’après coup—montrait quelque chose de plus précis : des rafales d’erreurs d’E/S et des réinitialisations de lien qui coïncidaient avec une mise à jour d’un module kernel particulier.
Les disques ne mouraient pas indépendamment ; le transport battait de l’aile sous charge. Remplacer un disque augmentait la charge (lectures/écritures du resilver), aggravant les réinitialisations.

La correction n’était pas « plus de disques ». C’était figer la version du driver HBA, ajuster les paramètres de file, et planifier les resilvers seulement après avoir confirmé la stabilité du transport.
Ils ont quand même remplacé un disque finalement—parce qu’un avait de véritables erreurs média—mais pas avant d’arrêter la défaillance systémique.

La mauvaise hypothèse : « Erreurs de checksum = disque ». Parfois oui. Parfois cela signifie « tout le chemin I/O est suspect ». Les événements vous indiquent dans quelle histoire vous êtes.

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

Une autre équipe aimait les tableaux de bord. Ils voulaient moins de pages, moins de « faux positifs », et une astreinte plus calme. Objectifs louables.
Ils ont décidé d’alerter uniquement sur les changements d’état zpool status : ONLINE→DEGRADED, DEGRADED→FAULTED. Pas d’alertes pour des événements comme les délais ou un seul ereport de checksum.

L’environnement a tourné des mois sans problème. Puis un backplane a commencé à lâcher un disque de façon intermittente pendant de courtes secondes lors de rafales d’écriture.
ZFS le marquait comme indisponible brièvement, réessayait, et récupérait. Le pool ne restait jamais assez longtemps en état dégradé pour déclencher l’alerte de « changement d’état ».
Pendant ce temps, zpool events hurlait presque dans le vide avec un motif répétitif : erreurs I/O, retrait de périphérique, retour de périphérique, config sync.

Le premier vrai symptôme remarqué par des humains n’était pas une alerte. C’était une base de données lente puis un resilver prolongé après que le disque a enfin cessé de revenir.
À ce moment-là, le pool avait subi des semaines de cycles de stress et avait moins de marge que quiconque ne le réalisait.

Après l’incident, ils ont réintroduit des alertes pour des classes d’événements spécifiques (retrails, ereports I/O, rafales de checksum) avec limitation de débit et corrélation.
Moins de pages ? Oui. Mais pas en devenant aveugle. En devenant plus intelligent.

Deuxième plaisanterie sèche : Le système de surveillance le plus silencieux est aussi le moins cher—jusqu’à ce que vous calculiez le coût d’une panne.

Mini-histoire 3 : La pratique ennuyeuse mais correcte qui a sauvé la mise

Une organisation financière exploitait ZFS sur une paire de nœuds de stockage. Rien d’exotique : RAIDZ2 pour les datasets volumineux, SLOG en miroir pour les charges sync, scrubs réguliers, et ZED lié aux tickets.
La configuration était tellement banale que personne n’en parlait, ce qui est exactement ce que l’on souhaite pour le stockage.

Pendant un scrub hebdomadaire de routine, ZFS a enregistré un petit nombre d’erreurs de checksum sur un disque. Pas d’erreurs de données permanentes. Le pool est resté ONLINE.
ZED a généré un ticket avec le by-id du périphérique, l’hôte et le contexte du scrub. Le ticket n’était pas urgent, mais il n’a pas été ignoré.

L’ingénieur stockage a consulté zpool events -v et a vu que les ereports de checksum étaient groupés sur une fenêtre de cinq minutes.
Les logs kernel dans cette fenêtre montraient une réinitialisation de lien unique sur une voie SAS—classique « coupure de transport ». Ils ont resserré le câble lors de la fenêtre de maintenance, puis relancé un scrub.
Plus d’erreurs.

Deux mois plus tard, le même backplane a commencé à défaillir plus sérieusement sur un autre emplacement. Cette fois, parce qu’ils avaient de l’historique,
ils ont reconnu le motif immédiatement. Ils ont préventivement déplacé les disques hors de l’armoire suspecte avant que cela ne cause un incident multi-disques.

La pratique qui a sauvé la mise n’était pas de l’héroïsme. C’était : scrubs programmés, tickets déclenchés par événements, et lire réellement la chronologie.
S’ennuyer est une fonctionnalité.

Erreurs courantes : symptôme → cause racine → correction

Cette section est volontairement directe. Voici les modes de défaillance que j’ai vus les gens répéter parce qu’ils « ont géré ZFS une fois »
et ont supposé que cela signifiait « comprendre le stockage ».

1) « Pool est dégradé, mais les performances vont bien » → complaisance → panne surprise

• Symptôme : état DEGRADED pendant des jours ; les utilisateurs ne se plaignent pas.
• Cause racine : vous opérez sans marge de redondance. La prochaine faute devient une panne ou une perte de données.
• Correction : Remplacez/restaurez la redondance rapidement. Utilisez zpool events -v pour confirmer que la défaillance est localisée et pas liée au transport avant de remplacer.

2) « Erreurs de checksum aléatoires sur plusieurs disques » → mauvais diagnostic « disques défectueux » → remplacements gaspillés

• Symptôme : erreurs de checksum apparaissent sur différents disques, parfois après des redémarrages ou des pics de charge.
• Cause racine : firmware/driver HBA, expander SAS/backplane défectueux, câble marginal, instabilité d’alimentation.
• Correction : Corrélez les événements par horodatage avec les journaux kernel ; cherchez des réinitialisations/délais sur le même bus. Stabilisez le transport d’abord, puis remplacez les disques qui montrent encore des erreurs média persistantes.

3) « Le scrub est lent, c’est normal » → périphérique malade caché → resilver interminable

• Symptôme : scrubs/resilvers tournent à une fraction de la vitesse attendue ; parfois « pas d’ETA ».
• Cause racine : un disque relance des lectures, disques SMR sous I/O aléatoire soutenu, ou un système saturé par une charge concurrente.
• Correction : Surveillez zpool events -f pendant le scrub pour erreurs I/O ; vérifiez les logs OS pour retries/délais ; envisagez de déplacer les charges lourdes pendant le resilver et de remplacer le périphérique lent/qui échoue.

4) « Pas d’alertes, donc pas de problème » → ZED non actif → dégradation silencieuse

• Symptôme : quelqu’un découvre les problèmes manuellement ; aucun ticket/page n’a été créé.
• Cause racine : ZED désactivé, e‑mails/handlers mal configurés, ou monitoring qui ne vérifie zpool status qu’une fois par jour.
• Correction : Activez et validez ZED ; testez un événement contrôlé (début/fin de scrub) et vérifiez que les alertes arrivent où des humains les verront.

5) « Remplacer le disque immédiatement » → stress du rebuild déclenche des fautes de transport latentes → pannes en cascade

• Symptôme : dès que le resilver démarre, d’autres disques commencent à tomber en erreur, ou le même disque « échoue plus fort ».
• Cause racine : la reconstruction augmente l’I/O et révèle un HBA/backplane/câblage instable.
• Correction : Avant le remplacement, cherchez des motifs multi-disques dans zpool events. Si l’instabilité du transport est suspectée, stabilisez d’abord, puis reconstruisez.

6) « Erreurs permanentes détectées » → suppression panique → rendre la récupération plus difficile

• Symptôme : errors: Permanent errors have been detected... liste des fichiers.
• Cause racine : ZFS n’a pas pu reconstruire certains blocs depuis la redondance. Supprimer le fichier peut détruire la valeur médico-légale ou compliquer la récupération au niveau applicatif.
• Correction : Prenez un snapshot de l’état actuel (si possible), identifiez les objets impactés, restaurez depuis sauvegarde/snapshot si approprié, et conservez les événements/logs pour l’analyse de cause racine.

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

Checklist A: Mettre en place une surveillance « je ne serai pas surpris » pour les événements zpool

1. Activez ZED et confirmez qu’il tourne : systemctl status zfs-zed.service.
2. Vérifiez au moins un chemin de livraison : ingestion syslog, e‑mail, ou hook ticket via zedlets.
3. Alertez sur ces classes d’événements (limitée en débit) : suppression de périphérique, ereports I/O, ereports checksum, scrub finish avec erreurs, resilver finish avec erreurs.
4. Incluez le chemin vdev by-id dans les alertes. N’alertez pas avec /dev/sdX seul.
5. Conservez un court historique roulant de la sortie zpool events -v dans votre système d’incident pendant les pages (copier/coller suffit ; la perfection est surévaluée quand vous perdez un disque).

Checklist B: Quand un pool passe en DEGRADED

1. Exécutez zpool status et enregistrez la sortie complète dans le ticket.
2. Exécutez zpool events -v | tail -n 200 et enregistrez-la.
3. Identifiez si le problème est mono‑périphérique ou multi‑périphérique.
4. Corrélez avec les logs kernel pour réinitialisations/délais autour du premier horodatage problématique.
5. Si erreurs média sur un seul périphérique : offline/remplacez ; surveillez les événements de resilver en direct.
6. Si motif de transport : mettez en pause les opérations risquées ; inspectez câbles/HBA/backplane/alimentation ; puis procédez aux remplacements.
7. Après le resilver, lancez un scrub et vérifiez que scrub_finish a scrub_errors: 0.

Checklist C: Après un correctif sans erreur (la partie que les gens zappent)

1. Confirmez que le pool est ONLINE et que zpool status -x est propre.
2. Revoyez les événements depuis le début de l’incident ; assurez-vous qu’il n’y a pas d’ereports I/O ou checksum récurrents.
3. Apportez un changement durable : figer un firmware, enregistrement de remplacement de câble, ajustement du calendrier de scrub, ou correction du routage d’alerte.
4. Documentez l’« horodatage du premier problème » et l’« horodatage du dernier problème ». C’est important pour la portée.

Checklist D: Recherche rapide de goulot quand resilver/scrub est lent

1. Vérifiez s’il y a des erreurs pendant l’opération : zpool events -f pendant 5–10 minutes.
2. Vérifiez les logs OS pour retries/délais de lecture dans la même fenêtre.
3. Vérifiez si un périphérique limite le vdev (latence élevée) : si un disque est malade, le remplacer est plus rapide que « attendre ».
4. Réduisez temporairement la charge concurrente. La reconstruction est un test de stress ; n’y lancez pas de benchmarks.

FAQ

1) Quelle est la différence entre zpool events et zpool status ?

zpool status est un instantané courant plus un court résumé de l’activité récente. zpool events est la chronologie : ce qui s’est passé, quand, et souvent quel chemin de périphérique et quelle classe d’erreur.
En cas d’incident, la chronologie bat l’impression.

2) Si je vois des erreurs de checksum, dois‑je toujours remplacer le disque ?

Non. Si les erreurs de checksum sont isolées à un seul disque et persistent, le remplacement est généralement approprié. Si elles apparaissent sur plusieurs disques, suspectez d’abord le transport (HBA/backplane/câblage) ou le firmware.
Événements plus logs kernel décident de ce que vous avez devant vous.

3) Pourquoi ZFS signale‑t‑il des erreurs quand l’application semble aller bien ?

Parce que ZFS vérifie l’intégrité des données de façon agressive et peut souvent réparer des lectures corrompues grâce à la redondance sans l’exposer aux applications.
C’est tout l’intérêt. Traitez les erreurs réparées comme un signe d’alerte, pas comme une parade festive.

4) Les événements ereport.fs.zfs.* sont‑ils « sérieux » ?

Ce sont des rapports de faute structurés. Certains sont informatifs ; beaucoup indiquent de vrais problèmes d’I/O. Ce qui compte, c’est la fréquence, s’ils se répètent sur le même vdev, et s’ils coïncident avec des scrubs/resilvers ou des changements d’état.

5) Puis‑je effacer les événements ou réinitialiser l’historique des événements ?

La rétention des événements dépend de la plateforme/outillage. Ne comptez pas pouvoir les « effacer » comme un tableau de compteurs.
Opérationnellement, conservez la sortie pertinente dans votre dossier d’incident et concentrez‑vous sur l’arrêt des nouveaux événements.

6) Comment savoir si c’est un câble/backplane plutôt qu’un disque ?

Cherchez des motifs : plusieurs disques sur le même bus HBA affichant des délais/réinitialisations au même moment ; périphériques qui disparaissent et réapparaissent ; erreurs qui montent sous charge (resilver/scrub) et disparaissent ensuite.
Les logs de type « Medium Error » sur un seul disque pointent plus fortement vers une défaillance média.

7) Pourquoi les performances se sont‑elles effondrées quand un disque a échoué, même si le pool est resté en ligne ?

La redondance dégradée change le comportement de lecture/écriture et augmente le travail (reconstruction de parité, retries, scrubbing/resilvering supplémentaires).
De plus, un disque défaillant peut être « online » tout en répondant très lentement, ralentissant tout le vdev.

8) Dois‑je lancer des scrubs chaque semaine ou chaque mois ?

Cela dépend de la capacité, de la charge et de la tolérance au risque. Les gros pools bénéficient d’une vérification plus fréquente car les erreurs latentes s’accumulent.
L’intransigeable est la cohérence : choisissez un intervalle que vous pouvez maintenir, et alertez sur scrub finish avec erreurs.

9) Comment utiliser les événements pour éviter les faux positifs dans les alertes ?

Limitez le débit et corrélez. Alertez sur la première occurrence, puis supprimez les répétitions pendant une fenêtre sauf si l’état du pool change ou que les erreurs augmentent.
N’alertez pas uniquement sur les changements d’état ; c’est comme cela qu’on manque des semaines de flapping.

10) Les événements aident‑ils pour les plaintes « ZFS est lent » ?

Oui, indirectement. Les événements peuvent indiquer que le système refait des retries d’I/O, subit des suppressions de périphériques, ou exécute des scrubs/resilvers—exactement le type de stress en arrière-plan qui rend la latence désagréable.
Pour l’optimisation pure des performances, il vous faudra toujours des stats I/O, mais les événements révèlent souvent le « pourquoi maintenant ».

Conclusion : prochaines étapes qui réduisent réellement le risque

zpool events n’est pas une commande de curiosité. C’est le récit que votre pile de stockage écrit pendant que vous regardez des tableaux de bord qui moyennent la vérité.
Lisez‑le, automatisez‑le, et utilisez‑le pour décider si vous avez affaire à un disque mourant ou à un transport menteur.

Faites ceci ensuite, dans cet ordre :

1. Assurez‑vous que ZED tourne et est connecté à des humains (tickets/pages), pas seulement au syslog.
2. Ajoutez une étape au runbook : chaque fois que zpool status montre un problème, capturez zpool events -v et les logs kernel autour du premier horodatage problématique.
3. Alertez sur les classes d’événements qui indiquent un risque (I/O, suppressions, erreurs scrub/resilver), avec limitation de débit plutôt que silence.
4. Programmez des scrubs et traitez les « erreurs réparées » comme un signal actionnable, pas comme un simple FYI.
5. Pendant un remplacement de disque, surveillez les événements en direct. Si les erreurs se propagent, arrêtez d’échanger des pièces et corrigez le transport.

Le stockage ne tombe pas en panne poliment. Il échoue de manières qui ressemblent à des problèmes réseau, base de données, ou « le cloud est lent aujourd’hui ».
ZFS vous donne une chronologie. Servez‑vous en avant qu’il n’ait à vous sauver.