Le TDP n’est ni un thermomètre, ni un wattmètre

Le TDP (Thermal Design Power) ressemble à une mesure. Il a l’air d’une mesure. Les gens le citent comme une mesure. Sur les portables, ce n’est souvent pas une mesure de la puissance que vous verrez à la prise, à la batterie, ni même au niveau du package CPU sous votre charge de travail.

En pratique, le « TDP » d’un portable est généralement une étiquette pour l’enveloppe thermique prévue du processeur dans certaines conditions définies qui peuvent ne pas correspondre à vos conditions, au refroidissement de votre portable ou aux choix du firmware du fabricant. Le CPU dispose d’un modèle interne de puissance et de température, le firmware fixe des limites et l’OS demande de la performance. La seule chose que garantit « TDP », c’est qu’une réunion a eu lieu à ce sujet.

Ce que le TDP est censé représenter

Historiquement, le TDP était utilisé par les concepteurs système pour dimensionner le refroidissement : dissipateurs, ventilateurs, ouvertures et flux d’air du châssis. L’objectif n’était pas la « puissance max », mais la « chaleur à évacuer lors d’une charge soutenue qui intéresse le fabricant ». Cette différence subtile compte : charge soutenue, définie, règles définies par le fabricant.

Ce que les acheteurs de portables pensent que cela représente

• Une promesse de performance soutenue.
• Une promesse de puissance maximale absorbée.
• Un indicateur de « ce CPU est plus rapide que cet autre CPU ».
• Une garantie que deux portables avec le même CPU auront des performances similaires.

Un seul de ces points est occasionnellement vrai, et encore, seulement par accident.

Ce que devient souvent le TDP dans les portables

Il devient un argument marketing pour segmenter une famille de CPU : « la série U est efficace », « la série H est rapide », « HX est proche du desktop ». Ensuite, les OEM fixent leurs propres limites soutenues et de pic pour s’adapter au châssis, à la batterie, aux objectifs de nuisance sonore et au positionnement produit. La puce peut être capable de pics à 60–90W, mais le portable peut n’autoriser cela que pendant 10 secondes, 28 secondes, ou « jusqu’à ce que l’utilisateur ouvre Slack ».

Blague n°1 : Le TDP des portables est comme une prévision météo : techniquement dérivé de modèles, mais pas quelque chose sur lequel vous devriez parier votre trajet quotidien.

Comment on en est arrivé là : la lente dérive du TDP vers le marketing

Les CPU mobiles n’ont pas commencé à tromper du jour au lendemain. L’industrie a évolué vers des processeurs qui peuvent dépasser régulièrement leur « enveloppe de base », et vers des OEM qui optimisent agressivement la finesse et l’autonomie. Le problème est que la fiche technique n’a pas évolué en quelque chose d’utile pour les consommateurs.

Faits intéressants et contexte historique (court et concret)

1. Le Turbo boost a rendu la « puissance de base » politiquement gênante. Dès que les CPU ont commencé à monter la fréquence de façon opportuniste, la « puissance typique » a cessé d’être stable.
2. Le modèle de limites de puissance d’Intel (PL1/PL2/Tau) a normalisé les pics. La puissance soutenue et la puissance court terme sont devenues des réglages distincts, pas un seul nombre.
3. Les pièces mobiles ont poussé l’intégration. GPUs intégrés et contrôleurs mémoire signifient que la puissance du package CPU n’est pas « seulement des cœurs », donc le mix de charges varie fortement.
4. Le design fin et léger est devenu un argument majeur. Beaucoup de portables sont conçus d’abord pour le bruit et l’épaisseur, puis les limites de puissance sont définies après coup.
5. La segmentation produit par les OEM est réelle. Deux modèles avec le même CPU peuvent être intentionnellement réglés pour des puissances soutenues différentes afin de préserver une grille tarifaire.
6. Batterie et contraintes VRM comptent. Un portable peut ne pas pouvoir fournir beaucoup de puissance depuis la batterie sans chute de tension, chaleur ou problèmes d’usure à long terme.
7. La température de surface et le confort utilisateur sont des contraintes. « Ne brûlez pas l’utilisateur » est une limite de conception ; elle prime souvent sur « atteindre le score du benchmark ».
8. Les bascules Windows « Meilleure performance » ont changé les attentes des utilisateurs. Les profils d’énergie de l’OS peuvent modifier le comportement PL1/PL2 sans l’expliquer clairement.
9. Les limites au niveau plateforme (adaptateur AC, USB-C PD) sont devenues des goulots courants. Un adaptateur USB-C de 65W peut plafonner un CPU « 45W » une fois que le reste du système prend sa part.

Voici la partie inconfortable : le fournisseur de CPU peut publier un nombre, mais votre portable est un traité négocié entre firmware, thermiques et une volonté commerciale de ne pas cannibaliser le modèle « Pro ».

Les vrais réglages : PL1, PL2, Tau, cTDP, et alliés

Si vous voulez la réalité, ignorez le TDP et apprenez la couche de contrôle. Les noms diffèrent selon les fournisseurs, mais la structure est similaire : une limite de puissance soutenue, une limite de boost court terme, et des contraintes thermiques qui annulent tout quand le refroidissement est saturé.

PL1 : le budget de puissance soutenue

PL1 est souvent la puissance « long terme ». Le portable peut tourner à ce niveau indéfiniment si le refroidissement le permet. Les OEM définissent fréquemment PL1 en dessous de la « classe TDP » annoncée du CPU, car ils conçoivent pour l’acoustique, l’autonomie ou la température de surface du châssis.

Dans le monde réel : PL1 est le nombre qui gouverne votre compilation de 10 minutes, votre rendu long, votre simulation soutenue et vos plaintes du type « pourquoi l’ordinateur est-il plus lent après la première minute ? »

PL2 : le budget de boost court terme

PL2 est la limite de « rafale ». C’est ce qui rend les portables réactifs à l’ouverture d’apps, à l’export d’un petit fichier ou à un benchmark court. PL2 est aussi la raison pour laquelle les reviewers obtiennent de jolis graphiques avec des runs courts.

PL2 peut être 2–3× PL1 sur certains designs. Ce n’est pas de la triche. C’est le but. Le mensonge survient quand le marketing laisse entendre que le comportement en rafale est le comportement soutenu.

Tau : la fenêtre temporelle (la partie que tout le monde oublie)

Tau est en pratique « combien de temps pouvons-nous faire semblant d’être sur un desktop ? » Il définit combien de temps PL2 peut être utilisé avant de retomber vers PL1. Certains portables sont livrés avec un Tau long pour être compétitifs sur les benchmarks. D’autres le gardent court pour éviter l’accumulation de chaleur et les pics de bruit.

cTDP / plages de puissance configurables

Beaucoup de CPU mobiles supportent des plages configurables : 12–15W, 15–28W, 35–45W, etc. Cette plage ne signifie pas que vous obtenez « un CPU à 28W ». Cela signifie que le CPU peut fonctionner dans différentes enveloppes selon le réglage OEM.

Si vous voyez le même CPU dans différents portables avec des performances très différentes, c’est la raison dans neuf cas sur dix.

Throttling thermique vs limitation de puissance

Les gens attribuent « le throttling thermique » à tout, mais la limitation de puissance est souvent le premier frein. Le CPU peut ne jamais atteindre sa température maximale ; il peut simplement être maintenu sur un PL1 bas parce que l’OEM veut une courbe de ventilateur silencieuse.

Cette distinction compte, car la correction diffère :

• Limitée en puissance : changez la politique de puissance (si possible), les réglages firmware, ou acceptez le choix produit.
• Limitée thermiquement : améliorez le refroidissement (nettoyage, changement de pâte thermique, alignement des pads, courbe de ventilateur), réduisez l’ambiance ou réduisez la charge.

Vue d’un responsable fiabilité sur la gestion de la puissance

Dans les systèmes de production, on suppose qu’il y a une boucle de contrôle. Dans les portables, vous en avez plusieurs : DVFS CPU, logique ventilateur du contrôleur embarqué, plans d’énergie OS, et parfois des démons constructeurs qui se battent entre eux. Vous ne « fixez » pas un TDP. Vous gérez un système de contraintes.

Une citation opérationnelle s’impose. Voici une idée paraphrasée de Werner Vogels (CTO d’Amazon) : paraphrased idea: Everything fails, and you should design and operate as if failure is normal.

Les limites de puissance ne sont pas une défaillance, mais il faut les traiter comme un mode normal à observer et planifier.

L’ordinateur portable est le produit (le CPU n’est qu’un passager)

Deux portables peuvent partager le même modèle de CPU et pourtant se comporter comme des espèces différentes. Parce que le CPU n’est pas le système. Le système, c’est : capacité de refroidissement, masse du dissipateur, qualité de la chambre à vapeur, design des ventilateurs, géométrie d’entrée/sortie d’air, réglages firmware, conception VRM, wattage de l’adaptateur, et si l’OEM a discrètement plafonné les performances sur batterie.

Refroidissement : l’état stable prime sur les pics

La performance du refroidissement concerne l’évacuation de chaleur en régime permanent. Un portable fin peut absorber un pic (masse thermique), mais ne peut pas le soutenir sans flux d’air et surface de ailettes. Quand les reviewers lancent une boucle de benchmark courte, la première passe est la lune de miel. La dixième passe, c’est le mariage.

Alimentation et limites de l’adaptateur

Un « CPU 45W » dans un système avec un adaptateur USB-C PD 65W est déjà en négociation avec le GPU, l’écran, le SSD et la charge. Sous charge, le système peut :

• réduire la puissance CPU pour continuer la charge,
• arrêter la charge et maintenir la performance, ou
• vidanger la batterie tout en étant branché (oui, vraiment).

Le mode batterie est un univers à part

Beaucoup de portables plafonnent fortement la puissance CPU sur batterie pour préserver la durée de vie des cycles et éviter les chutes de tension. Si vous faites un vrai travail sur batterie, vous devez mesurer les performances sur batterie. Sinon vous évaluez une machine différente de celle que vous utilisez.

Logiciels constructeur et « modes IA de puissance »

Les utilitaires constructeurs peuvent outrepasser les politiques OS, brider PL1 quand le « mode silencieux » est activé, ou même changer les limites selon l’application active. Parfois ils fonctionnent bien. Parfois ils le font pour atteindre une certification acoustique. Dans tous les cas, vous devez savoir qui est aux commandes.

Blague n°2 : La courbe des ventilateurs du portable a été conçue par quelqu’un qui pense que « silencieux » signifie « laisser souffrir le CPU en silence ».

Modes de défaillance que vous pouvez réellement diagnostiquer

Quand un portable sous-performe, vous voulez une courte liste de causes plausibles. Voici l’ensemble que j’utilise, car il se mappe proprement à des mesures.

1) Pic court, puis effondrement

Schéma : rapide pendant 10–60 secondes, puis les fréquences chutent et ne se rétablissent pas.

Cause probable : PL2 autorisé, mais PL1 est bas, ou le refroidissement est saturé et impose un état soutenu bas.

Décision : si vous avez besoin de performance soutenue, choisissez un châssis plus épais ou un modèle connu pour une puissance soutenue plus élevée, pas une classe TDP annoncée supérieure.

2) Toujours lent, même au démarrage

Schéma : ne monte jamais beaucoup en fréquence.

Cause probable : OS en économiseur d’énergie, « mode silencieux » constructeur, plafonnement sur batterie, adaptateur de faible puissance, ou capteur thermique / ventilateur bloqué.

Décision : validez d’abord la source d’alimentation et le plan d’énergie ; ne chassez les problèmes thermiques qu’après.

3) Performance très variable d’un jour à l’autre

Schéma : parfois excellent, parfois terrible, sans changement de charge.

Cause probable : logiciels en arrière-plan, tâches de mise à jour Windows, service d’alimentation constructeur basculant les modes, accumulation de poussière, température ambiante ou installation de dock/charge instable.

Décision : établissez une mesure reproductible : même source d’alimentation, même mode, même charge, même ambiance.

4) Branché mais toujours fortement limité

Schéma : « mode AC » mais puissance limitée comme sur batterie.

Cause probable : adaptateur non reconnu, négociation USB-C PD à une puissance inférieure, câble endommagé, ou bug firmware forçant la politique batterie.

Décision : confirmez la puissance négociée et si la batterie se charge sous charge.

5) Le CPU n’est pas le goulot

Schéma : les fréquences sont correctes, mais les tâches restent lentes.

Cause probable : pression mémoire, limites I/O stockage, chiffrement de disque en arrière-plan, ou throttling thermique du SSD.

Décision : prouvez la saturation CPU avant de blâmer le « mensonge du TDP ».

Guide de diagnostic rapide

Quand quelqu’un dit « ce portable est lent », ne commencez pas par repaster. Ne commencez pas par acheter un pad de refroidissement. Ne lancez pas une suite de benchmarks d’une heure. Vous voulez un triage de 10 minutes qui isole le limiteur dominant.

Première étape : confirmer la source d’alimentation et la politique

• La machine est-elle sur batterie, sur secteur ou sur une station d’accueil ?
• Se recharge-t-elle réellement sous charge ?
• L’OS est-il dans un plan d’énergie restrictif ?
• Un logiciel constructeur force-t-il le « silence » ou l’« éco » ?

Deuxième étape : observer les limites pendant une charge soutenue

• Surveillez la puissance du package CPU dans le temps (pas seulement le pic).
• Surveillez fréquence et température ensemble.
• Cherchez des indicateurs de « limite de puissance » vs « throttling thermique ».

Troisième étape : vérifiez le reste du système pour le vrai goulot

• Pression mémoire et activité de swap.
• Débit et latence stockage sous charge.
• Utilisation GPU si la charge décharge sur le GPU.
• Tâches d’arrière-plan qui volent du temps CPU.

Quatrième étape : décider si c’est une réparation ou un mauvais produit

Si le portable se comporte exactement comme conçu (PL1 bas pour le silence), vous pouvez parfois ajuster des paramètres. Mais souvent la « réparation » consiste à choisir un portable conçu pour la puissance soutenue. C’est brutal, mais moins cher que des semaines de frustration.

Tâches pratiques : commandes, sorties et décisions

Voici des vérifications réelles et exécutables. J’utilise des exemples Linux parce qu’ils sont observables et scriptables. La méthode importe plus que l’OS.

Task 1: Identify CPU model and base characteristics

cr0x@server:~$ lscpu | sed -n '1,25p'
Architecture:                         x86_64
CPU op-mode(s):                       32-bit, 64-bit
Model name:                           13th Gen Intel(R) Core(TM) i7-13700H
CPU(s):                               20
Thread(s) per core:                   2
Core(s) per socket:                   14
CPU max MHz:                          5000.0000
CPU min MHz:                          400.0000

Ce que cela signifie : Confirme le CPU et la fréquence max annoncée. Cela ne vous dit rien sur la performance soutenue, mais fixe les attentes pour le comportement en boost.

Décision : Si c’est une puce « U » dans un châssis fin et que vous attendez un comportement d’atelier de travail, stoppez et réajustez vos attentes avant de poursuivre.

Task 2: Confirm which driver and governor is active (Linux)

cr0x@server:~$ cpupower frequency-info | sed -n '1,40p'
analyzing CPU 0:
  driver: intel_pstate
  CPUs which run at the same hardware frequency: 0
  hardware limits: 400 MHz - 5.00 GHz
  available cpufreq governors: performance powersave
  current policy: frequency should be within 400 MHz and 5.00 GHz.
                  The governor "powersave" may decide which speed to use

Ce que cela signifie : Avec intel_pstate, « powersave » est souvent le mode par défaut et permet tout de même le turbo, mais il peut être influencé par EPP/energy bias.

Décision : Si vous diagnostiquez la performance, forcez temporairement « performance » pour ôter une variable.

Task 3: Temporarily switch to performance governor (diagnostic)

cr0x@server:~$ sudo cpupower frequency-set -g performance
Setting cpu: 0
Setting cpu: 1
Setting cpu: 2
Setting cpu: 3

Ce que cela signifie : Vous demandez à l’OS de favoriser la performance. Cela n’outrepasse pas PL1/PL2 du firmware, mais cela montre ce que la plateforme peut faire.

Décision : Si la performance s’améliore beaucoup, le problème est de politique, pas de refroidissement. Ensuite, décidez si vous pouvez tolérer l’impact sur batterie/bruit.

Task 4: Watch frequency and temperature in real time

cr0x@server:~$ sudo turbostat --quiet --interval 2
     CPU     Avg_MHz   Busy%   Bzy_MHz  TSC_MHz  CoreTmp  PkgTmp  PkgWatt
       -       3120    92.15     3385     1896     86.0    90.0    44.72
       -       2650    99.02     2675     1896     92.0    96.0    28.11
       -       2580    99.11     2600     1896     94.0    97.0    24.95

Ce que cela signifie : Vous voyez le schéma classique : forte puissance du package initialement, puis chute (souvent vers PL1), tandis que la température approche du plafond.

Décision : Si PkgWatt chute alors que les temp. sont élevées, vous êtes soit limité thermiquement, soit le firmware impose une puissance soutenue plus basse pour éviter l’accumulation de chaleur.

Task 5: Run a sustained CPU load to expose PL1 behavior

cr0x@server:~$ stress-ng --cpu 0 --timeout 180s --metrics-brief
stress-ng: info:  [23110] dispatching hogs: 20 cpu
stress-ng: metrc: [23110] stressor       bogo ops real time  usr time  sys time   bogo ops/s
stress-ng: metrc: [23110] cpu            3154210    180.00   1790.22    12.11     17523.39

Ce que cela signifie : Une charge soutenue de 3 minutes suffit souvent à faire sortir beaucoup de portables du PL2 et à atteindre les limites d’état stable.

Décision : Associez cela à turbostat. Si vous observez une baisse après 28–60 secondes, voilà votre réalité soutenue.

Task 6: Check Intel RAPL energy counters (power telemetry)

cr0x@server:~$ sudo powercap-info -p intel-rapl
Zone 0
  Name: package-0
  Enabled: yes
  Energy: 879.23 J
  Max energy range: 262143.99 J
Zone 0 subzone 0
  Name: core
  Energy: 522.17 J
Zone 0 subzone 1
  Name: uncore
  Energy: 101.55 J
Zone 0 subzone 2
  Name: dram
  Energy: 87.49 J

Ce que cela signifie : Les compteurs RAPL vous permettent d’estimer la puissance moyenne sur un intervalle en échantillonnant l’énergie avant / après.

Décision : Si l’énergie du package augmente lentement pendant une charge soutenue, votre plateforme applique un plafond de puissance bas indépendamment du « TDP ».

Task 7: Look for thermal and power limit messages in the kernel log

cr0x@server:~$ sudo dmesg | egrep -i 'thrott|thermal|pstate|rapl|power limit' | tail -n 15
intel_rapl_common: Found RAPL domain package
thermal thermal_zone7: critical temperature reached (105 C), shutting down
intel_pstate: turbo disabled by BIOS or unavailable on processor

Ce que cela signifie : Cela révèle des événements matériels : turbo désactivé, événements thermiques critiques ou problèmes de configuration plateforme.

Décision : Si vous voyez « turbo disabled by BIOS », arrêtez de modifier l’OS. Votre limiteur est une politique firmware.

Task 8: Inspect current thermal zones and temperatures

cr0x@server:~$ for z in /sys/class/thermal/thermal_zone*/type; do echo -n "$(basename $(dirname $z)) "; cat $z; done | head
thermal_zone0 x86_pkg_temp
thermal_zone1 acpitz
thermal_zone2 INT3400 Thermal

cr0x@server:~$ cat /sys/class/thermal/thermal_zone0/temp
94000

Ce que cela signifie : Les températures sont souvent en millidegrés Celsius. 94000 signifie 94°C.

Décision : Si la temp. du package est proche du point de throttling sous charge modérée, vous avez probablement un problème de refroidissement (poussière, ventilateur défaillant, pâte dégradée) ou une courbe de ventilateur extrêmement conservative.

Task 9: Check whether you’re swapping (memory pressure masquerading as CPU slowness)

cr0x@server:~$ free -h
               total        used        free      shared  buff/cache   available
Mem:            32Gi        29Gi       1.1Gi       1.2Gi       2.3Gi       1.9Gi
Swap:            8Gi       6.5Gi       1.5Gi

Ce que cela signifie : Une utilisation intensive du swap peut rendre les « tâches CPU » lentes car tout dépend du stockage.

Décision : Si le swap est actif pendant des builds, des VMs ou des charges de conteneurs, votre « problème de TDP » peut en fait être « pas assez de RAM ».

Task 10: Confirm storage isn’t the bottleneck (NVMe)

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (laptop) 	01/12/2026 	_x86_64_	(20 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          35.12    0.00    6.21   22.18    0.00   36.49

Device            r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz     w/s     wkB/s   w_await wareq-sz  aqu-sz  %util
nvme0n1          92.0   8120.0     0.0    0.00   12.10    88.26    41.0   6240.0    18.33   152.20    1.22  96.00

Ce que cela signifie : Un %iowait élevé et un %util proche de saturation signifient que le disque est occupé ; le CPU peut attendre.

Décision : Si l’I/O est le goulot, augmenter les limites CPU n’aidera pas. Réparez le stockage (SSD plus rapide, éviter le throttling thermique, réduire l’amplification d’écriture) ou réduisez la charge I/O.

Task 11: Check NVMe drive temperature (SSD throttling can look like CPU throttling)

cr0x@server:~$ sudo nvme smart-log /dev/nvme0 | egrep -i 'temperature|warning'
temperature                             : 72 C
warning_temp_time                       : 3
critical_temp_time                      : 0

Ce que cela signifie : Un SSD à 72°C avec un temps d’avertissement suggère qu’il peut s’accélérer en throttling, surtout dans les portables fins avec un mauvais flux d’air sur le SSD.

Décision : Si le temps d’avertissement augmente pendant les builds, ajoutez un pad / dissipateur thermique ou réduisez les écritures soutenues (par exemple, déplacez le répertoire de build vers tmpfs si la RAM le permet).

Task 12: Check for cgroup CPU throttling (containers make everything confusing)

cr0x@server:~$ cat /sys/fs/cgroup/user.slice/user-1000.slice/cpu.stat 2>/dev/null | head
usage_usec 928381223
user_usec  812332110
system_usec 116049113
nr_periods  22990
nr_throttled 1420
throttled_usec 91822111

Ce que cela signifie : Si nr_throttled est élevé, l’ordonnanceur bride l’usage CPU à cause des quotas cgroup, pas parce que le CPU est limité en puissance.

Décision : Corrigez les limites de conteneurs (Docker/Kubernetes CPU quota) avant de blâmer les thermiques du portable.

Task 13: Check AC adapter / battery state (on Linux via upower)

cr0x@server:~$ upower -i /org/freedesktop/UPower/devices/battery_BAT0 | egrep -i 'state|percentage|energy-rate|time to'
  state:               charging
  percentage:          83%
  energy-rate:         28.1 W
  time to full:        0.9 hours

Ce que cela signifie : Un état de charge positif et un taux d’énergie raisonnable indiquent que l’adaptateur fournit assez de puissance pour faire tourner le système et charger.

Décision : Si l’état passe à « discharging » sous charge alors que l’appareil est branché, votre adaptateur / dock est un limiteur. Augmentez le wattage de l’adaptateur ou évitez ce dock pour les charges lourdes.

Task 14: Verify CPU idle behavior (background load stealing your turbo budget)

cr0x@server:~$ top -b -n 1 | head -n 15
top - 12:18:02 up  2:41,  1 user,  load average: 6.21, 5.90, 4.40
Tasks: 412 total,   3 running, 409 sleeping,   0 stopped,   0 zombie
%Cpu(s): 26.2 us,  6.3 sy,  0.0 ni, 63.1 id,  4.1 wa,  0.0 hi,  0.3 si,  0.0 st
MiB Mem :  31890.8 total,   1220.4 free,  29401.1 used,   1269.3 buff/cache
MiB Swap:   8192.0 total,   1581.2 free,   6610.8 used.   1820.2 avail Mem

  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
 4121 cr0x      20   0 5429812 617148  82192 R  182.3   1.9   5:21.83 chrome
 8892 cr0x      20   0 2916420 501120  61444 S   78.1   1.5   2:11.20 docker

Ce que cela signifie : CPU et pression mémoire en arrière-plan peuvent empêcher les états de repos profonds et réduire la marge pour le turbo, surtout sur des systèmes thermiquement contraints.

Décision : Si « idle » n’est pas idle, éliminez les coupables en arrière-plan avant de blâmer l’enveloppe CPU.

Trois mini-histoires d’entreprise des tranchées des limites de puissance

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

Une équipe a déployé une flotte de « portables développeur standard » pour un nouveau système de build interne exécutant compilations locales, tests unitaires et builds de conteneurs. La décision d’achat reposait sur un simple critère : CPU dernière génération, « classe 45W », 32Go RAM, bon clavier. Les machines semblaient identiques sur le papier. Le service achats était ravi. Les ingénieurs… moins.

En une semaine, les temps de build ont divergé. Certains développeurs terminaient un build complet dans un délai raisonnable ; d’autres mettaient presque le double. Les machines lentes n’étaient pas cassées. Elles n’étaient pas infectées. Elles n’étaient même pas particulièrement chaudes. Elles étaient simplement coincées à une limite de puissance soutenue plus basse parce que ces unités étaient une variante de châssis plus fine avec une cible acoustique plus silencieuse.

La mauvaise hypothèse était subtile : « même modèle de CPU = même performance ». Cette hypothèse fonctionnait sur desktop. Elle échouait sur portable, car l’enveloppe soutenue du CPU est essentiellement une décision OEM. L’étiquette « 45W » ne décrivait pas ce que les portables pouvaient soutenir ; elle décrivait ce que le CPU pouvait théoriquement être configuré pour atteindre.

La correction fut ennuyeuse et coûteuse : standardiser sur un modèle de portable spécifique, pas un SKU CPU, et le qualifier par un test de charge soutenue de 10 minutes lors de l’acceptation. Ils ont aussi mis à jour le formulaire interne de demande matériel pour inclure « puissance package soutenue en charge », car c’est plus difficile à maquiller que « TDP ».

Mini-histoire 2 : Une optimisation qui s’est retournée

Un ingénieur orienté performance a décidé de « réparer » des charges CI lentes sur les portables en forçant des modes performance maximum sur toute la flotte. Le changement a été poussé comme configuration : définir le governor CPU sur performance, désactiver les économies agressives et rendre les ventilateurs plus proactifs. Les benchmarks courts se sont améliorés immédiatement, et l’ingénieur a reçu quelques messages reconnaissants.

Puis le retour de bâton est arrivé. L’usure des batteries a augmenté sensiblement en quelques mois. Des machines qui tenaient autrefois toute une journée de réunions nécessitaient une recharge en milieu de journée. Certains portables ont commencé à chauffer même au repos, parce que les tâches en arrière-plan plus le biais de performance empêchaient le CPU d’entrer dans des états basse consommation efficaces. Sur un sous-ensemble d’unités, les roulements de ventilateurs ont commencé à faire des bruits désagréables plus tôt que prévu.

La surprise majeure fut l’expérience développeur : les portables devinrent bruyants dans les open-spaces, et les gens commencèrent à activer les « modes silencieux » des constructeurs pour s’adapter. Cela réintroduisit discrètement des PL1 bas et des performances incohérentes. L’optimisation créa un système à deux vitesses : ceux qui toléraient le bruit obtenaient la vitesse, et les autres avaient de l’imprévisibilité.

La leçon : forcer le mode performance global traite un symptôme (vitesse court terme) et ignore la fonction objective du système (batterie, acoustique, thermiques, longévité). L’approche correcte était de fournir un profil « charge lourde » documenté que les ingénieurs pouvaient activer branchés, et de mesurer la performance soutenue plutôt que de poursuivre le turbo maximal.

Mini-histoire 3 : Une pratique ennuyeuse mais correcte qui sauva la situation

Une équipe plateforme maintenait une liste interne de « portables validés » pour les ingénieurs qui exécutent régulièrement des bases de données locales, VMs et compilations. La liste ne mentionnait jamais le TDP. Elle spécifiait modèles, versions BIOS, wattage adaptateur et un test d’acceptation simple : exécuter une charge CPU soutenue de 10 minutes et enregistrer la puissance package stabilisée, la fréquence et la température.

Quand un cycle de renouvellement est arrivé, le vendeur proposa un nouveau modèle séduisant : plus fin, plus léger, même génération de CPU et un badge « haute performance ». Il séduisit lors des démos courtes. L’équipe plateforme exécuta quand même le test d’acceptation, parce que c’est ce qu’elle faisait toujours.

Le nouveau modèle boostait fort, puis se stabilisait sur une puissance soutenue bien plus basse que l’ancien modèle. Ce n’était pas catastrophique ; ce n’était juste pas l’outil adapté aux ingénieurs qui vivent de compilations et de VMs. L’explication du vendeur fut prévisible : objectifs acoustiques, contraintes de châssis et courbe de ventilateur différente. Rien n’était « cassé ».

Parce que l’équipe avait institutionnalisé un test ennuyeux, elle détecta l’inadéquation avant d’émettre les bons de commande. Ils approuvèrent le modèle pour un usage bureau général, mais conservèrent la ligne plus épaisse (ou une alternative) pour les utilisateurs intensifs. Pas de drame. Pas de « pourquoi les builds sont lents » en réunion d’urgence. Juste une évitement tranquille de la douleur.

Erreurs courantes : symptôme → cause racine → solution

1) « Mon CPU est 45W mais il ne tire qu’environ 25W en charge »

Symptôme : la puissance package se stabilise bien en dessous de la classe annoncée.

Cause racine : l’OEM a fixé PL1 bas pour atteindre des objectifs de bruit/température de surface, ou la source d’alimentation (adaptateur/dock) ne fournit pas assez d’enveloppe.

Solution : validez sur l’adaptateur OEM ; vérifiez l’état de charge sous charge ; si PL1 est plafonné par le firmware, votre véritable solution est un autre modèle de portable ou un mode performance constructeur qui augmente PL1.

2) « Il est rapide pendant 30 secondes, puis lent pour toujours »

Symptôme : fréquences élevées initialement, puis palier stable bas.

Cause racine : le burst PL2 expire (fenêtre Tau), puis le CPU retombe vers PL1 ; parfois la chaleur forcée impose des limites encore plus basses.

Solution : mesurez la puissance soutenue après 3–10 minutes ; choisissez le matériel en fonction de ce palier, pas de la première passe d’un benchmark.

3) « Sur batterie, mon portable devient une autre machine »

Symptôme : chute importante de performance débranché.

Cause racine : limites de décharge batterie, firmware conservateur sur batterie ou changement de plan OS.

Solution : si vous avez besoin de performance sur batterie, achetez spécifiquement des systèmes connus pour autoriser plus de puissance sur batterie. Sinon, acceptez que le mode batterie soit pour l’efficacité et organisez votre travail en conséquence.

4) « Branché, mais toujours lent et pas en charge »

Symptôme : le pourcentage de batterie diminue lentement alors que l’appareil est connecté.

Cause racine : wattage de l’adaptateur trop faible, négociation USB-C PD à une puissance inférieure, ou dock incapable de fournir sous charge.

Solution : utilisez l’adaptateur OEM haute puissance ; remplacez le câble ; évitez les docks basse puissance pour les charges soutenues.

5) « La temp. CPU est correcte, mais les fréquences restent basses »

Symptôme : températures sous le seuil de throttling, pourtant fréquence/puissance basses.

Cause racine : enforcement de limite de puissance, EPP/energy bias, « mode silencieux » constructeur ou quota cgroup.

Solution : vérifiez la politique de puissance et le throttling cgroup ; vérifiez que le turbo n’est pas désactivé par le BIOS ; puis considérez les profils performance constructeur.

6) « J’ai repasté et ça n’a presque rien changé »

Symptôme : pics de température plus bas mais même performance soutenue.

Cause racine : la performance soutenue est limitée par la puissance, pas par la thermique ; PL1 OEM est le plafond.

Solution : arrêtez de considérer le refroidissement comme le seul levier. Mesurez le comportement PL1 ; s’il est plafonné, acceptez-le ou changez de matériel.

7) « Les benchmarks sont excellents, le travail réel est médiocre »

Symptôme : bons scores sur tests courts, lent sur compilations/rendus longs.

Cause racine : les benchmarks favorisent les rafales ; votre charge est soutenue et chauffe le châssis.

Solution : utilisez des benchmarks soutenus (runs en boucle, charges de 10 minutes) et suivez la puissance package stabilisée et les fréquences.

8) « La montée de gamme CPU n’a pas beaucoup aidé ma charge »

Symptôme : le nouveau CPU semble similaire.

Cause racine : la charge est limitée par l’I/O, la mémoire ou le GPU ; ou le nouveau portable a des limites soutenues plus basses malgré une silicon plus récente.

Solution : mesurez les goulots (iowait, swap, utilisation GPU). Si la puissance soutenue est plus basse, vous avez acheté une histoire plus fine, pas une machine plus rapide.

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

Checklist A : Acheter un portable pour du travail CPU soutenu

1. Choisissez par modèle, pas par CPU SKU. Le même CPU dans des châssis différents peut se comporter très différemment.
2. Exigez des chiffres soutenus. Recherchez des tests qui montrent des boucles de plusieurs minutes et la puissance stabilisée.
3. Privilégiez un refroidissement plus épais pour les charges longues. Chambre à vapeur, ventilateurs doubles, bonne évacuation. Le poids est une caractéristique de performance.
4. Vérifiez le wattage de l’adaptateur. Assurez-vous que l’alimentation peut couvrir CPU+GPU+charge. USB-C PD est pratique, pas magique.
5. Confirmez les attentes de performance sur batterie. Si vous en avez vraiment besoin, testez-le.
6. Surveillez les modes performance constructeur. Certains sont de vrais réglages ; d’autres ne sont que des habillages UI pour « rendre plus bruyant ».
7. Prévoyez le refroidissement du SSD. Les builds et VMs soutenus peuvent chauffer les NVMe jusqu’au throttling.
8. Ne misez pas tout sur des graphiques de benchmark en une seule exécution. Demandez : que se passe-t-il à la minute 8 ?

Checklist B : Diagnostiquer un portable existant qui « devrait être plus rapide »

1. Normalisez les variables : adaptateur OEM, branché, ambiance stable, lid ouvert, pas de couverture sur le lit.
2. Définissez une politique d’énergie connue (mode performance temporaire) et désactivez le « mode silencieux » constructeur.
3. Exécutez une charge CPU soutenue pendant 3–10 minutes.
4. Observez : puissance package, fréquence, température, comportement des ventilateurs.
5. Décidez : limité par la puissance vs limité thermiquement vs autre goulot (RAM/SSD/cgroups).
6. Si limité thermiquement : nettoyez les évents/ventilateurs, vérifiez la rotation des ventilateurs, inspectez pâte/pads, envisagez un pad de refroidissement en dépannage.
7. Si limité par la conception : évaluez les options firmware ; sinon arrêtez de perdre du temps et acceptez l’enveloppe produit.
8. Si « autre goulot » : corrigez la pression RAM, la saturation I/O ou les quotas de conteneurs.

Checklist C : Fixer les attentes pour les équipes (édition entreprise)

1. Standardisez sur des modèles spécifiques. Pas « n’importe quel i7 ». Un modèle, baseline BIOS, adaptateur de référence.
2. Définissez un test d’acceptation. Charge soutenue + observation de la puissance stabilisée.
3. Documentez les modes énergie. « Silencieux », « équilibré », « performance » et quand les utiliser.
4. Fournissez un niveau workstation. Certains ingénieurs ont besoin de performance soutenue ; prétendre que tout le monde n’en a pas est gaspiller la paie.
5. Instrumentez la douleur des développeurs. Suivez les temps de build et la pression des ressources ; traitez cela comme la latence en production.

FAQ

1) Le TDP est-il la puissance maximale absorbée ?

Non. Sur les CPU mobiles modernes, les rafales courtes peuvent dépasser la « classe TDP » de beaucoup. La puissance soutenue peut aussi être inférieure, selon les limites OEM.

2) Pourquoi deux portables avec le même CPU ont-ils des performances différentes ?

Parce que l’OEM fixe les limites soutenues et de rafale, les courbes de ventilateur et parfois des solutions thermiques différentes. Le modèle CPU n’est qu’une entrée parmi d’autres pour la performance.

3) Qu’est-ce qui compte plus que le TDP pour le travail soutenu ?

La puissance package et la fréquence stabilisées après plusieurs minutes de charge, ainsi que savoir si le système est limité par la puissance ou par la thermique dans cet état stable.

4) Si j’augmente les limites de puissance, aurai‑je toujours plus de performance ?

Seulement si vous avez une marge thermique et une alimentation suffisante. Sinon vous obtiendrez des températures plus élevées, des ventilateurs plus bruyants, puis un retour au même point par throttling.

5) Pourquoi mon portable throttle alors que la temp. CPU n’est pas au maximum ?

Parce que des limites de puissance peuvent plafonner la performance avant d’atteindre les limites thermiques. De plus, d’autres capteurs (VRM, température de surface) peuvent déclencher des throttles au niveau plateforme.

6) L’undervolting aide-t-il ?

Parfois. Réduire la tension peut faire baisser la puissance à une fréquence donnée, ce qui peut améliorer les fréquences soutenues dans la même enveloppe thermique/puissance. Sur beaucoup de plateformes modernes, l’undervolting peut être restreint par le firmware pour des raisons de sécurité/stabilité.

7) « 15W » vs « 28W » fait-il une grosse différence ?

Cela peut être énorme pour les charges soutenues, mais seulement si le portable autorise réellement ces limites soutenues. Certaines puces « capables de 28W » sont intégrées dans des portables qui tiennent bien moins en charge.

8) Quel est le test le plus simple pour voir la capacité CPU soutenue de mon portable ?

Exécutez un stress CPU de 3–10 minutes (ou votre charge réelle) tout en surveillant la puissance package et la fréquence dans le temps. Le plateau est votre réalité.

9) Pourquoi les reviewers et fiches techniques se focalisent-ils encore sur le TDP ?

Parce que c’est un nombre unique qui tient dans un tableau comparatif. Le comportement soutenu est une courbe, et les courbes sont gênantes pour le marketing et les filtres d’achat.

10) Dois-je acheter un portable gaming pour du travail CPU ?

Pas automatiquement, mais beaucoup de châssis gaming ont un meilleur refroidissement soutenu et des budgets de puissance plus élevés. Si vous valorisez la performance soutenue plutôt que la portabilité et le silence, c’est un choix rationnel.

Conclusion : prochaines étapes qui ne gaspillent pas votre argent

Arrêtez d’acheter des portables comme s’ils étaient des CPU desktop dans un autre boîtier. Le TDP n’est pas un contrat. Sur les portables, c’est plutôt une suggestion amendée par le firmware, le refroidissement et la stratégie produit.

Ce qu’il faut faire ensuite :

1. Mesurez votre réalité : exécutez une charge soutenue et observez la puissance package, la fréquence et la température jusqu’à stabilisation.
2. Classez le limiteur : politique de puissance, PL1 plafonné par l’OEM, saturation thermique, adaptateur/dock, ou goulots non-CPU comme RAM/SSD.
3. N’tweakez que ce qui vaut la peine : corrigez les charges en arrière-plan, confirmez le wattage adaptateur, nettoyez les voies de refroidissement. Ne repastez pas un portable juste parce qu’il est plafonné par le firmware.
4. À l’achat : choisissez des modèles prouvés pour soutenir la puissance dont vous avez besoin, et traitez la « classe TDP » comme une étiquette de famille, pas une garantie de performance.

Le CPU peut être excellent. Le portable peut toujours mentir. Votre travail consiste à le faire avouer avec des mesures.

La vérité inconfortable : « le meilleur » gagne rarement

Les ingénieurs aiment les designs propres. Les marchés aiment le volume d’expédition. Ce ne sont pas les mêmes priorités.

FireWire a été conçu comme un vrai bus : les appareils pouvaient communiquer entre eux sans que l’hôte microgère chaque octet. Il avait un bon support pour les transferts isochrones (pensez aux flux audio/vidéo qui nécessitent un timing prévisible) et n’interrompait pas constamment le CPU pour demander la permission à chaque opération. L’USB, surtout au début, était conçu comme une file polie à l’administration : tout le monde attend, l’hôte appelle votre numéro, vous remettez vos papiers, et vous vous rasseyez.

Et pourtant : l’USB a gagné parce qu’il était plus simple à implémenter, bénéficiait d’un plus large soutien des consortiums, avait moins de frictions de licence et de coût dans la chaîne d’approvisionnement, et s’est intégré partout. En termes d’exploitation : il avait une meilleure « disponibilité » au niveau de l’écosystème. L’interface la plus rapide sur le papier est inutile quand vous ne trouvez pas de câble dans une salle de réunion ou de contrôleur sur une carte mère.

Idée directrice pour la suite : FireWire a perdu non pas parce qu’il était mauvais, mais parce que « assez bien + partout » est une superpuissance.

Ce qu’était réellement FireWire (et pourquoi les ingénieurs l’aimaient)

IEEE 1394 en anglais opérationnel simple

FireWire (IEEE 1394) est un bus série conçu avec beaucoup d’ADN « vrai bus » : arbitrage, transferts peer-to-peer et capacité à déplacer des données avec moins de babysitting CPU. Il supportait à la fois les transferts asynchrones (données générales) et les transferts isochrones (flux sensibles au temps). Ce second mode explique pourquoi il est devenu le chouchou des caméras DV, des interfaces audio et des premiers workflows médias professionnels.

Traits pratiques clés qui comptaient :

• Capacité peer-to-peer : les périphériques pouvaient communiquer sans tout router via le modèle d’ordonnancement piloté par le CPU de l’hôte.
• Mode isochrone : mieux adapté aux flux réguliers que le monde « bulk d’abord » de l’USB initial.
• Moindre charge CPU (souvent) : moins d’interruptions et moins de bavardage de protocole pour certaines charges.
• Chaînage en guirlande : plusieurs appareils sur une chaîne, moins d’encombrement de hubs.

Le ressenti FireWire : prévisible, « pro », un peu snob

FireWire donnait l’impression d’un équipement de rack studio. Les connecteurs étaient assez robustes. Les performances étaient solides pour l’époque. L’écosystème avait de vrais succès : capture vidéo, stockage externe, audio, et même une certaine sensation de « ça marche simplement »—quand ça marchait réellement.

Mais la réalité en production transforme souvent l’esthétique en tableur.

Ce qu’était réellement l’USB (et pourquoi les achats l’aimaient)

La promesse initiale de l’USB : un port pour dominer le bureau

L’USB a été conçu pour remplacer un zoo de ports hérités par quelque chose d’universel, bon marché et simple. L’architecture est centrée sur l’hôte : le contrôleur hôte planifie les transferts, les périphériques répondent. Cela garde les périphériques plus simples et moins chers—un compromis d’ingénierie qui devient un avantage marché quand vous voulez mettre des ports sur chaque PC, imprimante, scanner et gadget en plastique.

Les caractéristiques déterminantes de l’USB n’étaient pas glamour, mais décisives :

• Contrôleurs peu coûteux et large intégration de chipsets.
• Pilotes de classe (HID, stockage de masse) qui réduisent les douleurs spécifiques aux fournisseurs.
• Plug-and-play que les consommateurs savent gérer sans lire un PDF.
• Compatibilité ascendante qui a créé une longue trajectoire « ça se branche encore ».

Le ressenti USB : désordonné, omniprésent, difficile à tuer

L’USB est la blatte des standards d’E/S, dans le sens le plus flatteur possible. Il survit. Il s’adapte. Il se retrouve là où il n’a pas sa place. Cette ubiquité en fait la réponse par défaut même quand ce n’est pas la meilleure.

Petite blague #1 : la nomenclature USB ressemble à un plan de migration de stockage rédigé par un comité—techniquement correct, émotionnellement traumatisant.

Faits intéressants et contexte historique (les choses qu’on oublie)

1. FireWire (IEEE 1394) a été développé avec une contribution significative d’Apple et positionné tôt comme un bus multimédia haut débit.
2. FireWire 400 (1394a) faisait 400 Mb/s et, dans des transferts soutenus réels, surpassait souvent l’USB 2.0 malgré le 480 Mb/s annoncé de ce dernier.
3. USB 1.1 plafonnait à 12 Mb/s (Full Speed). Le stockage USB précoce n’était pas pour le loisir.
4. FireWire supportait les transferts isochrones en tant que fonctionnalité de première classe, ce qui explique que les caméras DV l’aient standardisé pour les workflows d’ingest.
5. FireWire permettait le chaînage d’appareils sans hubs dans beaucoup de configurations ; l’USB s’est majoritairement reposé sur des hubs et une topologie centrée sur l’hôte.
6. Certains écosystèmes utilisaient FireWire pour des workflows de type « Target Disk Mode », transformant efficacement une machine en disque externe pour transfert et récupération de données.
7. Les pilotes de classe de stockage USB (MSC) ont réduit le besoin de pilotes spécifiques, ce qui a baissé les coûts de support à grande échelle.
8. Les perceptions de licences et de redevances autour de FireWire ont créé des frictions pour certains fabricants, tandis que l’USB a bénéficié d’un soutien industriel plus large et d’une commoditisation.
9. Quand FireWire 800 (800 Mb/s) a mûri, l’USB avait déjà atteint le statut de « port partout » et suivait un cycle d’itération et de marketing plus rapide.

Les vraies différences techniques qui apparaissent en production

Débit vs débit effectif vs « pourquoi mon CPU est à 30% pour une copie de disque ? »

Les specs sont du marketing. L’exploitation, c’est de la physique plus la qualité du pilote.

Le chiffre de 480 Mb/s de l’USB 2.0 semble battre le 400 Mb/s de FireWire 400. En pratique, l’USB 2.0 livrait souvent un débit soutenu inférieur pour les charges de stockage, surtout avec des contrôleurs et pilotes anciens, parce que :

• Surcharge protocolaire et complexité d’ordonnancement des transactions.
• Polling centré sur l’hôte et implication CPU.
• Comportement de bus partagé derrière hubs et câblage interne.
• Qualité d’implémentation du contrôleur et du pilote (qui varie énormément selon les époques).

FireWire présentait souvent de meilleures performances soutenues et une moindre charge CPU pour certains usages. Mais cela dépendait aussi d’avoir les bons ports, les bons câbles et les bons chipsets—des choses qui deviennent « optionnelles » dès que le marché le décide.

Isochrone vs bulk : pourquoi les musiciens s’en souciaient

Les transferts isochrones concernent les garanties de timing (ou au moins l’intention de timing). Cela importe pour les interfaces audio et la capture vidéo où le jitter et les dropouts sont plus douloureux que la perte de débit brut. FireWire a été conçu en gardant cela à l’esprit.

L’histoire initiale de l’USB reposait largement sur les transferts bulk pour le stockage et les transferts de contrôle pour les périphériques. Les versions ultérieures de l’USB se sont améliorées et les piles de pilotes ont mûri, mais la réputation est restée : FireWire = « pro audio/vidéo », USB = « périphériques ».

Topologie : bus vs arbre

Le modèle de chaînage de FireWire réduisait l’encombrement de hubs mais augmentait le mode de défaillance « un connecteur défaillant ruine la chaîne ». Le modèle hub-and-spoke de l’USB facilite l’expansion mais transforme le bus en domaine de contention partagé—surtout si quelqu’un branche un périphérique basse vitesse sur le même hub que votre SSD externe et se demande pourquoi les copies saccadent.

Alimentation et câbles : les tueurs peu glamours

Les pannes de stockage ne sont pas toujours des histoires de protocoles. Elles concernent souvent le budget d’alimentation, la qualité du câble et les connecteurs sous la poussière des bureaux. Les disques et boîtiers alimentés par USB ont rendu le stockage externe bon marché et portable, ce qui est parfait jusqu’à ce que le port ne puisse pas fournir un courant stable et que votre « disque » devienne un générateur aléatoire de déconnexions.

Petite blague #2 : L’interface de stockage la plus rapide est celle connectée par un câble qui n’est pas maintenu par l’espoir et la friction.

Pourquoi l’USB a gagné : l’économie ennuyeuse de l’ubiquité

1) L’intégration bat l’élégance

L’USB s’est intégré aux chipsets, aux workflows BIOS/UEFI, aux systèmes d’exploitation et aux attentes des consommateurs. FireWire nécessitait souvent des contrôleurs supplémentaires, de l’espace sur la carte et—surtout—quelqu’un pour s’en soucier.

Quand les fabricants de cartes mères rognent des centimes et cherchent des arguments marketing, « port supplémentaire que seules quelques personnes utilisent » devient une cible. L’USB n’a jamais été « supplémentaire ». C’était le plan.

2) Les périphériques bon marché créent une roue de renforcement

Une fois que vous pouvez acheter un périphérique USB bon marché, vous l’achetez. Une fois que vous en possédez un, vous voulez des ports USB. Une fois que vous avez des ports, les fournisseurs fabriquent plus d’appareils. Cette boucle se renforce. L’écosystème FireWire était plus petit, plus professionnel et donc plus cher par unité. Ce n’est pas une défaite morale ; c’est un résultat du marché.

3) Coûts de support et histoire des pilotes

Les pilotes de classe USB ont compté. Pour l’informatique à grande échelle, « ça s’énumère et marche avec le pilote intégré » n’est pas une commodité. C’est une ligne budgétaire. FireWire avait un bon support, mais le caractère « par défaut » de l’USB a réduit les frictions pour imprimantes, scanners, claviers, stockages et plus tard les téléphones.

4) Perception et disponibilité

Les gens choisissent ce qu’ils peuvent obtenir aujourd’hui, pas ce qui est théoriquement meilleur. Entrez dans n’importe quel magasin de fournitures de bureau dans les années 2000 : câbles USB et périphériques sur chaque étagère. FireWire était un article spécialisé, de plus en plus traité comme tel.

5) Calendrier : l’USB a continué d’itérer tandis que FireWire perdait du terrain

Même quand FireWire 800 était une forte réponse technique, l’USB était déjà le connecteur par défaut sur la planète. Le marché ne fait pas « en retard mais meilleur » à moins d’un facteur de contrainte. Il n’y en avait pas.

Une citation opérationnelle à garder en tête

« Everything fails all the time. » — Werner Vogels

Ce n’est pas du cynisme ; c’est de la planification de capacité pour la réalité. Choisissez des interfaces et des workflows qui échouent de façon prévisible, faciles à diagnostiquer et faciles à remplacer. À l’échelle de l’écosystème, l’USB correspondait mieux à cela, même quand les implémentations individuelles étaient plus désordonnées.

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

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

Une société média de taille moyenne exploitait une flotte de stations qui effectuaient des ingestings et transcodages nocturnes. Les stations d’ingest recevaient des disques externes fournis depuis les tournages. L’équipe IT a standardisé sur « externe rapide » et a supposé « USB 3 veut dire toujours assez rapide ». Ils ont aussi supposé que si le port est bleu, le bus est correct.

Un jour, les temps d’ingest ont doublé. Puis triplé. Les monteurs ont commencé à mettre les jobs en file pendant la nuit et arrivaient devant des rendus à moitié terminés. La supervision du cluster de transcodage avait l’air normale ; l’utilisation CPU et GPU était correcte. Le goulot venait en amont : les stations d’ingest.

Le coupable était un « refresh » piloté par les achats qui avait changé en douce la topologie USB interne. Plusieurs ports en façade partageaient un hub avec une webcam interne et un module Bluetooth, et sous certains mélanges de périphériques les disques externes négociaient une vitesse réduite ou subissaient des réinitialisations répétées. Les logs OS montraient des déconnexions transitoires et des ré-énumérations, mais personne n’examinait les logs des stations parce que « les stations ne sont pas des serveurs ».

La correction n’a pas été héroïque. Ils ont cartographié les ports par contrôleur, imposé l’usage des ports arrière pour l’ingest et interdit les hubs pour le stockage dans ce workflow. Ils ont aussi ajouté un petit contrôle de santé : si un disque s’énumère en High Speed (USB 2.0) plutôt qu’en SuperSpeed, le script d’ingest refuse de démarrer et demande à l’utilisateur de changer de port.

La mauvaise hypothèse n’était pas « USB est lent ». C’était « les étiquettes de vitesse USB sont une promesse ». Elles ne le sont pas. C’est une négociation.

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

Une équipe d’ingénierie desktop d’entreprise devait imager des centaines de machines par semaine. Ils utilisaient des SSD externes avec une « image maître » pour éviter de saturer le réseau. Quelqu’un a remarqué que le processus d’imagerie effectuait une passe complète de vérification après l’écriture. Ils l’ont désactivée pour gagner du temps.

Pendant un moment, cela a paru brillant. Le débit d’imagerie a augmenté. La file a diminué. Tout le monde a félicité la demande de changement.

Puis une lente hémorragie a commencé : un petit pourcentage de machines démarrait avec des problèmes de système de fichiers étranges, corruption de pilotes ou installations applicatives en échec. La réimagerie corrigeait parfois, parfois non. Les tickets ont afflué. On a commencé à blâmer l’image OS, l’agent de sécurité endpoint, voire « des lots de RAM défectueux ».

Cela s’est avéré être une combinaison de câbles USB marginaux, de quelques bridges de boîtier défectueux et de réinitialisations de bus occasionnelles pendant des écritures soutenues. Avec la vérification désactivée, la corruption silencieuse passait inaperçue. L’« optimisation » avait supprimé la seule étape qui l’aurait détectée tant que la machine était encore sur le banc.

Ils ont réactivé la vérification, standardisé sur des câbles certifiés plus courts et ajouté une étape checksum rapide sur le fichier image lui-même. Le débit a un peu chuté. Les incidents ont fortement diminué. C’est ce genre de compromis qui compte.

Mini-récit n°3 : La pratique ennuyeuse mais correcte qui a sauvé la situation

Un petit laboratoire de recherche utilisait des contrôleurs d’instruments qui déversaient des données sur des disques externes pendant les relevés sur le terrain. Ils employaient un mélange d’ordinateurs portables USB et quelques machines plus anciennes avec des ports FireWire pour du matériel legacy. L’équipe terrain détestait les « étapes supplémentaires », mais l’IT exigeait un rituel simple : avant chaque session de capture, exécuter un contrôle de sanity court et enregistrer la vitesse du bus et les compteurs d’erreurs.

Un jour, une unité de terrain a commencé à perdre des échantillons—de façon intermittente. Ce n’était pas catastrophique, ce qui l’a rendu pire : les données semblaient plausibles, jusqu’à ce qu’on compare les horodatages et constate des trous. Le fournisseur de l’instrument a blâmé le logiciel du contrôleur. Les chercheurs ont blâmé le disque. L’IT a blâmé tout le monde, en silence.

Parce que l’équipe avait ces contrôles pré-vol, ils ont pu corréler les échecs à un modèle d’ordinateur portable spécifique et à un port USB précis. Les logs montraient des messages récurrents de réinitialisation xHCI sous charge d’écriture soutenue. L’insertion d’un hub alimenté (oui, parfois la « boîte supplémentaire » est la solution) a stabilisé la fourniture d’alimentation. Ils ont aussi modifié le chemin de capture pour écrire localement d’abord, puis copier vers le stockage externe après la session.

C’était ennuyeux : vérifier, enregistrer, comparer, isoler. Pas d’héroïsme. Mais ça a évité une semaine de terrain gâchée, le type d’incident qui n’apparaît pas sur les tableaux de bord mais qui détruit les budgets.

Mode d’emploi pour un diagnostic rapide : quoi vérifier en premier/deuxième/troisième

Objectif : décider en 10 minutes si c’est le disque, le boîtier, le câble, le port/contrôleur ou le système de fichiers

Premier : identifier la vitesse de lien négociée et la topologie

• Est-ce qu’il fonctionne réellement à la vitesse attendue (USB 2 vs USB 3) ?
• Est-il derrière une chaîne de hubs ou de dongles ?
• Le contrôleur est-il partagé avec d’autres périphériques à fort trafic ?

Deuxième : vérifier les réinitialisations, déconnexions et erreurs de transport

• Logs kernel : réinitialisations USB, retours UAS vers usb-storage, erreurs SCSI.
• SMART : erreurs CRC, erreurs média, pics du compteur de cycles d’alimentation.

Troisième : benchmarkez la bonne chose (et ne vous mentez pas)

• Lecture/écriture séquentielle pour les attentes de copies en vrac.
• Latence et IOPS si la charge concerne de petits fichiers ou des bases de données.
• Utilisation CPU pendant le transfert (la charge de l’hôte compte).

Points de décision

• Si la vitesse négociée est incorrecte : corrigez câblage/port/dongle d’abord ; ne touchez pas au logiciel.
• Si les logs montrent des réinitialisations : suspectez l’alimentation/le câble/le firmware du boîtier ; échangez les composants.
• Si les benchmarks vont bien mais que les « vraies copies » sont lentes : suspectez le système de fichiers, le chiffrement, l’antivirus ou le surcoût des petits fichiers.

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

Ces exemples sont orientés Linux parce que c’est là que l’instrumentation est la plus claire. La logique est la même ailleurs : identifier le bus, valider la vitesse, vérifier les erreurs, puis mesurer.

Task 1: List USB topology and negotiated speed

cr0x@server:~$ lsusb -t
/:  Bus 02.Port 1: Dev 1, Class=root_hub, Driver=xhci_hcd/4p, 10000M
    |__ Port 2: Dev 3, If 0, Class=Mass Storage, Driver=uas, 5000M
/:  Bus 01.Port 1: Dev 1, Class=root_hub, Driver=ehci-pci/6p, 480M
    |__ Port 4: Dev 5, If 0, Class=Mass Storage, Driver=usb-storage, 480M

Ce que ça signifie : Un périphérique de stockage est en SuperSpeed (5000M) utilisant UAS ; un autre est coincé à 480M utilisant l’ancien pilote usb-storage.

Décision : Déplacez le périphérique lent sur un vrai port USB 3, retirez hubs/dongles et vérifiez que le câble est compatible USB 3. Si ça négocie encore 480M, suspectez le bridge du boîtier ou le câble.

Task 2: Identify the specific device and vendor/product IDs

cr0x@server:~$ lsusb
Bus 002 Device 003: ID 152d:0578 JMicron Technology Corp. / JMicron USA Technology Corp. JMS578 SATA 6Gb/s bridge
Bus 001 Device 005: ID 0bc2:3320 Seagate RSS LLC Expansion Desk

Ce que ça signifie : Vous pouvez relier le comportement à un chipset bridge (ici, JMS578) ou à un modèle d’enclosure spécifique.

Décision : Si un bridge particulier montre des problèmes répétés, standardisez en l’évitant. Dans les parcs, la cohérence des chipsets bat la vitesse de pointe théorique.

Task 3: Watch kernel logs for resets and transport errors

cr0x@server:~$ sudo dmesg -T | tail -n 25
[Mon Jan 21 10:14:02 2026] usb 2-2: reset SuperSpeed USB device number 3 using xhci_hcd
[Mon Jan 21 10:14:03 2026] scsi host6: uas
[Mon Jan 21 10:14:03 2026] sd 6:0:0:0: [sdb] tag#23 uas_eh_abort_handler 0 uas-tag 4 inflight: CMD OUT
[Mon Jan 21 10:14:03 2026] sd 6:0:0:0: [sdb] tag#23 CDB: Write(10) 2a 00 1a 2b 10 00 00 08 00 00
[Mon Jan 21 10:14:03 2026] blk_update_request: I/O error, dev sdb, sector 439037952 op 0x1:(WRITE) flags 0x0 phys_seg 1 prio class 0

Ce que ça signifie : La réinitialisation du bus + l’abort UAS + les erreurs I/O pointent vers une instabilité de transport (alimentation, câble, firmware du boîtier), pas un « système de fichiers lent ».

Décision : Changez de câble, testez un autre port/contrôleur et envisagez de forcer BOT (désactiver UAS) comme test. Si les erreurs persistent, retirez l’enclosure du parc.

Task 4: Confirm which driver is bound (UAS vs usb-storage)

cr0x@server:~$ readlink -f /sys/bus/usb/devices/2-2:1.0/driver
/sys/bus/usb/drivers/uas

Ce que ça signifie : Le périphérique utilise UAS, typiquement meilleur pour les performances mais parfois source de bugs firmware.

Décision : Si vous voyez des réinitialisations/timeouts avec UAS, testez avec UAS désactivé (tâche suivante). Ne conservez le changement que s’il améliore la fiabilité.

Task 5: Temporarily disable UAS for a specific device (test reliability)

cr0x@server:~$ echo 'options usb-storage quirks=152d:0578:u' | sudo tee /etc/modprobe.d/disable-uas.conf
options usb-storage quirks=152d:0578:u

Ce que ça signifie : Cela définit une quirk pour forcer le périphérique à utiliser usb-storage (BOT) au lieu d’UAS.

Décision : Redémarrez ou rechargez les modules, puis retestez débit et taux d’erreur. Si la stabilité s’améliore nettement, vous avez trouvé un problème de firmware/bridge ; planifiez le remplacement du matériel.

Task 6: Inspect block device identity and path

cr0x@server:~$ lsblk -o NAME,MODEL,SERIAL,SIZE,TRAN,ROTA,TYPE,MOUNTPOINTS
NAME   MODEL            SERIAL        SIZE TRAN ROTA TYPE MOUNTPOINTS
sda    Samsung_SSD      S5R...        1.8T sata    0 disk
sdb    USB_SSD_Encl     0123456789AB  932G usb     0 disk /mnt/ext

Ce que ça signifie : Confirme que le périphérique est bien connecté via USB (TRAN=usb) et s’il est rotatif.

Décision : S’il est rotatif et que vous attendez des vitesses SSD, arrêtez de blâmer le bus. S’il s’agit d’un SSD et qu’il est lent, concentrez-vous sur la vitesse du bus, le bridge de l’enclosure et le surcoût du système de fichiers.

Task 7: Quick sequential read test (bypassing filesystem cache)

cr0x@server:~$ sudo dd if=/dev/sdb of=/dev/null bs=16M status=progress iflag=direct
2147483648 bytes (2.1 GB, 2.0 GiB) copied, 9 s, 238 MB/s

Ce que ça signifie : Débit de lecture brut depuis le block device. Évite les astuces du cache de pages.

Décision : Si vous êtes bloqué à ~35–40 MB/s, vous êtes probablement en USB 2.0. Si vous êtes dans les centaines, le bus est probablement correct.

Task 8: Quick sequential write test (destructive if you point at a real filesystem)

cr0x@server:~$ sudo dd if=/dev/zero of=/mnt/ext/testfile.bin bs=16M count=256 oflag=direct status=progress
4294967296 bytes (4.3 GB, 4.0 GiB) copied, 20 s, 214 MB/s

Ce que ça signifie : Débit d’écriture soutenu sur le système de fichiers monté. L’utilisation de oflag=direct réduit les effets du cache.

Décision : Si les écritures sont bien plus lentes que les lectures, suspectez les options de journalisation du FS, le chiffrement ou le cache d’écriture/thermal throttling du dispositif.

Task 9: Measure latency and IOPS (small-file pain)

cr0x@server:~$ sudo fio --name=randread --filename=/mnt/ext/fio.bin --size=2G --direct=1 --rw=randread --bs=4k --iodepth=32 --numjobs=1 --time_based --runtime=30
randread: (groupid=0, jobs=1): err= 0: pid=18422: Mon Jan 21 10:22:10 2026
  read: IOPS=5400, BW=21.1MiB/s (22.1MB/s)(633MiB/30001msec)
    slat (usec): min=8, max=210, avg=18.40, stdev=6.12
    clat (usec): min=120, max=9800, avg=590.22, stdev=410.55

Ce que ça signifie : IOPS de lecture aléatoire et latence. Le stockage USB externe peut sembler « rapide » pour de grandes copies séquentielles et être catastrophique pour les petits I/O aléatoires.

Décision : Si la latence est élevée et que la charge concerne de petits fichiers (installations de paquets, checkouts git, disques de VM), arrêtez d’utiliser ce disque externe pour ce cas d’usage. Utilisez un NVMe interne ou une solution réseau adaptée.

Task 10: Check SMART health (if available through USB bridge)

cr0x@server:~$ sudo smartctl -a /dev/sdb
smartctl 7.3 2022-02-28 r5338 [x86_64-linux-6.5.0] (local build)
=== START OF INFORMATION SECTION ===
Device Model:     CT1000MX500SSD1
Serial Number:    1234ABCDE567
...
=== START OF SMART DATA SECTION ===
Reallocated_Sector_Ct   0x0033   100   100   010    Pre-fail  Always       -       0
UDMA_CRC_Error_Count    0x003e   200   200   000    Old_age   Always       -       12

Ce que ça signifie : Les erreurs CRC indiquent souvent des problèmes d’intégrité signal (câble/boîtier), pas forcément de NAND mourante.

Décision : Si les CRC augmentent, remplacez d’abord le câble et l’enclosure. Si les secteurs réalloués augmentent, remplacez le disque.

Task 11: Verify filesystem and mount options

cr0x@server:~$ mount | grep /mnt/ext
/dev/sdb1 on /mnt/ext type ext4 (rw,nosuid,nodev,noatime,discard)

Ce que ça signifie : Des options comme discard peuvent nuire aux performances sur certains dispositifs ; noatime peut aider pour des charges riches en métadonnées.

Décision : Si la performance est incohérente, testez sans discard continu (préférez fstrim périodique). Gardez noatime pour les workloads intensifs en petits fichiers.

Task 12: Check for USB autosuspend power management issues

cr0x@server:~$ cat /sys/module/usbcore/parameters/autosuspend
2

Ce que ça signifie : Autosuspend est activé (secondes). Une autosuspension agressive peut provoquer des déconnexions sur des périphériques marginaux.

Décision : Pour les périphériques de stockage instables, désactivez l’autosuspend pour ce périphérique ou globalement (avec précaution), puis retestez la stabilité.

Task 13: Identify which PCIe USB controller you’re on

cr0x@server:~$ lspci -nn | grep -i usb
00:14.0 USB controller [0c03]: Intel Corporation Sunrise Point-LP USB 3.0 xHCI Controller [8086:9d2f]

Ce que ça signifie : Relie le comportement à une famille de contrôleur. Certains ont des quirks connus avec certains bridges.

Décision : Si une famille de contrôleurs est régulièrement problématique, routez les workflows critiques vers un contrôleur add-in connu bon ou un modèle d’hôte différent.

Task 14: Check link power management and errors during load

cr0x@server:~$ sudo journalctl -k -n 80 | grep -Ei 'usb|uas|xhci|reset|error'
Jan 21 10:24:11 server kernel: usb 2-2: reset SuperSpeed USB device number 3 using xhci_hcd
Jan 21 10:24:12 server kernel: sd 6:0:0:0: [sdb] Synchronizing SCSI cache
Jan 21 10:24:12 server kernel: sd 6:0:0:0: [sdb] tag#7 FAILED Result: hostbyte=DID_ERROR driverbyte=DRIVER_OK

Ce que ça signifie : Confirme des erreurs récurrentes au niveau transport corrélées à la charge.

Décision : Arrêtez d’ajuster les paramètres applicatifs. Remplacez la couche physique : câble, port, hub, enclosure. Si vous devez le garder en service, déplacez la charge vers un chemin plus sûr (copiez localement d’abord).

Task 15: Validate negotiated speed on a specific device path

cr0x@server:~$ cat /sys/bus/usb/devices/2-2/speed
5000

Ce que ça signifie : 5000 Mb/s (USB 3.0 SuperSpeed). Si vous voyez 480, vous êtes effectivement en USB 2.0.

Décision : Si la vitesse est 480 alors que vous attendiez 5000/10000, changez câble/port/dongle. N’acceptez pas « c’est bon » tant que ce nombre n’est pas correct.

Task 16: Confirm hub chain depth (dongles can quietly ruin you)

cr0x@server:~$ usb-devices | sed -n '1,120p'
T:  Bus=02 Lev=00 Prnt=00 Port=00 Cnt=00 Dev#=  1 Spd=10000 MxCh= 4
D:  Ver= 3.20 Cls=09(hub) Sub=00 Prot=03 MxPS= 9 #Cfgs=  1
P:  Vendor=1d6b ProdID=0003 Rev=06.05
S:  Product=xHCI Host Controller
...
T:  Bus=02 Lev=02 Prnt=02 Port=02 Cnt=01 Dev#=  3 Spd=5000  MxCh= 0
D:  Ver= 3.10 Cls=00(>ifc) Sub=00 Prot=00 MxPS= 9 #Cfgs=  1
P:  Vendor=152d ProdID=0578 Rev=02.10
S:  Product=JMS578

Ce que ça signifie : Montre que le périphérique est au niveau 2 (derrière quelque chose). Plus il y a de dongles/hubs, plus il y a de « surprises ».

Décision : Pour les transferts critiques, réduisez la profondeur de chaîne : connexion directe au port hôte, de préférence en I/O arrière, idéalement sur un contrôleur dédié.

Erreurs courantes : symptôme → cause racine → correctif

1) « Le disque USB 3 copie à 35 MB/s »

Symptômes : Vitesse de copie autour de 30–40 MB/s ; CPU correct ; tout « fonctionne » mais lent.

Cause racine : Le périphérique a négocié en USB 2.0 (480M) à cause d’un mauvais câble, d’un port défaillant, d’un hub/dongle ou d’une limitation de l’enclosure.

Correctif : Vérifiez lsusb -t et /sys/bus/usb/devices/.../speed. Passez à un câble USB 3 connu, port direct, évitez les hubs et vérifiez qu’il indique 5000/10000.

2) Déconnexions aléatoires pendant de gros écrits

Symptômes : « device not accepting address », « reset SuperSpeed USB device », remontage du système de fichiers en lecture seule.

Cause racine : Instabilité d’alimentation, câble marginal, bug firmware du bridge du boîtier ou problème de transport UAS.

Correctif : Essayez un câble court et de meilleure qualité, utilisez un hub alimenté pour les périphériques bus-powered, mettez à jour le firmware de l’enclosure si possible, ou désactivez UAS à titre diagnostique (et remplacez le matériel si c’est la seule façon d’obtenir de la stabilité).

3) Les benchmarks sont bons, la charge réelle est mauvaise

Symptômes : dd montre 300 MB/s mais l’extraction d’un tar prend une éternité ; les opérations git sont lentes.

Cause racine : I/O aléatoire petit et surcharge métadonnées ; choix/options du système de fichiers ; antivirus ou indexation ; surcharge du chiffrement.

Correctif : Mesurez avec fio 4k random ; utilisez un SSD interne pour les métadonnées ; ajustez les options de montage (noatime), évitez les systèmes de fichiers lents sur des médias lents et excluez les scans lourds quand c’est pertinent.

4) « Nous avons désactivé la vérification pour accélérer l’imagerie » et maintenant tout est hanté

Symptômes : Problèmes de démarrage incohérents, installations corrompues, échecs qui disparaissent après réimagerie.

Cause racine : Corruption silencieuse due à un transport défaillant, câbles de mauvaise qualité ou réinitialisations pendant l’écriture.

Correctif : Réactivez vérification/checksums, standardisez le matériel et traitez la qualité des câbles comme une dépendance de première classe.

5) Un port fonctionne, un autre pas

Symptômes : Le même disque se comporte différemment selon le port utilisé.

Cause racine : Câblage interne/hub/contrôleur différent ; les ports avant ont souvent une intégrité de signal moins bonne ; bande passante partagée avec d’autres périphériques internes.

Correctif : Cartographiez les ports vers les contrôleurs (lsusb -t, usb-devices), standardisez sur des ports connus bons pour le stockage à haut débit et documentez-le.

6) Le périphérique FireWire « était fiable » mais maintenant c’est une pièce de musée

Symptômes : Adaptateurs partout ; problèmes de compatibilité ; difficile de trouver ports/câbles ; support de pilotes intermittent sur les nouveaux OS.

Cause racine : Effondrement de l’écosystème : moins de contrôleurs natifs, plus de chaînes d’adaptateurs, moins de tests par les fournisseurs.

Correctif : Migrez les workflows : capturez localement puis transférez via des interfaces modernes ; conservez une machine legacy connue et stable pour l’ingest d’archives ; ne comptez plus sur des piles d’adaptateurs en production.

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

Checklist A : Standardiser le stockage externe pour une équipe

1. Choisissez un modèle d’enclosure et un modèle de disque ; testez-les sur vos plateformes hôtes principales.
2. Exigez des câbles conformes à la spécification de vitesse (étiquetez-les ; jetez les câbles mystères).
3. Décidez si vous autorisez hubs/dongles. Pour le stockage : défaut « non ».
4. Définissez une vérification minimale de la vitesse négociée (scriptable via sysfs sur Linux).
5. Choisissez le système de fichiers et les options de montage selon la charge (séquentiel vs métadonnées).
6. Notez les « ports connus bons » sur chaque modèle d’hôte (I/O arrière vs façade).
7. Incluez une étape de vérification pour l’imagerie/sauvegarde (checksum ou relecture).
8. Suivez les défaillances par chipset bridge et famille de contrôleur, pas seulement par « marque de disque ».

Checklist B : Avant d’accuser le réseau ou l’array de stockage

1. Vérifiez la vitesse et le pilote (UAS vs BOT).
2. Consultez les logs kernel pour réinitialisations et erreurs I/O.
3. Effectuez un test de lecture raw et un test d’écriture sur le système de fichiers.
4. Réalisez un test 4k random si la charge concerne « beaucoup de petits fichiers ».
5. Vérifiez SMART et surveillez spécifiquement le compteur d’erreurs CRC.
6. Changez le câble avant de changer le disque. Puis changez l’enclosure.

Checklist C : Plan de migration depuis FireWire sans drame

1. Inventoriez ce qui requiert encore FireWire (périphériques de capture, disques legacy, vieux Mac).
2. Gardez une machine d’ingest legacy dédiée, stable et inchangée.
3. Déplacez la capture sur le stockage interne local d’abord ; transférez ensuite via des interfaces modernes.
4. Quand possible, remplacez l’appareil FireWire par un équivalent moderne plutôt que d’empiler des adaptateurs.
5. Testez le workflow complet avec de vraies tailles de données et de l’injection de pannes (débrancher/rebrancher, cycles d’alimentation).

FAQ

1) Est-ce que FireWire était réellement plus rapide que l’USB ?

Souvent, oui en transferts soutenus réels comparés à l’USB 2.0, malgré la bande passante annoncée plus élevée de l’USB 2.0. FireWire avait tendance à fournir un débit plus stable et une moindre charge CPU dans de nombreuses configurations.

2) Si FireWire était meilleur, pourquoi tout le monde ne l’a-t-il pas gardé ?

Parce que les écosystèmes gagnent. L’USB était moins cher à implémenter, s’est intégré partout, a bénéficié de pilotes de classe et est devenu le port par défaut. La disponibilité bat l’élégance.

3) L’USB est-il « mauvais » pour le stockage externe aujourd’hui ?

Non. L’USB moderne (et USB-C) peut être excellent. Le problème est la variabilité : câbles, enclosures, hubs, implémentations de contrôleurs et alimentation peuvent encore saboter vos flux.

4) Pourquoi certains disques USB se déconnectent-ils aléatoirement sous charge ?

Causes courantes : alimentation insuffisante (surtout pour les disques rotatifs alimentés par le bus), câbles marginaux, firmware buggy du bridge du boîtier ou quirks UAS qui se manifestent sous I/O soutenu.

5) Quelle est la façon la plus rapide de savoir si je suis accidentellement en USB 2.0 ?

Sur Linux : cat /sys/bus/usb/devices/<dev>/speed ou lsusb -t. Si vous voyez 480M, vous êtes en USB 2.0.

6) Dois-je désactiver UAS pour corriger des problèmes ?

Seulement comme diagnostic ou solution de dernier recours. Si désactiver UAS rend un périphérique stable, la vraie correction est de remplacer le boîtier/bridge par un modèle qui se comporte correctement.

7) Pourquoi les benchmarks ne sont-ils pas d’accord avec les copies de fichiers ?

Les benchmarks mesurent souvent le débit séquentiel ; les workloads réels peuvent être riches en métadonnées ou en I/O aléatoire. De plus, les caches peuvent mentir. Utilisez des tests en I/O direct et mesurez la charge réelle que vous exécutez.

8) Thunderbolt est-il le « nouveau FireWire » ?

Dans le sens où il est plus « comme un bus » et hautes performances, oui. Dans le sens où il va automatiquement gagner partout, non. Le coût, l’intégration et le fait que « chaque machine aléatoire l’ait » décident encore de l’adoption.

9) Si j’ai encore du matériel FireWire, quelle est la démarche opérationnelle la plus sûre ?

Gardez un hôte legacy connu et stable, évitez les chaînes d’adaptateurs en production, capturez localement d’abord et traitez le workflow comme une entrée d’archives—contrôlée, répétable et documentée.

Conclusion : que faire la semaine prochaine, pas le trimestre prochain

FireWire a perdu parce que l’USB s’est implanté partout d’abord, est devenu moins cher plus vite et a réduit les frictions pour les fabricants et l’IT. La leçon n’est pas « le marché est stupide ». La leçon est que l’effet de levier opérationnel bat la pureté du protocole.

Prochaines étapes qui rapportent immédiatement :

• Ne faites plus confiance aux étiquettes. Vérifiez la vitesse négociée et le pilote chaque fois qu’un workflow de stockage externe est critique.
• Standardisez la couche physique. Un modèle d’enclosure, un type de câble, ports connus-bons, dongles minimaux.
• Instrumentez les workflows poste de travail. Les logs kernel et les contrôles de vitesse ne sont pas réservés aux serveurs.
• Rendez la vérification non négociable pour l’imagerie, les sauvegardes et les pipelines d’ingest où la corruption silencieuse coûte cher.
• Planifiez vos sorties legacy. Si FireWire est encore dans votre chemin critique, traitez cela comme une dette technique avec un calendrier de sortie.

Vous n’avez pas besoin de l’interface « la meilleure ». Vous avez besoin de l’interface qui échoue de façon prévisible, est diagnostiquable et remplaçable à 16h30 un vendredi. L’USB a gagné parce qu’il s’est optimisé pour le monde tel qu’il est. Opérez en conséquence.

Ce que signifie réellement « error opening » dans le contexte Proxmox RBD

Quand Proxmox dit « RBD: error opening », vous voyez généralement une erreur remontée depuis librbd (la librairie userspace utilisée pour accéder aux images RBD).
La librairie tente de :

1. Charger la configuration Ceph (moniteurs, réglages d’authentification, fsid, etc.).
2. S’authentifier (cephx) en utilisant une clé pour un ID client donné (client.admin, client.pve ou un utilisateur personnalisé).
3. Parler aux moniteurs (MONs), obtenir la carte du cluster et localiser les OSDs.
4. Ouvrir l’image RBD (ce qui nécessite des permissions sur le pool et l’image).

« Error opening » est fréquemment déclenché par :

• Mauvais ou absence de keyring/clé dans la configuration de stockage Proxmox.
• Inadéquation d’ID client : vous avez la bonne clé, mais pour le mauvais nom de client.
• Caps ne permettant pas l’opération (caps en lecture seule mais vous créez des images ; absence de profile rbd ; manque d’accès aux métadonnées rbd_children, etc.).
• Moniteurs inaccessibles depuis un nœud (routage, pare-feu, mon_host incorrect, confusion IPv6 vs IPv4).
• Différences de configuration Ceph entre nœuds (un nœud a un /etc/ceph/ceph.conf obsolète ou un fsid erroné).
• Permissions des fichiers keyring sur le disque : root peut le lire, mais un processus tourne sous un autre utilisateur (courant dans des outils personnalisés ; moins courant sur une installation Proxmox standard).

La manière la plus rapide d’arrêter de deviner est de reproduire l’opération d’ouverture exacte depuis le nœud défaillant en utilisant la CLI rbd avec le même ID et le même keyring.
Si rbd ls fonctionne mais que rbd info pool/image échoue, vous êtes face à un mismatch de caps. Si rien ne fonctionne, commencez par les moniteurs + keyring.

Blague n°1 : « Error opening » est ce que Ceph dit quand il est trop poli pour dire « votre keyring est pourri. »

Fiche de diagnostic rapide (vérifier 1/2/3)

C’est l’ordre qui termine les incidents le plus vite. Pas l’ordre qui procure la satisfaction émotionnelle.

1) Confirmez que vous pouvez atteindre les moniteurs et vous authentifier depuis le nœud défaillant

• Si la connectivité aux moniteurs ou l’auth cephx échoue, rien d’autre n’a d’importance. Réglez d’abord ça.
• Utilisez ceph -s et ceph auth get client.X le cas échéant.

2) Confirmez que Proxmox utilise bien le keyring que vous croyez

• Inspectez /etc/pve/storage.cfg et le chemin keyring par stockage (ou la clé intégrée).
• Validez que le fichier existe sur chaque nœud (la config Proxmox est partagée, mais les fichiers keyring sont locaux sauf si vous les gérez explicitement).

3) Validez les caps par rapport au pool et à l’opération

• Listez les caps : ceph auth get client.pve.
• Testez avec des commandes rbd qui reflètent l’action en échec : rbd ls, rbd info, rbd create, rbd snap ls.

4) Ensuite seulement : investiguez les erreurs de l’UI Proxmox, les logs qemu et les cas limites

• Consultez les logs de tâches et journalctl pour pvedaemon, pveproxy et qemu-server.
• La plupart des incidents « error opening » sont liés à l’auth/caps/config. Les cas exotiques existent, mais ce ne sont pas vos premiers suspects.

Faits et contexte intéressants (parce que le passé tourne encore en prod)

• L’auth Ceph « cephx » a été conçue pour éviter les secrets partagés à l’échelle du cluster. Vous pouvez limiter les clés aux pools et aux opérations, d’où l’importance des caps.
• Le public initial de RBD était les plateformes cloud. Le modèle « image + snapshot + clone » est très centré VM, d’où l’adoption précoce par Proxmox et OpenStack.
• Proxmox stocke la config du cluster dans un système de fichiers distribué. /etc/pve est partagé entre nœuds, mais les fichiers locaux comme /etc/ceph/ceph.client.pve.keyring ne sont pas répliqués automatiquement.
• Historiquement, beaucoup de déploiements utilisaient client.admin partout. Ça « marche » jusqu’à ce que ça devienne un cauchemar d’audit et un amplificateur d’incidents.
• La syntaxe des caps a évolué dans le temps. Les anciens articles montrent des modèles obsolètes ; Ceph moderne préfère profile rbd plus le scope explicite du pool.
• Les moniteurs Ceph sont une porte de cohérence. Vous pouvez avoir des OSDs sains et quand même échouer à des ouvertures RBD si le quorum MON ou l’accessibilité sont rompus depuis un nœud.
• Ouvrir un RBD peut nécessiter des opérations sur les métadonnées. Même les lectures peuvent exiger l’accès aux métadonnées du pool (et selon les fonctionnalités, aux clés omap). « Je lui ai donné lecture seule » peut être accidentellement trop strict.
• La découverte de configuration Ceph a plusieurs chemins. Variables d’environnement, chemins par défaut et flags explicites peuvent conduire à un « ça marche dans mon shell » mais échoue dans les tâches Proxmox.

Symptômes courants : ce que vous verrez et où

Proxmox peut exposer la même défaillance sous plusieurs couches. Apprenez les schémas :

• Journal de tâches Proxmox : « rbd: error opening » lors de la création de disque, de l’attachement, d’un snapshot, d’une migration ou du démarrage d’une VM.
• Échecs de démarrage QEMU : la VM ne démarre pas ; les logs qemu mentionnent l’incapacité à ouvrir l’image RBD.
• Erreurs CLI de mapping : rbd map retourne « permission denied » ou « error connecting to the cluster ».
• Indices côté Ceph : les logs MON montrent des échecs d’auth ; les logs OSD montrent des opérations refusées ; mais souvent Ceph reste silencieux sauf si les niveaux de debug sont augmentés.
• Comportement spécifique au nœud : un nœud Proxmox peut accéder au RBD ; un autre ne le peut pas. Ça crie « mismatch de keyring/config locale ».

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

Le but de ces tâches est de transformer des erreurs UI vagues en décisions nettes. Exécutez-les depuis le nœud Proxmox défaillant d’abord, puis depuis un nœud connu bon pour comparer.

Task 1: Confirm Ceph cluster is reachable and you’re not chasing ghosts

cr0x@server:~$ ceph -s
  cluster:
    id:     2c3d1d5e-9a2e-4e2b-8a59-4f1c7c0c1c2f
    health: HEALTH_OK

  services:
    mon: 3 daemons, quorum mon1,mon2,mon3 (age 2h)
    mgr: mgr1(active, since 2h)
    osd: 12 osds: 12 up (since 3h), 12 in (since 3h)

  data:
    pools:   4 pools, 256 pgs
    objects: 3.2M objects, 12 TiB
    usage:   36 TiB used, 72 TiB / 108 TiB avail
    pgs:     256 active+clean

Ce que cela signifie : Cela confirme que la CLI peut parler aux moniteurs et s’authentifier en utilisant la config/clé par défaut que votre shell utilise.

Décision : Si cela échoue sur le nœud en panne mais fonctionne ailleurs, corrigez d’abord l’accessibilité des moniteurs et la config Ceph locale avant de toucher Proxmox.

Task 2: Identify what Proxmox thinks your RBD storage is

cr0x@server:~$ grep -nE '^(rbd:|[[:space:]]*(pool|monhost|username|keyring|content))' /etc/pve/storage.cfg
12:rbd: ceph-rbd
13:        monhost 10.10.0.11 10.10.0.12 10.10.0.13
14:        pool vmdata
15:        username pve
16:        keyring /etc/ceph/ceph.client.pve.keyring
17:        content images,rootdir

Ce que cela signifie : Proxmox tentera de se connecter à ces IPs de moniteurs, s’authentifier en tant que client.pve, en utilisant ce fichier keyring.

Décision : Si le keyring est absent ou pointe vers un fichier qui n’existe pas sur certains nœuds, vous avez trouvé la cause racine.

Task 3: Verify the keyring file exists on this node and is readable

cr0x@server:~$ ls -l /etc/ceph/ceph.client.pve.keyring
-rw------- 1 root root 151 Dec 26 10:41 /etc/ceph/ceph.client.pve.keyring

Ce que cela signifie : Il existe et seul root peut le lire, ce qui est normal sur Proxmox.

Décision : S’il manque sur un nœud, copiez-le de manière sécurisée ou recréez-le. Si les permissions sont trop permissives, corrigez-les ; les secrets négligés deviennent des incidents.

Task 4: Confirm the keyring actually contains the expected client name

cr0x@server:~$ sed -n '1,120p' /etc/ceph/ceph.client.pve.keyring
[client.pve]
	key = AQB7qMdnJg0aJRAA7i9fJvQW9x0o0Jr8mGmNqA==
	caps mon = "profile rbd"
	caps osd = "profile rbd pool=vmdata"

Ce que cela signifie : L’en-tête de section doit correspondre au nom d’utilisateur que Proxmox utilise (sans le préfixe client. dans storage.cfg).

Décision : Si le fichier indique [client.admin] mais que storage.cfg dit username pve, Proxmox échouera à s’authentifier.

Task 5: Test RBD access explicitly using the same identity as Proxmox

cr0x@server:~$ rbd -p vmdata ls --id pve --keyring /etc/ceph/ceph.client.pve.keyring
vm-101-disk-0
vm-102-disk-0
base-9000-disk-0

Ce que cela signifie : L’authentification fonctionne et l’utilisateur peut lister les images dans le pool.

Décision : Si la liste fonctionne mais que Proxmox échoue toujours à l’ouverture, le problème est probablement lié aux permissions spécifiques à l’image/fonctionnalités ou à un nom de pool/image différent de ce que vous pensez.

Task 6: Reproduce the open on a specific image (most useful for “error opening”)

cr0x@server:~$ rbd info vmdata/vm-101-disk-0 --id pve --keyring /etc/ceph/ceph.client.pve.keyring
rbd image 'vm-101-disk-0':
	size 100 GiB in 25600 objects
	order 22 (4 MiB objects)
	snapshot_count: 2
	id: 1a2b3c4d5e6f
	block_name_prefix: rbd_data.1a2b3c4d5e6f
	format: 2
	features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
	op_features:
	flags:
	create_timestamp: Tue Dec 24 09:12:33 2025
	access_timestamp: Tue Dec 24 09:12:33 2025
	modify_timestamp: Thu Dec 26 10:01:07 2025

Ce que cela signifie : Si cela réussit, l’« open » fonctionne au niveau RBD. Proxmox devrait pouvoir démarrer la VM à moins qu’il n’utilise d’autres identifiants/config.

Décision : Si cela échoue avec « permission denied », vos caps sont insuffisantes pour des opérations sur les métadonnées ou vous ciblez le mauvais pool.

Task 7: Confirm caps for the client user (don’t guess)

cr0x@server:~$ ceph auth get client.pve
[client.pve]
	key = AQB7qMdnJg0aJRAA7i9fJvQW9x0o0Jr8mGmNqA==
	caps mon = "profile rbd"
	caps osd = "profile rbd pool=vmdata"

Ce que cela signifie : Ceci est la vérité autoritaire à l’intérieur de Ceph (pas ce qui est copié dans un fichier keyring).

Décision : Si les caps n’incluent pas le pool cible, corrigez-les. Si la clé diffère du fichier keyring, mettez-le à jour partout.

Task 8: Check the Ceph config that Proxmox will implicitly use

cr0x@server:~$ cat /etc/ceph/ceph.conf
[global]
fsid = 2c3d1d5e-9a2e-4e2b-8a59-4f1c7c0c1c2f
mon_host = 10.10.0.11 10.10.0.12 10.10.0.13
auth_client_required = cephx
auth_cluster_required = cephx
auth_service_required = cephx

Ce que cela signifie : Un fsid erroné ou un mon_host manquant/incorrect peut pousser un nœud à parler au mauvais cluster ou à aucun cluster.

Décision : Si cela diffère entre nœuds, standardisez-le. Une divergence de configuration est la cause typique d’un « ça marchait hier » sans changement réel.

Task 9: Confirm monitor reachability from the failing node (routing/firewall)

cr0x@server:~$ for m in 10.10.0.11 10.10.0.12 10.10.0.13; do echo "== $m =="; nc -vz -w2 $m 3300; nc -vz -w2 $m 6789; done
== 10.10.0.11 ==
Connection to 10.10.0.11 3300 port [tcp/*] succeeded!
Connection to 10.10.0.11 6789 port [tcp/*] succeeded!
== 10.10.0.12 ==
Connection to 10.10.0.12 3300 port [tcp/*] succeeded!
Connection to 10.10.0.12 6789 port [tcp/*] succeeded!
== 10.10.0.13 ==
Connection to 10.10.0.13 3300 port [tcp/*] succeeded!
Connection to 10.10.0.13 6789 port [tcp/*] succeeded!

Ce que cela signifie : Ceph MON utilise 3300 (msgr2) et parfois 6789 (legacy). Vous voulez la connectivité au moins vers ce que votre cluster utilise.

Décision : Si ceci échoue sur un seul nœud, corrigez le pare-feu/routage/VLAN/MTU. Ne « corrigez » pas l’auth pour compenser un réseau défaillant.

Task 10: Pull the Proxmox task log that contains the failure

cr0x@server:~$ journalctl -u pvedaemon -S -2h | tail -n 40
Dec 26 10:50:14 pve3 pvedaemon[2211]:  starting task UPID:pve3:00008A1B:0002A1C4:676D7F46:qmstart:101:root@pam:
Dec 26 10:50:15 pve3 pvedaemon[1032]: command '/usr/bin/kvm -id 101 -name vm101 ... -drive file=rbd:vmdata/vm-101-disk-0:conf=/etc/pve/ceph.conf:id=pve:keyring=/etc/ceph/ceph.client.pve.keyring,if=none ...' failed: exit code 1
Dec 26 10:50:15 pve3 pvedaemon[1032]: TASK ERROR: start failed: error opening 'rbd:vmdata/vm-101-disk-0': (13) Permission denied

Ce que cela signifie : Cela confirme les arguments exacts que QEMU a utilisés, incluant id=pve et le chemin du keyring. C’est de l’or.

Décision : Refaire la commande RBD équivalente manuellement avec ces paramètres. Si cela échoue, ce n’est pas « un problème Proxmox ».

Task 11: Verify Proxmox is pointing QEMU at the right ceph.conf

cr0x@server:~$ ls -l /etc/pve/ceph.conf
-rw-r----- 1 root www-data 232 Dec 26 10:40 /etc/pve/ceph.conf

Ce que cela signifie : Proxmox peut générer/utiliser /etc/pve/ceph.conf. Cela peut différer de /etc/ceph/ceph.conf.

Décision : Si vos tests CLI utilisent /etc/ceph/ceph.conf mais QEMU utilise /etc/pve/ceph.conf, alignez-les ou testez avec le même --conf.

Task 12: Re-test with the same config file that QEMU used

cr0x@server:~$ rbd --conf /etc/pve/ceph.conf -p vmdata ls --id pve --keyring /etc/ceph/ceph.client.pve.keyring
rbd: listing images failed: (13) Permission denied

Ce que cela signifie : Cela précise la portée du problème. Votre succès précédent pouvait provenir d’une autre config (cluster différent, mon_host différent, réglages d’auth différents).

Décision : Inspectez /etc/pve/ceph.conf et corrigez-le ou cessez de l’utiliser. La cohérence bat l’ingéniosité.

Task 13: Confirm which Ceph cluster you’re talking to (fsid sanity check)

cr0x@server:~$ ceph --conf /etc/pve/ceph.conf fsid
2c3d1d5e-9a2e-4e2b-8a59-4f1c7c0c1c2f

Ce que cela signifie : Si le fsid diffère du cluster attendu, vous vous authentifiez contre le mauvais cluster Ceph (ou un ancien lab oublié).

Décision : Corrigez le fichier de config et redémarrez les services affectés ; n’ajoutez pas « juste plus de mons » à deux clusters en espérant le meilleur.

Task 14: Fix caps for a Proxmox RBD client (typical safe pattern)

cr0x@server:~$ ceph auth caps client.pve mon "profile rbd" osd "profile rbd pool=vmdata"
updated caps for client.pve

Ce que cela signifie : Vous accordez les permissions monitor appropriées et des permissions OSD scoppées sur le pool. C’est le comportement par défaut sensé pour des disques VM dans un pool.

Décision : Si vous avez plusieurs pools utilisés par Proxmox, ajoutez chaque pool explicitement. Évitez allow * sauf si vous aimez devoir l’expliquer plus tard.

Task 15: Update (or create) the keyring file consistently across nodes

cr0x@server:~$ ceph auth get client.pve -o /etc/ceph/ceph.client.pve.keyring
exported keyring for client.pve

Ce que cela signifie : Vous écrivez la clé/caps autoritaire sur le système de fichiers du nœud. Répétez sur chaque nœud ou distribuez de manière sécurisée.

Décision : Si un seul nœud avait un keyring obsolète, ceci élimine les échecs « error opening » spécifiques à un nœud.

Task 16: Validate Proxmox storage definition is healthy

cr0x@server:~$ pvesm status
Name       Type     Status           Total       Used        Available        %
ceph-rbd   rbd      active            0           0           0               0.00
local      dir      active        1966080    1126400          839680         57.29

Ce que cela signifie : Pour RBD, la capacité peut afficher 0 selon le réglage, mais le stockage doit être active.

Décision : S’il est inactive ou signale des erreurs, revérifiez les mon_host, username et chemin keyring dans storage.cfg.

Modèle d’authentification Ceph dans Proxmox : clients, keyrings, caps et où Proxmox cache les choses

Client names: the most common foot-gun is a one-word mismatch

Les utilisateurs Ceph s’appellent client.pve, client.admin, client.proxmox. Dans Proxmox storage.cfg, vous spécifiez souvent
username pve, que Proxmox interprète comme client.pve.

Les schémas de mismatch :

• Mismatch d’en-tête de keyring : le fichier contient [client.proxmox] mais Proxmox utilise pve. L’auth échoue.
• Clé obsolète : l’en-tête du fichier est correcte mais la clé provient d’une rotation antérieure. L’auth échoue.
• Caps inadéquates : l’auth réussit mais les opérations échouent au moment d’ouvrir/créer/snapshot.

Keyring location: shared config, local secrets

Le système de fichiers cluster de Proxmox donne envie de penser que tout dans votre configuration est répliqué. Ce n’est pas le cas.
/etc/pve/storage.cfg est répliqué. Votre fichier keyring sous /etc/ceph est juste un fichier local.

C’est pourquoi « fonctionne sur le nœud1, échoue sur le nœud3 » arrive si souvent :

• Vous avez ajouté le stockage via l’UI une fois, cela a mis à jour /etc/pve/storage.cfg sur tout le cluster.
• Vous avez copié le keyring sur un seul nœud (ou une version différente).
• Proxmox programme volontiers un démarrage de VM sur un nœud qui ne peut pas s’authentifier, et vous obtenez « error opening ».

Caps: “profile rbd” is the baseline, pool scoping is the safety rail

Pour l’utilisation RBD de Proxmox, le compromis opérationnel est :

• mon = "profile rbd" pour que le client puisse interroger les maps nécessaires et les métadonnées liées à RBD.
• osd = "profile rbd pool=<poolname>" pour que le client puisse accéder aux images d’un pool spécifique.

Si vous utilisez plusieurs pools (par ex. vmdata, fast-ssd, templates), vous pouvez soit :

• Accorder plusieurs clauses de pool (des clients séparés sont plus propres), ou
• Accepter des caps plus larges et assumer le compromis de sécurité.

Proxmox and /etc/pve/ceph.conf: the subtle config split

Proxmox peut maintenir une configuration Ceph sous /etc/pve/ceph.conf, et les processus QEMU lancés par Proxmox peuvent la référencer directement.
Pendant ce temps, vos commandes shell peuvent par défaut utiliser /etc/ceph/ceph.conf. Si ces fichiers diffèrent, vous perdrez des heures à « prouver » des faits contradictoires.

Choisissez une source de vérité et rendez-la cohérente. Si Proxmox utilise /etc/pve/ceph.conf, gardez-la correcte et synchronisée avec le cluster.

One reliability quote you should actually take seriously

Paraphrase d’une idée de John Allspaw (opérations/fiabilité) : « Les incidents viennent du travail normal et des décisions ordinaires, pas seulement d’incompétences rares. »

Erreurs fréquentes : symptôme → cause racine → correction

1) Symptom: Works on one node, fails on another with “error opening”

Cause racine : Fichier keyring absent ou différent sur le nœud en échec (ou ceph.conf différent).

Correction : Assurez-vous que le keyring et la configuration existent et correspondent sur chaque nœud.

cr0x@server:~$ sha256sum /etc/ceph/ceph.client.pve.keyring /etc/ceph/ceph.conf /etc/pve/ceph.conf
e1d0c0d2f0b8d66c3f2f5b7a20b3fcb0a1f6e42a2bfafbfcd1c4e2a8fcbcc3af  /etc/ceph/ceph.client.pve.keyring
9b1f0c3c4f74d5d5c22d5e4e2d0a2a77bff2f5bd3d92a0e7db6c2f4f122c8f10  /etc/ceph/ceph.conf
9b1f0c3c4f74d5d5c22d5e4e2d0a2a77bff2f5bd3d92a0e7db6c2f4f122c8f10  /etc/pve/ceph.conf

Décision : Hashs différents entre nœuds ? Stop. Standardisez. Ne continuez pas à déboguer les couches supérieures.

2) Symptom: “(13) Permission denied” when starting VM or creating disk

Cause racine : Caps trop restrictives pour ce que Proxmox tente de faire (create, snapshot, clone), ou mauvaise portée pool.

Correction : Mettez à jour les caps pour inclure le pool correct et profile rbd. Vérifiez avec un test rbd create.

cr0x@server:~$ rbd create vmdata/caps-test --size 64M --id pve --keyring /etc/ceph/ceph.client.pve.keyring
rbd: create error: (13) Permission denied

Décision : Cela confirme que c’est les caps, pas une configuration VM instable. Corrigez les caps, retestez la création et supprimez l’image de test.

3) Symptom: “no keyring found” or “failed to load keyring” in logs

Cause racine : Mauvais chemin keyring dans storage.cfg, ou le fichier existe mais a des permissions/contexts SELinux/AppArmor incorrects (rare sur Proxmox par défaut).

Correction : Corrigez le chemin ; utilisez un chemin absolu ; mettez 0600 root:root.

4) Symptom: “error connecting to the cluster” or MON connection timeouts

Cause racine : IPs de moniteurs erronées dans storage.cfg/ceph.conf, pare-feu bloquant 3300/6789, ou mismatch DNS/IPv6.

Correction : Utilisez des adresses de moniteurs stables ; validez la connectivité ; évitez les noms d’hôte sauf si le DNS est réellement fiable.

5) Symptom: RBD list works, but open fails for some images

Cause racine : L’image est dans un autre pool, ou les fonctionnalités de l’image exigent des opérations que vos caps bloquent, ou le nom d’image est erroné (typo, référence obsolète après renommage).

Correction : Vérifiez pool/image exacts ; exécutez rbd info et rbd snap ls en utilisant la même identité que Proxmox.

6) Symptom: After rotating keys, old VMs won’t start

Cause racine : Un nœud a encore l’ancien keyring ; Proxmox y planifie des starts ; vous obtenez « error opening ».

Correction : Déployez les mises à jour de keyring de façon atomique sur tous les nœuds, puis validez avec un petit jeu de tests start/migrate.

Blague n°2 : La rotation de clés, c’est comme utiliser du fil dentaire — tout le monde admet que c’est bien, et presque personne ne le fait selon le calendrier annoncé.

Trois mini-histoires d’entreprise issues du terrain

Mini-story 1: The incident caused by a wrong assumption

Une entreprise de taille moyenne exploitait un cluster Proxmox avec Ceph RBD pour les disques VM. Ils ont ajouté un nouveau nœud, l’ont joint au cluster Proxmox et l’ont considéré comme terminé.
Le lendemain matin, une maintenance de routine a déclenché une série de migrations de VM vers le nouveau nœud.

La moitié des VMs migrées ne revenaient pas. Proxmox affichait le même message laconique : « error opening ».
La santé Ceph était bonne. Le stockage était défini dans /etc/pve/storage.cfg, donc l’équipe a supposé « la config de stockage s’est répliquée ; donc l’accès au stockage aussi ».

Cette hypothèse était la cause entière de l’incident. Le nouveau nœud n’avait pas /etc/ceph/ceph.client.pve.keyring. Les nœuds existants l’avaient.
L’UI Proxmox a empiré la situation en étant cohérente : même nom de stockage, même pool, mêmes moniteurs, même message d’échec.

La correction fut peu glamour : distribuer le keyring à chaque nœud, vérifier que les hashes correspondent, puis relancer les starts.
L’action de postmortem fut encore plus ennuyeuse : une checklist d’ajout de nœud avec une étape « keyrings Ceph présents et vérifiés ».

Mini-story 2: The optimization that backfired

Une autre organisation voulait réduire le rayon d’impact et a créé des utilisateurs Ceph séparés pour différents clusters Proxmox en minimisant agressivement les caps.
Bonne intention. Puis ils ont été trop loin : caps en lecture seule pour un utilisateur que Proxmox utilisait aussi pour des opérations de snapshot et de templating par clone.

Tout semblait bien pendant des semaines parce que les I/O runtime de VM fonctionnaient la plupart du temps — jusqu’à ce que la pipeline de templates tourne à grande échelle.
Soudain, les tâches de provisioning ont commencé à échouer avec « error opening » et « permission denied », et l’équipe a cherché du réseau car les échecs étaient intermittents et corrélés dans le temps.

La vraie cause était que certaines opérations nécessitaient des écritures métadonnées (création de snapshot, clone, flatten) que leurs caps bloquaient.
Les échecs étaient périodiques car ces opérations l’étaient.

Ils ont corrigé cela en séparant les responsabilités : un utilisateur Ceph pour « I/O runtime VM » avec accès pool strictement scoppé,
un autre pour les tâches de gestion d’images pilotées par l’automatisation, avec permissions supplémentaires et contrôles opérationnels plus stricts.
Le principe du moindre privilège a survécu. Il fallait juste l’aligner sur les workflows réels, pas sur des souhaits.

Mini-story 3: The boring but correct practice that saved the day

Une équipe de services financiers avait une habitude presque comique : chaque nœud avait un petit script local validant quotidiennement l’accès client Ceph.
Il exécutait ceph -s, rbd ls et rbd info contre une image connue, en utilisant les mêmes identifiants que Proxmox.
Il consignait les résultats localement et exposait aussi une métrique simple « ok/fail ».

Un après-midi, un admin Ceph a tourné les clés pendant une fenêtre de changement. Le changement était correct, les caps étaient bons et le cluster Ceph est resté sain.
Mais un nœud Proxmox a raté la mise à jour du keyring à cause d’une défaillance temporaire de gestion de configuration.

Leur validation quotidienne l’a détecté en quelques heures — avant qu’une migration de maintenance n’amène des charges sur le nœud défaillant.
Au lieu d’une panne, ils ont eu un ticket : « Node pve7 fails RBD open using client.pve. » La remédiation fut une synchronisation du keyring et un retest.

Rien d’héroïque. Personne n’a été réveillé. C’est à ça que ressemble l’ingénierie de fiabilité les jours calmes : moins d’histoires à raconter.

Listes de contrôle / plan pas à pas

Checklist A: When a VM fails to start with “error opening”

1. Dépêchez-vous depuis le nœud en échec, récupérez l’erreur exacte et les paramètres dans les logs (journalctl -u pvedaemon).
2. Extrayez id=, keyring=, pool, nom d’image et le chemin conf=.
3. Exécutez rbd --conf ... info pool/image --id ... --keyring ....
4. Si l’auth échoue : vérifiez l’existence du keyring, son exactitude et l’en-tête du nom client.
5. Si « permission denied » : inspectez les caps et le scoping du pool ; corrigez les caps ; retestez.
6. Si la connectivité aux moniteurs échoue : validez les ports 3300/6789 ; vérifiez mon_host et le routage/MTU.
7. Une fois corrigé, relancez le démarrage de la VM et vérifiez la lecture/écriture.

Checklist B: Adding a new Proxmox node to a Ceph-backed cluster

1. Installez les paquets clients Ceph requis pour votre version de Proxmox.
2. Copiez /etc/ceph/ceph.conf (ou assurez-vous que /etc/pve/ceph.conf est correct et utilisé de manière cohérente).
3. Copiez les keyrings requis : typiquement /etc/ceph/ceph.client.pve.keyring.
4. Vérifiez les permissions des fichiers : 0600 root:root pour les keyrings.
5. Exécutez : ceph -s et rbd -p <pool> ls --id pve --keyring ....
6. Ce n’est qu’après cela que vous autorisez les migrations/HA sur ce nœud.

Checklist C: Safe-ish key rotation for Proxmox RBD clients

1. Créez ou mettez à jour l’entrée d’auth Ceph (ceph auth get-or-create / ceph auth caps), en gardant le scoping pool correct.
2. Exportez le fichier keyring mis à jour.
3. Distribuez le keyring à tous les nœuds Proxmox (atomiquement si possible).
4. Vérifiez que les hashes correspondent entre nœuds.
5. Exécutez des tests d’ouverture RBD depuis chaque nœud en utilisant le même --conf que QEMU.
6. Faites un canari : démarrez une VM par nœud, faites une migration, créez un snapshot si vous en utilisez.
7. Ce n’est qu’après cela que vous pouvez considérer la rotation comme « terminée ».

Commands that help automate the checklist validation

cr0x@server:~$ rbd --conf /etc/pve/ceph.conf info vmdata/vm-101-disk-0 --id pve --keyring /etc/ceph/ceph.client.pve.keyring
rbd image 'vm-101-disk-0':
	size 100 GiB in 25600 objects
	order 22 (4 MiB objects)
	snapshot_count: 2
	id: 1a2b3c4d5e6f
	format: 2
	features: layering, exclusive-lock, object-map, fast-diff, deep-flatten
	op_features:
	flags:
	create_timestamp: Tue Dec 24 09:12:33 2025
	access_timestamp: Tue Dec 24 09:12:33 2025
	modify_timestamp: Thu Dec 26 10:01:07 2025

Décision : Si cela fonctionne sur chaque nœud, vous avez éliminé la plupart des causes d’auth/keyring de « error opening ».

FAQ

1) Why does Proxmox show “error opening” instead of the real Ceph error?

Parce que l’erreur remonte à travers QEMU/librbd et est résumée. La raison détaillée se trouve souvent dans des lignes de journalctl montrant
« permission denied », « no such file » ou des erreurs de connexion. Récupérez toujours les logs du nœud qui a échoué.

2) I can run ceph -s successfully, so why does Proxmox fail?

Votre shell peut utiliser un fichier de config différent (/etc/ceph/ceph.conf) et une clé différente (client.admin via le keyring par défaut).
Proxmox pourrait utiliser /etc/pve/ceph.conf et client.pve. Testez en utilisant le même --conf, --id et --keyring que ceux indiqués dans les logs Proxmox.

3) Can I just use client.admin to make it go away?

Vous pouvez, et ça « marche », mais c’est une mauvaise habitude. Cela augmente le rayon d’impact et complique les audits. Utilisez un client dédié avec des caps scoppées au pool.
Réservez client.admin aux tâches administratives, pas aux I/O de VM de routine.

4) What are the minimum caps for Proxmox RBD usage?

Typiquement : mon "profile rbd" et osd "profile rbd pool=<pool>". Si vous utilisez des workflows additionnels (snapshots, clones, flatten),
vous voudrez généralement conserver profile rbd, mais assurez-vous que votre cluster et vos clients supportent les opérations nécessaires. Validez en testant l’opération avec la même identité.

5) Why does it fail only during migration or snapshot?

Parce que les migrations et les snapshots sollicitent des appels API différents. Lister des images n’est pas la même chose qu’ouvrir une image avec certaines fonctionnalités, créer des snapshots ou cloner.
Si cela échoue pour ces opérations, suspectez d’abord un mismatch de caps.

6) Where does Proxmox store Ceph secrets?

Proxmox stocke la définition du stockage dans /etc/pve/storage.cfg. La clé elle-même est typiquement dans un fichier keyring sous /etc/ceph référencé par chemin.
Certaines configurations intègrent les secrets différemment, mais le modèle « fichier keyring local au nœud » est courant et explique précisément pourquoi des mismatches nœud-à-nœud surviennent.

7) How do I tell if it’s a monitor connectivity problem versus auth?

Si vous voyez des timeouts et « error connecting to the cluster », validez d’abord la reachabilité réseau vers les ports MON (3300/6789) et confirmez mon_host.
Si vous voyez rapidement « permission denied », les moniteurs sont joignables et l’auth/caps est le coupable probable.

8) Do I need to restart Proxmox services after fixing keyrings or caps?

Souvent non ; les nouvelles tâches prennent en compte le fichier keyring mis à jour. Mais si vous avez changé quel fichier de config est utilisé ou mis à jour des définitions de stockage,
redémarrer pvedaemon et retenter la tâche peut supprimer un état obsolète. Restez ciblé ; ne redémarrez pas des nœuds pour faire de la thérapie.

9) What’s the fastest safe test to validate a fix?

Exécutez rbd info pool/image en utilisant le même --conf, --id et --keyring que QEMU utilise, depuis le nœud qui a échoué.
Ensuite démarrez une VM qui utilise cette image. Si vous dépendez de snapshots/clones, testez-en un aussi.

10) Could this be a Ceph bug or data corruption?

Cela peut arriver, mais si le cluster est sain et que l’erreur est « permission denied » ou « keyring not found », ce n’est pas de la corruption.
Commencez par l’auth/config ; 95% des incidents « error opening » sont des coupures auto-infligées.

Conclusion : prochaines étapes à faire aujourd’hui

Si vous voulez que « error opening » cesse d’être un personnage récurrent dans vos rotations d’astreinte, faites trois choses :

1. Standardisez quel fichier de config QEMU utilise (/etc/pve/ceph.conf vs /etc/ceph/ceph.conf) et harmonisez-les sur tous les nœuds.
2. Utilisez un client Ceph dédié (par ex. client.pve) avec des caps profile rbd scoppées par pool. Arrêtez d’utiliser client.admin pour les I/O VM de routine.
3. Faites des keyrings un artefact de déploiement de première classe : distribuez-les sur chaque nœud, vérifiez les hashes et validez l’accès avec un test automatisé rbd info.

La bonne nouvelle : une fois que vous traitez les keyrings et les caps comme de la configuration de production (et non comme du savoir tribal), Ceph devient prévisiblement ennuyeux. C’est l’objectif.

Plan de diagnostic rapide (vérifiez ceci en premier)

Si vous n’avez que cinq minutes avant que quelqu’un d’important demande pourquoi il ne peut pas publier le billet du PDG, faites ceci dans l’ordre. Cette séquence trouve rapidement le goulot d’étranglement parce qu’elle suit le chemin d’authentification : navigateur → cache en périphérie → proxy inverse → PHP → base de données.

1) Confirmez si les cookies sont définis et renvoyés

• Vérifier : Le navigateur reçoit-il un Set-Cookie après l’envoi POST des identifiants ?
• Puis : La requête suivante vers /wp-admin/ inclut-elle ce cookie ?
• Pourquoi : Une « boucle » de connexion signifie souvent que WordPress dit « je n’ai pas reçu de cookie d’auth valide », donc il vous renvoie.

2) Confirmez que l’URL canonique et le schéma sont cohérents

• Vérifier : Basculez-vous entre http et https ou entre www et le domaine apex ?
• Pourquoi : Les cookies sont limités par des règles de domaine + schéma. Si votre POST de connexion a lieu sur un hôte/schéma et que l’admin charge sur un autre, votre cookie peut ne pas s’appliquer.

3) Contournez les caches et couches de sécurité

• Vérifier : Un cache en périphérie, un WAF, un plugin « performance » ou un proxy inverse met-il en cache wp-login.php ou altère-t-il les en-têtes ?
• Pourquoi : Les points d’entrée d’authentification sont dynamiques. Les mettre en cache, c’est comme étiqueter votre porte d’entrée « parfois ouverte ».

4) Désactivez les plugins en sécurité, puis les thèmes

• Vérifier : Le problème disparaît-il lorsque les plugins sont désactivés ?
• Pourquoi : Un plugin « sécurité » ou de « consentement cookie » peut casser l’auth de façon créative.

5) Validez les sessions côté serveur, PHP et l’écriture DB

• Vérifier : PHP écrit-il des sessions ? La base de données est-elle accessible en écriture ? Y a-t-il des erreurs fatales ?
• Pourquoi : Si WordPress ne peut pas définir l’état lié à l’auth (ou si vous avez des bizarreries d’object cache), il ne peut pas vous maintenir connecté.

Comment fonctionne réellement le flux de connexion WordPress (pour cesser de chasser des fantômes)

La connexion WordPress repose sur les cookies. Quand vous soumettez des identifiants à wp-login.php, WordPress :

1. Valide le nom d’utilisateur/mot de passe (ou SSO) et vérifie le statut/capacités de l’utilisateur.
2. Émet des cookies d’authentification : typiquement wordpress_logged_in_* et wordpress_sec_* (les noms varient selon le hash/salt et les réglages).
3. Redirige (302) vers /wp-admin/ ou vers une cible.
4. À la requête suivante, WordPress lit les cookies, les valide avec les salts et l’enregistrement utilisateur, puis autorise l’accès ou redirige de nouveau vers la connexion.

Une « boucle de connexion » signifie une des trois choses :

• Le cookie n’a jamais été défini (bloqué, supprimé, réponse mise en cache, mauvais en-têtes).
• Le cookie a été défini mais jamais renvoyé (mismatch de domaine, flag secure, mismatch de chemin, problèmes SameSite dans certains flux).
• Le cookie a été envoyé mais rejeté (salts incorrects après migration, incohérence DB/object cache, dérive d’heure, méta utilisateur étrange, plugin d’auth personnalisé).

Un mantra pratique : traitez ceci comme du débogage de systèmes distribués. Il y a plusieurs couches, et n’importe quelle couche peut « utilement » réécrire votre requête en échec.

Paraphrase d’une idée d’un poids lourd de la fiabilité : paraphrase — « L’espoir n’est pas une stratégie. » — attribué à Gene Kranz (mentalité des opérations de mission).

Blague #1 : Une boucle de connexion WordPress est le seul cardio que certains d’entre nous font dans une journée de travail. Ce n’est pas un bon programme de bien-être.

Faits intéressants et contexte historique (court, utile)

• Fait 1 : WordPress utilise une authentification basée sur les cookies depuis les premières versions ; les noms de cookies incluent des hachages dérivés des réglages du site et des salts de sécurité, d’où les migrations qui peuvent « casser » les connexions.
• Fait 2 : Le point d’accès wp-login.php est l’une des URL publiques les plus ciblées sur Internet ; de nombreuses piles d’hébergement ajoutent des règles WAF ou de limitation de débit qui peuvent interférer subtilement avec les connexions légitimes.
• Fait 3 : L’espace d’administration repose beaucoup sur les redirections (hôte canonique, enforcement SSL, emplacement admin). Une mauvaise configuration de redirection produit des boucles plus vite que presque n’importe quel autre bug.
• Fait 4 : Les navigateurs ont durci la gestion des cookies au fil du temps (notamment les paramètres SameSite), ce qui peut casser des flux de connexion impliquant des POSTs intersites ou des callbacks d’IdP externes si vous ne définissez pas correctement les cookies.
• Fait 5 : Beaucoup de CDN « tout mettre en cache » proposaient à l’origine des réglages naïfs ; les configurations modernes excluent généralement wp-admin et wp-login.php, mais cela reste fréquemment mal configuré.
• Fait 6 : WordPress stocke les URL canoniques (home et siteurl) dans la base de données, mais permet des overrides via wp-config.php. Les conflits entre les deux sont un générateur classique de boucles.
• Fait 7 : Un proxy inverse (load balancer, CDN, ingress) change la signification de « est-ce HTTPS ? » à moins que les en-têtes forwardés soient corrects ; WordPress utilise cela pour décider des flags de cookie sécurisé et des cibles de redirection.
• Fait 8 : Le cache d’objets (Redis/Memcached) peut rendre l’authentification « hantée » lorsque des valeurs obsolètes persistent après des déploiements ou lorsque plusieurs serveurs applicatifs ne sont pas alignés sur les salts/config.

Les vraies causes de la boucle de connexion (classées par fréquence)

1) Mismatch d’URL, d’hôte ou de HTTPS (le tapis roulant des redirections canoniques)

WordPress veut une URL unique pour le site. Si votre pile sert plusieurs variantes—http, https, avec/sans www, peut-être un domaine alternatif—le POST de connexion peut se produire sur une variante, mais la redirection vers /wp-admin/ aboutit sur une autre. Les cookies ne voyagent pas comme vous le souhaiteriez.

Déclencheurs courants :

• home et siteurl définis différemment (un en http, l’autre en https).
• HTTPS forcé au niveau du load balancer, mais WordPress croit être en HTTP.
• Règles de redirection dans Nginx/Apache qui se battent avec les redirections canoniques de WordPress.

2) Cookies bloqués, supprimés ou mal scoppés

Si les cookies ne sont pas définis ou renvoyés, WordPress ne peut pas vous garder connecté. Causes :

• Proxy/CDN qui supprime les en-têtes Set-Cookie pour « rendre la réponse cachable ».
• Mismatch domaine/chemin du cookie après un changement de domaine.
• Cookies sécurisés sur HTTPS qui ne fonctionnent pas parce que WordPress ne détecte pas HTTPS (il définit donc des cookies non sécurisés, puis on redirige vers HTTPS et ils ne sont pas acceptés).
• Plugins de consentement cookie ou de sécurité malveillants qui réécrivent les en-têtes.

3) Cache (edge, plugin, serveur) qui met en cache la mauvaise chose

Il est impressionnant de voir combien de configurations « performance » tentent de mettre en cache les pages de connexion. Si la réponse de connexion ou la redirection est mise en cache, différents utilisateurs commencent à partager le même état cassé. De plus, si un cache supprime les cookies, l’authentation casse de façon invisible.

4) Conflits plugins/thèmes, surtout sécurité et SSO

Les plugins de sécurité, les ponts SSO, les plugins 2FA et les packs « désactiver XML-RPC » s’accrochent souvent aux filtres d’authentification. Une mauvaise mise à jour peut introduire une règle de redirection qui ne se termine jamais.

5) Salts/clés cassés après migration ou dérive de configuration entre serveurs

WordPress signe les cookies d’auth avec les salts et clés dans wp-config.php. Si vous les changez, les cookies existants deviennent invalides (ce qui est normal), mais si vous avez plusieurs serveurs applicatifs avec des salts différents, les utilisateurs se déconnectent ou font des boucles selon le backend qui les sert.

6) Dérive d’heure ou bizarrerie de terminaison TLS

Les cookies d’auth contiennent une expiration. Si l’heure système est incorrecte (dérive VM, conteneur, NTP cassé), les cookies peuvent sembler immédiatement expirés. Moins fréquent, mais spectaculaire quand ça arrive.

7) Échecs d’écriture DB ou système de fichiers et fatales subtiles

L’auth WordPress dépend de lectures/écritures DB et de l’exécution complète de PHP. Si PHP fait un fatal après avoir défini une redirection, ou si la DB est en lecture seule, vous pouvez vous retrouver dans une boucle sans erreur utilisateur évidente. Vérifiez les logs sérieusement.

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

Voici des tâches pratiques que vous pouvez lancer sur un hôte Linux typique. Ajustez les chemins si votre distribution ou layout diffère. Chaque tâche inclut : commande, ce que signifie la sortie, et la décision suivante.

Task 1: Reproduire la chaîne de redirections depuis le serveur

cr0x@server:~$ curl -I -L https://example.com/wp-admin/ | sed -n '1,40p'
HTTP/2 302
location: https://example.com/wp-login.php?redirect_to=https%3A%2F%2Fexample.com%2Fwp-admin%2F&reauth=1
set-cookie: wp-wpml_current_language=en; path=/
server: nginx

HTTP/2 200
content-type: text/html; charset=UTF-8
cache-control: no-store, no-cache, must-revalidate, max-age=0

Ce que cela signifie : Un seul 302 vers la page de connexion est normal si vous n’êtes pas authentifié. Si vous voyez des 302 répétés qui rebondissent entre wp-login.php et wp-admin, vous avez une boucle.

Décision : Si la boucle apparaît ici sans navigateur, vous avez affaire à une logique de redirection côté serveur ou à un problème d’URL canonique — ce n’est pas « mon navigateur qui est bizarre ».

Task 2: Vérifier si les réponses de la page de connexion sont mises en cache par un proxy/CDN

cr0x@server:~$ curl -I https://example.com/wp-login.php | egrep -i 'cache|age|cf-cache-status|x-cache|via|set-cookie'
cache-control: no-store, no-cache, must-revalidate, max-age=0
set-cookie: wordpress_test_cookie=WP%20Cookie%20check; path=/; secure; HttpOnly

Ce que cela signifie : Vous voulez no-store ou un en-tête de cache similaire restrictif. Si vous voyez des en-têtes comme x-cache: HIT ou un statut de cache CDN montrant un hit, c’est suspect.

Décision : Si mis en cache, configurez le CDN/proxy inverse pour bypasser le cache pour /wp-login.php et /wp-admin/*, et pour ne jamais supprimer Set-Cookie.

Task 3: Confirmer les URL canoniques WordPress (WP-CLI)

cr0x@server:~$ cd /var/www/html
cr0x@server:/var/www/html$ wp option get home
https://example.com
cr0x@server:/var/www/html$ wp option get siteurl
http://example.com

Ce que cela signifie : Ce mismatch (https vs http) est un déclencheur classique de boucle.

Décision : Alignez-les sur le même schéma et hôte. Choisissez une URL canonique et tenez-vous-y.

Task 4: Corriger home et siteurl en sécurité

cr0x@server:/var/www/html$ wp option update home 'https://example.com'
Success: Updated 'home' option.
cr0x@server:/var/www/html$ wp option update siteurl 'https://example.com'
Success: Updated 'siteurl' option.

Ce que cela signifie : WordPress générera des cookies/redirections selon ces valeurs.

Décision : Retestez la connexion. Si la boucle persiste, passez à la détection HTTPS et aux en-têtes proxy.

Task 5: Vérifier si WordPress croit que la requête est HTTPS (derrière un proxy)

cr0x@server:~$ grep -R "HTTPS" -n /var/www/html/wp-config.php | head
# (no output)

Ce que cela signifie : Aucune forçage explicite de HTTPS au niveau de l’application. C’est acceptable si vos en-têtes proxy sont corrects, mais risqué sinon.

Décision : Si vous terminez TLS au load balancer et que vous forwardez vers PHP en HTTP, assurez-vous que X-Forwarded-Proto est défini et pris en compte, ou définissez conditionnellement $_SERVER['HTTPS']='on' dans wp-config.php.

Task 6: Vérifier les en-têtes forwardés dans Nginx (coupable fréquent)

cr0x@server:~$ sudo nginx -T 2>/dev/null | egrep -n "X-Forwarded-Proto|X-Forwarded-For|fastcgi_param"
112:    proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;
113:    proxy_set_header X-Forwarded-Proto $scheme;
210:    fastcgi_param HTTPS $https if_not_empty;

Ce que cela signifie : Si vous êtes derrière un proxy, $scheme peut être http entre le proxy et l’origine même quand le client utilisait HTTPS. Cela fait croire à WordPress qu’il est en HTTP.

Décision : Définissez le proto forwardé correctement depuis la périphérie (LB → origine). Souvent, vous voulez que Nginx fasse confiance à X-Forwarded-Proto de votre LB et le passe à PHP.

Task 7: Inspecter les en-têtes de réponse pour des cookies manquants/réécrits

cr0x@server:~$ curl -s -D - https://example.com/wp-login.php -o /dev/null | sed -n '1,40p'
HTTP/2 200
date: Fri, 27 Dec 2025 11:20:00 GMT
content-type: text/html; charset=UTF-8
set-cookie: wordpress_test_cookie=WP%20Cookie%20check; path=/; secure; HttpOnly

Ce que cela signifie : Vous recevez au moins un Set-Cookie pour le cookie de test. Après avoir posté les identifiants, vous devriez voir aussi les cookies d’auth.

Décision : Si Set-Cookie disparaît uniquement sur POST, suspectez des règles WAF, du cache ou un plugin qui plante en cours de réponse.

Task 8: Poster vers wp-login.php et vérifier les cookies d’auth (simulation serveur)

cr0x@server:~$ curl -s -D - -o /dev/null -X POST https://example.com/wp-login.php \
  -d "log=admin&pwd=wrongpassword&wp-submit=Log+In&redirect_to=https%3A%2F%2Fexample.com%2Fwp-admin%2F&testcookie=1" | egrep -i 'HTTP/|set-cookie:|location:'
HTTP/2 200
set-cookie: wordpress_test_cookie=WP%20Cookie%20check; path=/; secure; HttpOnly

Ce que cela signifie : Avec de mauvais identifiants vous n’obtiendrez pas de cookies d’auth ; vous devez obtenir un 200 avec la page d’erreur.

Décision : Si même des identifiants corrects ne produisent pas de cookies d’auth (vous verriez des lignes set-cookie supplémentaires), passez aux logs PHP et à l’isolation des plugins.

Task 9: Vérifier PHP-FPM et les logs web pour des fatales liées à l’auth

cr0x@server:~$ sudo tail -n 80 /var/log/php8.2-fpm.log
[27-Dec-2025 11:18:32] WARNING: [pool www] child 2147 said into stderr: "PHP Warning:  Cannot modify header information - headers already sent by (output started at /var/www/html/wp-content/plugins/foo/foo.php:12) in /var/www/html/wp-includes/pluggable.php on line 1428"

Ce que cela signifie : « Headers already sent » peut empêcher la définition des cookies. Pas de cookies, pas de connexion. Ce fichier de plugin a sorti quelque chose (même des espaces), avant que WordPress n’ait pu définir les en-têtes.

Décision : Désactivez le plugin fautif. Puis corrigez-le proprement (ou remplacez-le) car cela reviendra.

Task 10: Désactiver les plugins sans passer par wp-admin

cr0x@server:~$ cd /var/www/html
cr0x@server:/var/www/html$ wp plugin deactivate --all
Success: Deactivated 14 of 14 plugins.

Ce que cela signifie : Vous avez retiré l’interférence des plugins de l’équation.

Décision : Retestez la connexion. Si c’est corrigé, réactivez les plugins un par un pour trouver le coupable (oui, fastidieux ; oui, plus rapide que deviner).

Task 11: Basculer vers un thème par défaut pour éliminer les hacks d’auth au niveau thème

cr0x@server:/var/www/html$ wp theme list
+----------------+----------+--------+---------+
| name           | status   | update | version |
+----------------+----------+--------+---------+
| twentytwentyfour | inactive | none   | 1.2     |
| corp-theme     | active   | none   | 4.8.1   |
+----------------+----------+--------+---------+
cr0x@server:/var/www/html$ wp theme activate twentytwentyfour
Success: Switched to 'Twenty Twenty-Four' theme.

Ce que cela signifie : Si votre thème a des redirections personnalisées de connexion, des hooks SSO, ou un buffering de sortie cassé, cela l’isole.

Décision : Si cela corrige la boucle, votre « beau thème corporate » est maintenant un incident de production. Traitez-le en conséquence.

Task 12: Vérifier la dérive de configuration des salts/keys entre serveurs (diff rapide)

cr0x@server:~$ sudo egrep "AUTH_KEY|SECURE_AUTH_KEY|LOGGED_IN_KEY|NONCE_KEY" -n /var/www/html/wp-config.php
54:define('AUTH_KEY',         '...a...');
55:define('SECURE_AUTH_KEY',  '...b...');
56:define('LOGGED_IN_KEY',    '...c...');
57:define('NONCE_KEY',        '...d...');

Ce que cela signifie : Ces valeurs doivent être identiques sur tous les serveurs applicatifs derrière le load balancer.

Décision : Si vous avez plusieurs origines, vérifiez qu’elles correspondent partout. Si non, corrigez le déploiement pour que la configuration soit cohérente.

Task 13: Vérifier l’heure système et la synchro NTP (sanité des expirations de cookies)

cr0x@server:~$ timedatectl
               Local time: Fri 2025-12-27 11:20:44 UTC
           Universal time: Fri 2025-12-27 11:20:44 UTC
                 RTC time: Fri 2025-12-27 11:20:44
                Time zone: Etc/UTC (UTC, +0000)
System clock synchronized: yes
              NTP service: active
          RTC in local TZ: no

Ce que cela signifie : Si les horloges sont décalées ou NTP inactif, les cookies peuvent sembler instantanément expirés.

Décision : Si non synchronisé, corrigez l’heure d’abord. Ne déboguez pas l’auth sur un serveur qui ne sait pas quelle heure il est.

Task 14: Vérifier la santé du cache d’objets Redis (si utilisé)

cr0x@server:~$ redis-cli ping
PONG
cr0x@server:~$ redis-cli info | egrep "used_memory_human|maxmemory_human|evicted_keys"
used_memory_human:312.45M
maxmemory_human:512.00M
evicted_keys:18422

Ce que cela signifie : Beaucoup d’évictions peuvent causer des comportements étranges. Pas toujours des boucles de connexion, mais cela peut déstabiliser des valeurs caches liées à l’auth dans certaines configurations.

Décision : Si les évictions sont élevées, augmentez la mémoire du cache ou réduisez l’usage. Confirmez aussi que votre plugin d’object cache est adapté et configuré correctement.

Task 15: Confirmer que la DB est écrivable et ne retourne pas d’erreurs

cr0x@server:~$ mysql -N -e "SHOW GLOBAL VARIABLES LIKE 'read_only';"
read_only	OFF

Ce que cela signifie : Si la DB est en lecture seule (ou en échec), WordPress peut se comporter de façon imprévisible, surtout pour les sessions/plugins qui écrivent la méta utilisateur.

Décision : Si read_only est ON de façon inattendue, corrigez l’état de réplication/basculement ou pointez WordPress vers le primaire correct.

Task 16: Valider que wp-content n’est pas en lecture seule (mises à jour et certains flux d’auth)

cr0x@server:~$ sudo -u www-data test -w /var/www/html/wp-content && echo "wp-content writable" || echo "wp-content NOT writable"
wp-content writable

Ce que cela signifie : Toutes les boucles de connexion ne concernent pas les écritures de fichiers, mais les problèmes de permissions accompagnent souvent des déploiements cassés et des problèmes « headers already sent ».

Décision : Si non écrivable et que votre stack l’attend, corrigez la propriété/permissions ; si votre stack interdit les écritures, assurez-vous que les plugins/thèmes n’essaient pas d’écrire à l’exécution d’une manière qui casse les réponses.

Erreurs courantes : symptôme → cause racine → correctif

Symptôme : Mot de passe correct, redirection instantanée vers wp-login.php, sans erreur

Cause racine : Cookies non stockés ou non renvoyés (mismatch de domaine, flag secure, « headers already sent », proxy supprimant Set-Cookie).

Correctif : Vérifiez la cohérence home/siteurl, inspectez les en-têtes de réponse pour Set-Cookie, éliminez les warnings PHP « headers already sent », et désactivez les caches sur login/admin.

Symptôme : Ça marche sur un navigateur/appareil, échoue sur un autre

Cause racine : Différences de politique de cookie (comportement SameSite, blocage des cookies tiers), cookies obsolètes, ou extension de navigateur modifiant les requêtes.

Correctif : Testez dans un profil propre/en navigation privée, videz les cookies du site, assurez-vous que votre flux de connexion est en première partie (pas de POST inter-site), et confirmez HTTPS et l’hôte canonique.

Symptôme : Ça marche en accès direct sur l’origine, échoue via CDN/WAF

Cause racine : Cache en bordure des endpoints d’auth/admin, pages de challenge WAF, suppression d’en-têtes, ou protection anti-bot traitant des humains comme des bots.

Correctif : Contournez le bord pour confirmer, puis ajoutez des règles de bypass explicites. Éventuellement allowliste des plages IP admin si approprié et assurez-vous que les pages de challenge n’affectent pas les POSTs sur wp-login.php.

Symptôme : N’échoue que lorsque « Forcer HTTPS » ou HSTS est activé

Cause racine : WordPress ne détecte pas HTTPS derrière un proxy ; il définit des cookies ou redirections de manière incohérente.

Correctif : Corrigez les en-têtes forwardés et/ou activez la détection HTTPS dans wp-config.php. Assurez-vous qu’une seule couche effectue la redirection canonique.

Symptôme : Déconnexions aléatoires / boucles en environnement load-balanced

Cause racine : Différence de salts/keys entre serveurs applicatifs, wp-config.php incohérent, ou absence de sessions persistantes (sticky sessions) requises par un plugin.

Correctif : Rendre la configuration immuable et identique sur tous les nœuds. Évitez la dépendance aux sticky sessions ; si inévitable, configurez-les explicitement et documentez pourquoi.

Symptôme : La connexion fonctionne, mais wp-admin déconnecte immédiatement après quelques clics

Cause racine : Plugin de cache mettant en cache admin-ajax, plugin de sécurité agressif invalidant les sessions, ou dérive d’horloge.

Correctif : Excluez les chemins admin du cache, ajustez les règles de sécurité, et vérifiez la synchronisation temporelle.

Symptôme : Seuls les administrateurs sont affectés ; les éditeurs peuvent se connecter

Cause racine : Politiques de redirection spécifiques aux administrateurs, mauvaise configuration 2FA, vérifications de capacités, ou mu-plugin personnalisé.

Correctif : Inspectez les must-use plugins et les réglages de sécurité ; testez avec tous les plugins désactivés ; examinez les logs serveurs pour des redirections spécifiques aux rôles.

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

Checklist A : Récupération en une passe pour revenir dans wp-admin

1. Effacez les cookies du navigateur pour le site (ou utilisez une fenêtre privée). Si vous ne pouvez pas vous connecter là non plus, ce n’est pas « des cookies obsolètes ».
2. Confirmez l’URL canonique :
   • Faites en sorte que home et siteurl soient identiques (schéma + hôte).
   • Choisissez soit www soit le domaine apex et tenez-vous-y.
3. Contournez le CDN/WAF temporairement (fichier hosts / accès direct à l’origine) pour voir si la périphérie est le problème.
4. Désactivez tous les plugins via WP-CLI ou en renommant wp-content/plugins.
5. Changez pour un thème par défaut pour éliminer le code d’auth du thème.
6. Consultez les logs pour « headers already sent » et erreurs fatales.
7. Corrigez la détection HTTPS derrière les proxies (en-têtes forwardés ou forçage conditionnel HTTPS dans wp-config.php).
8. Réactivez les plugins un par un. Arrêtez-vous quand la boucle revient. Ce plugin est votre coupable, pas votre victime.

Checklist B : Durcir pour que cela ne revienne pas mardi prochain

1. Excluez les endpoints d’auth du cache : /wp-login.php, /wp-admin/*, et typiquement /wp-json/ selon vos flux admin.
2. Standardisez le déploiement de la config : une source de vérité pour wp-config.php et les salts, déployée identiquement sur tous les nœuds.
3. Surveillez les redirections : suivez les taux de 302 pour wp-login.php et wp-admin. Un pic est souvent un signal d’alerte.
4. Loggez à la périphérie et à l’origine : incluez des IDs de requête pour tracer une tentative de connexion à travers la pile.
5. Documentez votre politique d’URL canonique (hôte, schéma, HSTS). Une politique non écrite devient du folklore ; le folklore devient des incidents.
6. Testez après les changements : chaque fois que vous touchez aux règles CDN, à la terminaison HTTPS ou aux plugins de cache, testez explicitement le flux de connexion.

Blague #2 : Le moyen le plus rapide de créer une boucle de connexion WordPress est de dire « C’est juste un petit changement de redirection. » La boucle vous entend.

Trois mini-récits d’entreprise depuis le front

Incident #1 : La mauvaise hypothèse (HTTPS c’est HTTPS, non ?)

Une entreprise de taille moyenne faisait tourner WordPress derrière un load balancer qui terminait TLS. Les serveurs origine parlaient HTTP en interne. L’équipe a supposé que parce que le navigateur affichait une icône de cadenas, l’application « savait » qu’elle était en HTTPS.

Un après-midi, des éditeurs ont signalé une boucle de connexion. Ce n’était pas tout le monde — juste assez de personnes pour déclencher une panique et une tempête Slack. Le load balancer avait été remplacé lors d’une mise à jour réseau, et le comportement par défaut des en-têtes avait changé.

Sur l’origine, WordPress a commencé à voir les requêtes comme HTTP. Il répondait par des redirections vers HTTPS (parce que home était https), mais il définissait aussi des cookies d’une manière qui ne correspondait pas aux attentes du navigateur. L’histoire des cookies d’auth est devenue incohérente entre les requêtes. Les utilisateurs se connectaient, étaient redirigés, puis traités comme des inconnus et renvoyés.

La correction fut ennuyeuse : assurer que X-Forwarded-Proto: https était correctement défini à la périphérie, et que l’origine lui faisait confiance de façon stable. Une fois que WordPress a eu une vue stable du schéma, la boucle a disparu.

Leçon : dans un monde proxifié, « HTTPS » n’est pas un fait — c’est une affirmation transmise par des en-têtes. Si vous ne gérez pas explicitement cette affirmation, votre application se fabriquera sa propre réalité.

Incident #2 : L’optimisation qui a mal tourné (mettre tout en cache)

Une autre organisation avait une initiative performance. Quelqu’un a activé une règle CDN agressive pour mettre en cache plus de HTML, y compris des « pages à faible risque ». wp-login.php ressemblait à « juste une autre page » dans l’ensemble de règles. Première erreur.

En quelques heures, les taux de réussite de connexion ont chuté. Pas à zéro — juste assez pour être déroutant. Le CDN servait des pages de connexion mises en cache contenant des nonces obsolètes et des cibles de redirection incohérentes. Pire encore, certaines réponses mises en cache n’incluaient pas correctement Set-Cookie, selon la manière dont le borde traitait les en-têtes « non cachables ».

L’incident est devenu politique parce que le changement était présenté comme un « travail de performance », et le travail de performance est censé être héroïque. Au lieu de ça, il a transformé l’authentification en théâtre probabiliste.

La correction a été de créer des règles de bypass explicites pour tous les endpoints liés à l’auth et tout ce qui définit des cookies sensibles. Ils ont ensuite ajouté un moniteur synthétique qui exécutait un flux de connexion et alertait sur des chaînes de redirection inattendues.

Leçon : le cache n’est pas un marteau universel. C’est un scalpel. Si vous vous en servez comme d’un marteau, vous finirez par atteindre votre propre système de connexion.

Incident #3 : La bonne pratique ennuyeuse qui a sauvé la mise (immuabilité de la config)

Une entreprise exécutait WordPress sur plusieurs serveurs applicatifs. Ils avaient une pratique stricte : la configuration, y compris les salts et les clés, était gérée centralement et déployée identiquement à chaque release. Pas d’éditions manuelles. Pas de « correctifs rapides » sur des nœuds individuels.

Ils ont quand même eu un incident — un ingénieur a ajouté un nouveau nœud sous pression. Le nœud venait d’une image plus ancienne et avait initialement un wp-config.php non assorti. Dans beaucoup d’environnements, cela aurait généré des boucles de connexion aléatoires selon le backend qui servait l’utilisateur.

Voici ce qui les a sauvés : leur pipeline de déploiement détectait la dérive. Le nouveau nœud a échoué à un contrôle de checksum de configuration et n’est jamais entré dans la pool du load balancer. La boucle de connexion n’a jamais atteint les clients ; elle est restée un problème de staging où elle appartenait.

Ils ont corrigé l’image, redéployé, et ont poursuivi. Pas de poursuite nocturne « pourquoi cela n’arrive-t-il qu’à certains utilisateurs ».

Leçon : le correctif d’auth le plus fiable est de prévenir l’incohérence. Le deuxième plus fiable est d’empêcher les nœuds incohérents de servir du trafic.

FAQ

Pourquoi WordPress continue-t-il de me rediriger vers la page de connexion après m’être connecté ?

Parce que WordPress ne reçoit pas ou n’accepte pas un cookie d’auth valide à la requête suivante. C’est généralement causé par un mismatch d’URL/schéma, des problèmes de scope de cookie, du cache, des en-têtes proxy, ou un plugin qui interfère avec les en-têtes.

Est-ce que vider les cookies est la vraie solution ?

Vider les cookies est une étape de diagnostic. Si cela corrige le problème une fois, vous avez probablement changé les salts/keys récemment ou eu un mismatch transitoire de cookie. Si cela ne corrige jamais le problème, la cause est dans la pile, pas dans le navigateur.

Un CDN ou un WAF peut-il provoquer une boucle de connexion ?

Absolument. S’il met en cache wp-login.php, supprime Set-Cookie, ou challenge les requêtes POST, vous pouvez vous retrouver coincé dans une boucle. Contournez la périphérie pour confirmer, puis ajoutez des règles de bypass explicites.

Quelle est la différence entre home et siteurl, et pourquoi cela compte-t-il ?

siteurl est l’emplacement des fichiers core de WordPress ; home est ce que le site considère comme son URL publique. Si ces valeurs diffèrent (surtout en schéma/hôte), les redirections et le scope des cookies peuvent casser l’authentification.

Je suis derrière un load balancer. Quel en-tête est le plus important ?

X-Forwarded-Proto. S’il est faux ou non approuvé, WordPress peut croire qu’il est en HTTP alors que le client est en HTTPS, entraînant des redirections et des flags de cookie incorrects.

Est-ce que cela peut être un plugin même si le site public fonctionne correctement ?

Oui. Les pages publiques peuvent fonctionner tandis que les endpoints admin/auth échouent parce que les plugins s’accrochent au login, aux redirections, aux contrôles de sécurité et à la gestion des en-têtes. Désactivez les plugins pour le prouver.

Pourquoi cela n’arrive-t-il qu’à certains utilisateurs dans un environnement load-balanced ?

Généralement à cause d’une dérive de configuration (salts/keys différents) ou d’hypothèses d’état. Si un backend rejette les cookies créés par un autre backend, vous obtenez un comportement « fonctionne parfois ». Rendez la configuration identique et évitez les hacks stateful.

Réinitialiser les salts WordPress résoudra-t-il la boucle ?

Réinitialiser les salts invalide toutes les sessions, ce qui peut « corriger » des boucles causées par des cookies incohérents ou compromis. Mais si la cause racine est les en-têtes proxy, le cache ou le mismatch d’URL, cela n’aidera pas — vos utilisateurs seront simplement déconnectés puis toujours coincés.

Que faire si je n’ai pas accès à wp-admin ni à WP-CLI ?

Renommez le dossier des plugins via SSH pour désactiver tous les plugins : wp-content/plugins → plugins.disabled. Si cela corrige la connexion, réintroduisez les plugins avec précaution. Si non, concentrez-vous sur home/siteurl et la détection proxy/HTTPS.

Conclusion : prochaines étapes pour prévenir la réapparition

Corriger une boucle de connexion WordPress relève moins de l’héroïsme que du refus de se laisser tromper par sa propre pile. Suivez les cookies. Suivez les redirections. Confirmez ce que WordPress croit être l’URL canonique, et confirmez ce que le navigateur fait réellement.

Étapes pratiques :

1. Faites correspondre exactement home et siteurl (schéma + hôte).
2. Assurez-vous que votre proxy/CDN n’effectue pas de cache ou de modification sur wp-login.php et /wp-admin/, et ne supprime jamais Set-Cookie.
3. Vérifiez la détection HTTPS derrière les proxies via les en-têtes forwardés.
4. Désactivez plugins/thèmes pour isoler la sortie d’en-têtes et les hooks d’auth ; réactivez-les un par un.
5. Standardisez wp-config.php (en particulier salts/keys) sur tous les nœuds et gardez l’heure synchronisée.

Si vous faites ces cinq choses, la boucle de connexion redeviendra ce qu’elle devrait être : une histoire que vous racontez à d’autres ingénieurs, pas un lieu où vous vivez.

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.

La physique à laquelle on ne peut pas déroger

La pâte thermique (TIM : thermal interface material) n’est pas « un meilleur conducteur que le métal ». C’est l’inverse. Elle existe parce que les surfaces métalliques réelles ne sont pas plates.
Si vous mettez un spreader de CPU contre un dissipateur, vous n’obtenez pas un contact parfait. Vous obtenez des pics microscopiques en contact et beaucoup d’air piégé dans les vallées.
L’air est un conducteur désastreux. La pâte est « moins désastreuse que l’air », donc elle comble les vides.

L’objectif n’est pas une couche épaisse. L’objectif est une couche mince et continue qui remplace l’air tout en maintenant un contact métal-métal maximal. Si vous mettez trop
de pâte, vous augmentez l’épaisseur de la couche, et comme la pâte conduit moins bien que le cuivre ou l’aluminium, votre résistance thermique augmente. C’est la première
et la plus fréquente des erreurs « l’enthousiasme bat la physique ».

La deuxième erreur est mécanique : la pâte est glissante. L’excès de pâte peut modifier l’assise du dissipateur. Un refroidisseur légèrement incliné ou pas serré uniformément peut créer
un motif de contact qui semble correct à l’œil nu mais génère un point chaud sur un groupe de cœurs sous charge AVX. Les CPU modernes se protégeront en bridant,
mais « protégé » signifie toujours « plus lent », et dans les systèmes distribués, le plus lent est contagieux.

La troisième erreur est la contamination. La plupart des pâtes sont nominalement non conductrices électriquement, mais « non conductrice » n’est pas « sûr à étaler sur de minuscules composants ».
Certaines pâtes sont légèrement capacitives ; d’autres contiennent des métaux ; certaines deviennent conductrices lorsqu’elles sont contaminées ou vieillissent. Et même si la pâte elle-même est électriquement inoffensive,
elle attire poussière et fibres, et rend l’inspection et la retouche pénibles.

Voici la vérité opérationnelle : si le comportement thermique d’un serveur change après un repaste, supposez que vous l’avez empiré jusqu’à preuve du contraire. Cela ne veut pas dire que vous êtes incompétent.
Cela signifie que le système fonctionnait déjà, et vous avez modifié plusieurs variables à la fois : épaisseur de l’interface, pression de montage, courbes de ventilateurs (souvent), et circulation d’air
(vous aviez le capot ouvert). Commencez par la mesure, pas par l’intuition.

Une citation qui devrait figurer sur le mur de chaque équipe d’exploitation, de Richard Feynman :
Pour une technologie qui réussit, la réalité doit primer sur la communication, car la nature ne se laisse pas tromper.
C’est court, rugueux, et vrai.

Blague n°1 : La pâte thermique, c’est comme le parfum — si on la voit de l’autre côté de la pièce, vous en avez mis trop.

À quoi ressemble une application correcte (et pourquoi le « pois » n’est pas universel)

Les conseils sur Internet adorent le « point de la taille d’un pois ». Ce n’est pas faux dans l’esprit, mais c’est incomplet. Les CPU ont des configurations de die différentes sous le spreader.
Les dissipateurs appliquent des distributions de pression différentes. Certains sockets sont rectangulaires et longs (HEDT et plateformes serveur), ce qui fait que la méthode « un point »
peut laisser les coins sous-remplis. Une fine ligne ou un X peut être meilleur pour de grandes empreintes d’IHS.

L’approche sensée est ennuyeuse : utilisez une méthode connue et fiable par plateforme, appliquez un couple constant, et validez avec un contrôle du motif de contact lorsque vous changez de refroidisseur ou de type de pâte.
Si vous travaillez sur une flotte, standardisez. La cohérence bat l’artisanat de la pâte.

Pourquoi l’idée « plus de pâte = meilleur refroidissement » survit

Ça semble intuitif : plus de matériau entre deux choses signifie plus de transfert. C’est vrai quand le matériau est meilleur que l’espace. L’espace, c’est l’air (terrible), donc la première
petite quantité de pâte aide beaucoup. Après cela, vous ne remplacez plus l’air. Vous remplacez le contact métallique par une épaisseur de pâte. Et maintenant vous payez pour ça.

En termes serveurs : la pâte est comme un cache. Un peu, c’est bien. Toute la mémoire qui prétend être cache, ce n’est plus que… de la mémoire.

Faits et contexte historique (la version sans mythes)

• Fait 1 : L’électronique haute puissance utilisait des graisses et huiles comme matériaux d’interface des décennies avant que le repastage en PC grand public ne devienne un hobby.
• Fait 2 : Le « compound thermique » est devenu courant dans les PC lorsque la densité de puissance des CPU a augmenté et que le décalage entre surfaces brillantes et platitude réelle est devenu important.
• Fait 3 : Même des surfaces métalliques polies ont des aspérités microscopiques ; la douceur optique n’est pas la douceur thermique.
• Fait 4 : La conductivité typique des pâtes thermiques est bien inférieure à celle du cuivre ; leur valeur réside dans le remplacement de l’air, pas dans la supériorité au métal.
• Fait 5 : Les matériaux d’interface à changement de phase (pads qui s’assouplissent/fondent légèrement en température) existent pour simplifier la constance d’assemblage en production.
• Fait 6 : Le « pump-out » est réel : le cyclage thermique et les contraintes mécaniques peuvent faire migrer la pâte hors de la zone de contact la plus chaude avec le temps.
• Fait 7 : Certaines pâtes sont électriquement conductrices (notamment les composés métal-liquide), et elles exigent isolation, masquage et un niveau d’exécution plus élevé.
• Fait 8 : Beaucoup de dissipateurs serveurs sont conçus pour une pression de montage et un flux d’air spécifiques ; passer à une approche « aftermarket » peut casser le modèle thermique.
• Fait 9 : Le throttling thermique est devenu plus agressif et granulaire dans les CPU modernes ; vous pouvez perdre des performances sans plantage, ce qui rend l’échec facile à manquer.

Ce que « pâte thermique partout » casse vraiment

Mode d’échec 1 : Résistance thermique accrue due à un TIM épais

Trop de pâte crée une couche plus épaisse. La résistance thermique augmente. Les températures montent plus vite sous charge et se stabilisent à un équilibre plus élevé. Vous observez un
rampage des ventilateurs plus précoce, un bridage anticipé et une réduction du temps en turbo. En production, cela se traduit par des temps d’exécution de jobs plus longs, plus de latence en queue,
et parfois des resets watchdog sur des systèmes aux limites thermiques serrées.

Mode d’échec 2 : Mauvais contact dû au montage inégal

L’excès de pâte peut hydroplaner le dissipateur lors de l’installation, surtout si vous serrez trop fortement un coin trop tôt. Le dissipateur peut emprisonner un coin de pâte et ne jamais s’assoir complètement.
Vous verrez souvent un ou deux cœurs ou un CCD plus chauds que les autres, pas une augmentation uniforme. Ce motif compte : il crie « problème de contact » plus que « problème d’aéraulique ».

Mode d’échec 3 : Pâte aux mauvais endroits

La pâte étalée sur les bords du socket, les composants CMS ou entre les pins est un cadeau qui continue à faire des dégâts. Même les composés « non conducteurs » peuvent créer des chemins de fuite lorsqu’ils sont mélangés à de la poussière.
Cela complique aussi les inspections ultérieures : on ne distingue plus facilement si un composant est fissuré, carbonisé, ou simplement recouvert d’un manteau gris tendance.

Mode d’échec 4 : Mauvaise pâte pour le profil d’exploitation

Les postes et les serveurs ne vivent pas la même vie. Un serveur peut tourner en charge soutenue, avec des températures d’entrée élevées et un cyclage thermique constant. Certaines pâtes grand public se dessèchent,
se séparent ou pump-outent plus vite sous ce régime. À l’inverse, certains composés haute performance sont capricieux et exigent un montage parfait et une préparation de surface stricte.

Mode d’échec 5 : Poursuivre la pâte alors que le vrai problème est l’air

Le diagnostic classique erroné : « Le CPU est chaud, donc la pâte est mauvaise. » Dans une baie, la température d’entrée, les panneaux d’obturation, les faisceaux de câbles, la santé des ventilateurs et les courbes BMC sont
souvent les vrais coupables. La pâte est la chose la plus facile à manipuler, donc elle est blâmée. Pendant ce temps, le serveur respire l’air chaud du voisin parce que quelqu’un a retiré un panneau il y a des mois et personne n’a voulu ouvrir un ticket.

Blague n°2 : Si votre application de pâte ressemble à de l’art moderne, le CPU répondra par de l’art performance — essentiellement du throttling interprétatif.

Cahier de jeu : diagnostic rapide

Quand une machine chauffe après un repaste — ou commence à brider pendant des charges normales — ne recommencez pas par un nouveau repaste. Isolez le goulot d’étranglement en trois passages :
(1) confirmer capteurs et symptômes, (2) corréler avec comportement puissance et fréquence, (3) valider flux d’air et contact mécanique. Vous essayez de répondre rapidement à une question :
le facteur limitant est-il la génération de chaleur, le transfert de chaleur, ou l’évacuation de chaleur ?

Premier : confirmer que le symptôme est réel et spécifique

• Vérifier la température du package CPU, les deltas par cœur/CCD, et si le BMC est en accord avec l’OS.
• Rechercher les drapeaux de throttling thermique et les chutes de fréquence sous charge.
• Comparer avec un hôte frère connu bon si vous en avez un.

Deuxième : corréler les thermiques avec la charge et la puissance

• Est-ce déclenché par la charge (uniquement lors d’AVX ou compression), déclenché par le temps (après 20 minutes), ou par l’ambiance (seulement aux pics d’allée chaude) ?
• Les ventilateurs montent-ils en régime ? Si les ventilateurs sont bas alors que le CPU est chaud, suspectez le contrôle ventilateur / politiques BMC.
• Êtes-vous limité en puissance (clamp package) plutôt qu’en thermique ?

Troisième : valider le flux d’air et le contact mécanique

• Flux d’air : températures d’entrée, RPM des ventilateurs du châssis, filtres bouchés, panneaux manquants, câbles obstruant le flux.
• Mécanique : schéma de serrage du dissipateur, entretoises de montage, alignement de la plaque arrière, plaque froide déformée, entretoise correcte pour le socket.
• TIM : bonne quantité, pas de vides, pas de contamination, type de pâte adapté à la plage de température.

Si vous suivez cet ordre, vous évitez l’erreur la plus coûteuse : refaire des interventions physiques à répétition sans changement mesurable, ce qui transforme un problème technique en incident de fiabilité avec du temps d’arrêt en sus.

Tâches pratiques : commandes, sorties et décisions

Voici des commandes réelles que vous pouvez lancer sur des serveurs Linux typiques pour déterminer si votre problème vient du throttling, des capteurs, du flux d’air ou du contact. Chaque tâche inclut
ce que signifie la sortie et ce que vous devez décider ensuite. Utilisez-les comme vous utiliseriez iostat pour le stockage : comme des preuves, pas pour la déco.

Task 1: Check basic CPU temperatures and per-core spread

cr0x@server:~$ sensors
coretemp-isa-0000
Adapter: ISA adapter
Package id 0:  +86.0°C  (high = +90.0°C, crit = +100.0°C)
Core 0:        +85.0°C  (high = +90.0°C, crit = +100.0°C)
Core 1:        +86.0°C  (high = +90.0°C, crit = +100.0°C)
Core 2:        +68.0°C  (high = +90.0°C, crit = +100.0°C)
Core 3:        +69.0°C  (high = +90.0°C, crit = +100.0°C)

Signification : Deux cœurs sont ~17–18°C plus chauds que les autres dans des conditions similaires. Ce n’est pas « flux d’air du boîtier » ; c’est souvent un contact inégal ou un point chaud localisé.

Décision : Passez aux vérifications de throttling puis à une inspection mécanique si le motif persiste sous une charge contrôlée.

Task 2: Watch temperatures and fan behavior live

cr0x@server:~$ watch -n 1 'sensors | egrep "Package id 0|Core 0|Core 2|fan"'
Every 1.0s: sensors | egrep Package id 0|Core 0|Core 2|fan

Package id 0:  +92.0°C
Core 0:        +91.0°C
Core 2:        +74.0°C
fan1:          8200 RPM
fan2:          8100 RPM

Signification : Les ventilateurs tournent à fond ; le système fait l’effort. Les températures restent élevées, avec un grand delta. L’évacuation fonctionne ; le transfert de chaleur (TIM/contact) est suspect.

Décision : Validez les drapeaux de throttling ; préparez une réinstallation avec le bon couple et la bonne quantité de pâte.

Task 3: Confirm CPU frequency and throttling during load

cr0x@server:~$ lscpu | egrep "Model name|CPU MHz|Thread|Socket"
Model name:                           Intel(R) Xeon(R) CPU
Thread(s) per core:                   2
Socket(s):                            2
CPU MHz:                              1199.992

Signification : Si vous êtes sous charge et que vous voyez ~1.2 GHz sur un CPU qui devrait être bien plus élevé, vous êtes probablement en train de brider ou limité en puissance.

Décision : Vérifiez les logs du noyau pour des événements de throttling thermique et comparez aux limites de puissance.

Task 4: Look for thermal throttling messages in kernel logs

cr0x@server:~$ sudo dmesg -T | egrep -i "thermal|throttl|PROCHOT|temperature" | tail -n 10
[Mon Jan 22 10:14:05 2026] CPU0: Package temperature above threshold, cpu clock throttled (total events = 37)
[Mon Jan 22 10:14:05 2026] CPU1: Package temperature above threshold, cpu clock throttled (total events = 37)

Signification : C’est du throttling thermique explicite. Pas un « peut-être ». Pas un « l’utilisateur dit que c’est lent ».

Décision : Déterminez si cela vient du flux d’air/ambiance ou d’une mauvaise interface/montage en vérifiant ensuite l’entrée d’air et le contrôle des ventilateurs.

Task 5: Read BMC/IPMI sensor data (temps, fans, inlet)

cr0x@server:~$ sudo ipmitool sdr elist | egrep -i "inlet|ambient|cpu|fan" | head -n 12
Inlet Temp       | 24 degrees C      | ok
CPU1 Temp        | 91 degrees C      | ok
CPU2 Temp        | 89 degrees C      | ok
FAN1             | 8100 RPM          | ok
FAN2             | 8200 RPM          | ok
FAN3             | 7900 RPM          | ok

Signification : L’entrée est raisonnable ; les températures CPU sont élevées ; les ventilateurs tournent vite et sont sains. Cela oriente loin des problèmes d’allée chaude et vers le contact/TIM du dissipateur.

Décision : Planifiez une fenêtre de maintenance pour reseater ; ne perdez pas de temps à reconfigurer les courbes de ventilateurs.

Task 6: Verify CPU governor and frequency policy (avoid self-inflicted throttling)

cr0x@server:~$ cat /sys/devices/system/cpu/cpu0/cpufreq/scaling_governor
performance

Signification : Vous ne tournez pas en « powersave ». Bien. Si c’était « powersave », vous pourriez interpréter à tort des fréquences basses comme du throttling thermique.

Décision : Poursuivre les vérifications de limites de puissance/thermiques plutôt que d’ajuster la politique CPU.

Task 7: Check for power capping (can masquerade as thermal issues)

cr0x@server:~$ sudo ipmitool dcmi power reading
    Instantaneous power reading:                   412 Watts
    Minimum during sampling period:                380 Watts
    Maximum during sampling period:                430 Watts
    Average power reading over sample period:      405 Watts
    IPMI timestamp:                           Mon Jan 22 10:20:10 2026
    Sampling period:                          00000010 Seconds.

Signification : Ceci montre la consommation effective ; cela ne prouve pas que vous êtes plafonné, mais cela donne du contexte. Si votre plateforme impose un cap strict, les fréquences peuvent chuter même à des températures sûres.

Décision : Si les températures sont élevées et les fréquences basses, c’est thermique. Si les températures sont modérées et les fréquences basses, suspectez un power capping ou des limites BIOS.

Task 8: Identify whether a specific process triggers the heat spike

cr0x@server:~$ top -b -n 1 | head -n 15
top - 10:22:31 up 18 days,  3:12,  1 user,  load average: 63.12, 58.77, 41.09
Tasks: 412 total,   2 running, 410 sleeping,   0 stopped,   0 zombie
%Cpu(s):  2.1 us,  0.3 sy,  0.0 ni, 97.4 id,  0.0 wa,  0.0 hi,  0.2 si,  0.0 st
MiB Mem : 257843.1 total,  98212.7 free,  40117.2 used, 119513.2 buff/cache
  PID USER      PR  NI    VIRT    RES    SHR S  %CPU  %MEM     TIME+ COMMAND
28412 app       20   0  12.3g  2.1g  112m R  780.0   0.8  12:31.44 compressor

Signification : Un seul workload (compression/crypto/charge AVX) peut pousser les thermiques bien plus loin que vos tests habituels.

Décision : Utilisez un test de charge reproductible (même binaire) lors de la validation d’un reseat ; sinon vous courrez après du bruit.

Task 9: Stress test in a controlled way to reproduce the issue

cr0x@server:~$ sudo apt-get install -y stress-ng
Reading package lists... Done
Building dependency tree... Done
The following NEW packages will be installed:
  stress-ng
0 upgraded, 1 newly installed, 0 to remove and 0 not upgraded.

Signification : Vous avez maintenant un outil cohérent pour générer de la charge.

Décision : Lancez un court stress et surveillez les températures ; ne le faites pas en production sans fenêtre de maintenance et limites de sécurité.

cr0x@server:~$ sudo stress-ng --cpu 32 --timeout 60s --metrics-brief
stress-ng: info:  [31201] dispatching hogs: 32 cpu
stress-ng: metrc: [31201] cpu                60.00s  12345.67 bogo ops/s
stress-ng: info:  [31201] successful run completed in 60.02s

Signification : Une charge reproductible de 60 secondes permet des comparaisons avant/après. Associez-la à watch sensors.

Décision : Si le throttling arrive vite, c’est probablement contact/TIM. Si cela met longtemps, suspectez le flux d’air, des filtres bouchés ou l’ambiance.

Task 10: Check for corrected hardware errors that correlate with heat

cr0x@server:~$ sudo journalctl -k --since "1 hour ago" | egrep -i "mce|edac|hardware error" | tail -n 10
Jan 22 10:09:12 server kernel: mce: [Hardware Error]: Machine check events logged
Jan 22 10:09:12 server kernel: EDAC MC0: 1 CE memory read error on CPU_SrcID#0_Ha#0_Chan#1_DIMM#0

Signification : La chaleur peut exacerber des composants marginaux. Un repaste qui augmente les températures peut transformer « erreurs correctables rares » en « incident ».

Décision : Traitez les problèmes thermiques comme des risques de fiabilité ; planifiez une remédiation avant que les erreurs ne deviennent irréversibles.

Task 11: Validate storage latency during thermal throttling (because it will show up)

cr0x@server:~$ iostat -xz 1 3
Linux 6.5.0 (server) 	01/22/2026 	_x86_64_	(64 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          12.31    0.00    3.22    0.85    0.00   83.62

Device            r/s     w/s   rkB/s   wkB/s  rrqm/s wrqm/s  %util  r_await  w_await
nvme0n1         12.0   220.0   512.0  8192.0     0.0    0.0   68.5    2.10    9.80

Signification : Pendant le throttling, le CPU peut devenir le goulot d’étranglement et gonfler les temps de traitement des requêtes, ce qui peut ressembler à un « stockage qui a ralenti ».

Décision : Si la latence stockage augmente pendant que les fréquences CPU baissent et que les températures grimpent, corrigez d’abord la thermique avant d’ajuster l’I/O.

Task 12: Verify ZFS scrub/resilver isn’t turning thermals into a self-inflicted outage

cr0x@server:~$ zpool status
  pool: tank
 state: ONLINE
status: One or more devices is currently being resilvered.
action: Wait for the resilver to complete.
  scan: resilver in progress since Mon Jan 22 09:41:03 2026
        1.20T scanned at 1.68G/s, 612G issued at 858M/s, 4.10T total
        612G resilvered, 14.58% done, 0 days 01:10:22 to go
config:

        NAME        STATE     READ WRITE CKSUM
        tank        ONLINE       0     0     0
          raidz2-0  ONLINE       0     0     0
            sda     ONLINE       0     0     0
            sdb     ONLINE       0     0     0
            sdc     ONLINE       0     0     0
            sdd     ONLINE       0     0     0

Signification : La resilver sollicite fortement le CPU et la mémoire (checksums, compression, parité). Si vos thermiques CPU sont marginaux, ce type de charge les trouvera.

Décision : Si vous bridez, envisagez de mettre en pause ou de planifier ces travaux de maintenance lourds jusqu’à correction du refroidissement — sinon vous prolongez la période risquée.

Task 13: Check BMC event log for thermal or fan events

cr0x@server:~$ sudo ipmitool sel list | tail -n 8
 217 | 01/22/2026 | 10:14:06 | Temperature #0x01 | Upper Critical going high | Asserted
 218 | 01/22/2026 | 10:14:10 | Temperature #0x01 | Upper Critical going high | Deasserted
 219 | 01/22/2026 | 10:14:12 | Processor #0x01   | IERR | Asserted

Signification : Le BMC a vu un franchissement de seuil thermique. Un événement processeur peut aussi indiquer une instabilité liée à la chaleur.

Décision : Escaladez. Le thermique n’est plus cosmétique ; il provoque désormais des fautes matérielles.

Task 14: Check whether the chassis thinks the lid is present (yes, this happens)

cr0x@server:~$ sudo ipmitool sdr elist | egrep -i "intrusion|chassis"
Chassis Intrusion | Not Available     | ok

Signification : Certaines plateformes ajustent le comportement des ventilateurs selon les capteurs d’intrusion/châssis. Si celui-ci est déclenché, le contrôle des ventilateurs peut se comporter bizarrement.

Décision : Si l’intrusion est affirmée ou « ouverte », corrigez l’état physique d’abord ; ne paramétrez pas le logiciel autour d’un capot manquant.

Trois mini-récits d’entreprise sur le terrain

1) L’incident causé par une mauvaise hypothèse

Une société SaaS de taille moyenne disposait d’une flotte de serveurs de base de données stables depuis des années. Puis un rafraîchissement matériel de routine a eu lieu : même famille CPU, stepping un peu plus récent,
nouvelle révision de la fixation du dissipateur fournie par le vendeur. Rien d’effrayant. Un technicien a repasté quelques hôtes pendant le rack-and-stack parce que certains dissipateurs semblaient « un peu secs ». Cela semblait responsable.

La mauvaise hypothèse était simple : plus de pâte améliore les thermiques, et « ça va s’étaler ». Le technicien a utilisé une quantité généreuse et a fait une installation rapide — serré un coin,
puis l’opposé, mais pas en étapes incrémentales. Les machines ont démarré. Les températures semblaient correctes au repos. Tout le monde est rentré chez soi.

Le lendemain, le cluster de bases de données a commencé à montrer des pics de latence imprévisibles. Pas massifs. Juste assez pour déclencher des retries, qui ont créé plus de charge, qui ont créé
plus de chaleur. Lors du job analytics nocturne, deux nœuds ont commencé à brider, ont pris du retard dans la réplication, et ont été mis hors circuit par le gestionnaire de cluster comme « lents et non sains ».
Le basculement a fonctionné, mais c’était chaotique : un épisode de disponibilité, une pluie de pages, et une longue réunion RCA.

Le post-mortem portait moins sur la pâte que sur la discipline. Ils ont comparé la télémétrie thermique entre les nœuds « repastés » et « intacts » et ont trouvé une signature claire :
températures de package plus élevées sous charge et plus grand delta par cœur. La correction n’a rien d’héroïque. Ils ont ramené les machines en fenêtre de maintenance, nettoyé correctement,
appliqué une quantité mesurée, serré en croix avec un couple constant, et validé avec un test de stress avant de les remettre en pool.

La vraie leçon : supposer qu’un changement physique est bénin parce que le système boote revient à supposer qu’un changement de stockage est sûr parce que le système de fichiers se monte. Boot n’est pas un benchmark. C’est un bonjour.

2) L’optimisation qui s’est retournée contre eux

Une autre organisation — grande, économe, et fière de son « efficacité » — voulait réduire le bruit de ventilateurs et la consommation d’énergie dans un labo devenu discrètement une zone de préproduction.
Quelqu’un a décidé « d’optimiser » les thermiques : réappliquer une pâte haute conductivité premium sur la flotte puis abaisser légèrement les courbes des ventilateurs via les réglages BMC.
L’argument : une meilleure pâte nous permet de faire tourner les ventilateurs moins vite.

La pâte était correcte. Le processus ne l’était pas. Ils ont utilisé une méthode d’étalement pour créer une couche parfaite à l’œil, mais ils ne contrôlaient pas l’épaisseur. Certains dissipateurs se sont retrouvés
avec une couche de pâte tout simplement trop épaisse. Les machines ont tourné plus frais au repos — parce que tout tourne plus frais au repos — et le changement de courbe a donné l’impression
d’un environnement plus calme et « stable ». Slide de victoire.

Puis ils ont exécuté des tests de charge en staging plus réalistes que leurs tests synthétiques précédents. Sous charges CPU soutenues, les températures ont monté lentement, les ventilateurs sont montés tard
(à cause de la nouvelle courbe), et les CPU ont commencé à rétrograder. Les résultats de performance semblaient pires. L’équipe a alors supposé que la nouvelle pâte nécessitait un « rodage », parce que c’est le mythe auquel on se raccroche quand on a déjà choisi un récit.

Au final, l’optimisation a échoué deux fois : le changement de courbe a réduit la marge thermique, et l’épaisseur de TIM incohérente a augmenté la résistance thermique. Ils ont rétabli la politique des ventilateurs,
standardisé la méthode d’application, et ce n’est qu’après cela que la « pâte premium » a produit une amélioration mesurable. Le coût a été surtout du temps et de la crédibilité, qui en milieu corporate ne se renouvelle pas.

Règle opérationnelle : ne jamais regrouper changements physiques et changements de politique à moins d’être prêt à les bisecter. Si vous ne pouvez pas bisecter, vous n’apprendrez pas.

3) La pratique ennuyeuse mais correcte qui a sauvé la situation

Une équipe de stockage gérant des nœuds denses compute+NVMe avait une habitude presque comique : à chaque retrait de dissipateur, ils le notaient comme un échange de disque.
Ticket, raison, type de pâte, méthode, schéma de couple, et un snapshot « avant/après » d’un test de stress de 60 secondes. Personne n’aimait le faire. Tout le monde adorait l’avoir plus tard.

Pendant un gel de changement de fin de trimestre, un nœud a commencé à brider par intermittence. Il ne tombait pas en erreur complète. Il était juste lent. Le service qu’il hébergeait avait des SLOs stricts de latence en queue,
et ce nœud tirait toute la pool vers le bas. À cause du gel, l’équipe avait besoin de preuves avant de demander une exception pour travaux physiques.

Ils ont extrait les données historiques de l’hôte et ont vu que les températures de package sous le test standard avaient augmenté d’environ 10°C depuis la dernière maintenance. Ils ont aussi vu qu’un retrait de dissipateur
avait été enregistré deux mois plus tôt pour un RMA de carte mère. Cela leur a donné une hypothèse plausible : un problème d’assise subtil ou un pump-out.

Ils ont obtenu l’exception, réinstallé le dissipateur selon leur procédure standard, et le test après correspondait à la ligne de base. Pas de drame, pas de suppositions, pas de « essayez une autre marque de pâte ».
L’hôte est revenu en pool, et la fin de trimestre s’est déroulée sans incident de performance.

Voilà à quoi ressemble l’ennuyeux quand il fonctionne : un petit rituel de mesure et de documentation qui transforme un mystère thermique en tâche de maintenance prévisible.

Erreurs courantes : symptômes → cause → correction

1) Températures CPU élevées immédiatement après un repaste

Symptômes : Les températures sont pires qu’avant ; les ventilateurs montent vite ; bridage sous charge modeste.

Cause racine : Trop de pâte (couche épaisse), poches d’air piégées, dissipateur mal assis.

Correction : Retirer le dissipateur, nettoyer complètement les deux surfaces, appliquer une petite quantité mesurée, reseater en serrant en croix par paliers. Valider par un test de charge reproductible.

2) Un cœur/CCD beaucoup plus chaud que les autres

Symptômes : Grand delta par cœur sous charge ; la température du package semble « à peu près » mais un hotspot atteint les seuils.

Cause racine : Pression de montage inégale, inclinaison, entretoise incorrecte, base du dissipateur voilée, coin de pâte.

Correction : Vérifier la compatibilité du matériel de montage ; reseater ; assurer un couple uniforme. Envisager d’inspecter le motif de contact (empreinte fine de pâte) pour confirmer la couverture.

3) Températures correctes au repos, mauvaises après 20–60 minutes

Symptômes : Montée graduelle puis bridage ; souvent corrélé à des charges soutenues (scrubs, rebuilds, jobs batch).

Cause racine : Restriction du flux d’air (filtres, faisceaux de câbles), courbe de ventilateur trop conservative, pics d’ambiance/entrée, pump-out de la pâte avec le temps.

Correction : Vérifier la température d’entrée et le RPM des ventilateurs via le BMC ; inspecter le chemin d’air ; restaurer la politique de ventilateurs du vendeur ; si l’historique le suggère, reseater avec une pâte résistante au pump-out.

4) Systèmes qui rebootent sous charge, thermiques « semblent normaux »

Symptômes : Reboots aléatoires ; parfois pas de log thermique clair ; événements MCE/EDAC occasionnels.

Cause racine : Point chaud localisé non capté par le capteur que vous surveillez, VRM qui surchauffe, mauvais alignement du dissipateur, ou couvercle/ducting manquant provoquant la surchauffe d’un composant.

Correction : Utiliser les capteurs BMC au-delà du CPU (VRM, carte mère, entrée). Confirmer que le ducting et les conduits sont installés. Reverifier l’assise du dissipateur. Ne pas ignorer les erreurs correctées.

5) Ventilateurs bloqués bas alors que la température monte

Symptômes : CPU atteint 90°C, les ventilateurs restent à bas RPM ; pas de panne de ventilateur évidente.

Cause racine : Mauvaise configuration de la politique BMC, capteur d’intrusion châssis activé, ou bug firmware.

Correction : Comparer les températures de l’OS à celles du BMC ; vérifier le SEL pour des événements de politique ; restaurer le profil thermique par défaut ; mettre à jour le firmware BMC pendant une fenêtre contrôlée.

6) Pâte sur le socket/composants après intervention

Symptômes : Contamination visuelle ; problèmes de boot intermittents ; instabilité inexpliquée après maintenance.

Cause racine : Sur-application et étalement pendant le retrait/installation du dissipateur ; mauvaise méthode de nettoyage.

Correction : Couper l’alimentation, démonter avec soin, nettoyer avec un solvant approprié et des outils non pelucheux, inspecter sous une forte lumière. Si une pâte conductrice a été utilisée, traitez cela comme un incident et envisagez le remplacement de la carte.

7) « On a repasté et c’est toujours chaud »

Symptômes : Aucune amélioration après plusieurs repastes ; tout le monde est fatigué ; le système reste marginal.

Cause racine : Le problème n’est pas la pâte : mauvais modèle de dissipateur, chicane manquante, matériel de montage incorrect, ventilateur dégradé, ailettes du dissipateur bouchées, ou température d’entrée trop élevée.

Correction : Arrêtez de repaster. Validez les numéros de pièce, les chicanes et le flux d’air. Vérifiez les ventilateurs et la propreté des ailettes. Comparez à un hôte connu bon dans la même baie.

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

Étape par étape : la procédure « faire une fois et bien » de repaste (niveau serveur)

1. Planifiez la validation. Choisissez un test de charge reproductible (par ex. stress-ng --cpu N --timeout 60s) et enregistrez les températures et fréquences de base avant toute intervention matérielle.
2. Programmez une fenêtre. Prévoyez du temps pour un nettoyage soigné et un test post-travail. La précipitation est la manière dont la pâte devient un mode de vie.
3. Coupez l’alimentation et déchargez. Retirez les cordons d’alimentation, attendez, suivez le guide de service de votre plateforme. Ne hot-swappez pas votre patience.
4. Retirez le dissipateur avec soin. Desserrer en croix un peu à la fois. Évitez de tordre et d’étaler la pâte sur les composants.
5. Nettoyez complètement les deux surfaces. Utilisez des lingettes/tampons non pelucheux et un solvant approprié. Enlevez l’ancienne pâte des bords et recoins où elle aime se cacher.
6. Inspectez les surfaces. Recherchez rayures, piqûres, résidus et signes de contact inégal. Confirmez le bon bracket/entretoises pour le socket.
7. Appliquez la pâte parcimonieusement. Utilisez le minimum nécessaire pour combler les vides : petit point pour un IHS typique, ligne/X pour de grandes empreintes rectangulaires serveur selon le cas.
8. Placez le dissipateur droit. Évitez de le faire glisser ; un petit déplacement peut créer des vides ou repousser la pâte de façon inégale.
9. Serrez progressivement en croix. Quelques tours par vis, en alternant les coins, jusqu’à l’assise complète selon la spécification du fournisseur.
10. Réinstallez chicanes et conduits. Ce n’est pas du décor. C’est la différence entre « système de refroidissement » et « espoir ».
11. Démarrez et vérifiez les capteurs. Confirmez ventilateurs, température d’entrée et températures CPU dans l’OS et le BMC.
12. Lancez le test de validation. Comparez à la base. Si les températures sont pires, arrêtez et revérifiez le montage et la quantité de pâte plutôt que « d’essayer un nouveau motif » au hasard.
13. Enregistrez la modification. Notez le type de pâte, la méthode, et les métriques avant/après. Votre futur vous sera irritablement reconnaissant.

Checklist : sanity du flux d’air et du châssis (avant de blâmer la pâte)

• Tous les modules ventilateurs présents, bon modèle, pas de défauts signalés.
• Ailettes du dissipateur propres ; pas de matage de poussière ni de mousse d’emballage (oui, ça arrive).
• Chicane d’air installée et assise.
• Panneaux d’obturation en place ; pas de RU ouverts court-circuitant le flux d’air.
• Faisceaux de câbles ne bloquant pas les entrées des ventilateurs ou la chicane CPU.
• Températures d’entrée dans la plage attendue ; comparer aux voisins de baie.
• Profil thermique BMC réglé sur le mode recommandé par le vendeur pour votre charge de travail.

Checklist : choisir la pâte comme un adulte

• Préférez des pâtes non conductrices et non capacitives pour les serveurs de flotte, sauf si vous avez une raison solide et des contrôles d’exécution.
• Priorisez la stabilité au cyclage thermique (résistance au pump-out) plutôt que les revendications de conductivité de benchmark maximal.
• Standardisez sur un ou deux composés approuvés et une méthode d’application par plateforme.
• Évitez de mélanger les pâtes ou d’appliquer sur des résidus ; nettoyez jusqu’à la surface nue à chaque fois.
• Si vous utilisez des pads à changement de phase par conception, ne les remplacez pas par de la pâte à la légère ; vous altéreriez un assemblage validé.

FAQ

1) Trop de pâte thermique peut-il réellement aggraver les températures ?

Oui. La pâte sert principalement à combler l’air. Une couche épaisse augmente la résistance thermique comparée au contact métal-métal, élevant les températures et accélérant le bridage.

2) Comment savoir si j’ai mis trop de pâte sans tout démonter ?

Cherchez une signature post-repaste : températures de package plus élevées sous la même charge contrôlée, plus grands deltas par cœur, rampage des ventilateurs plus précoce, et nouveaux événements de throttling dans les logs.
Ces motifs suggèrent fortement une mauvaise interface ou un problème d’assise.

3) La méthode du « pois » est-elle toujours correcte ?

Non. C’est un bon défaut pour beaucoup de tailles d’IHS grand public, mais de grandes empreintes rectangulaires serveur bénéficient souvent d’une ligne ou d’un X pour assurer la couverture des bords. L’exigence réelle est une couverture fine et continue après montage, pas une fidélité à une forme.

4) Faut-il étaler la pâte avec une carte/spatule ?

Dans les opérations de flotte, étaler augmente souvent la variabilité d’épaisseur et peut introduire des bulles si c’est fait à la léger. Un point/ligne/X contrôlé avec une pression de montage appropriée est généralement plus constant. Si vous étalez, utilisez une méthode qui contrôle l’épaisseur et évite l’air.

5) À quelle fréquence faut-il repaster les serveurs ?

Moins souvent que ce que suggèrent les forums hobby. Beaucoup d’assemblages serveur tiennent des années sans repaste. Repastez quand vous avez une preuve : températures qui montent avec le temps, après retrait du dissipateur, ou après un problème de contact vérifié — pas comme rituel saisonnier.

6) Les composés « métal » ou « métal liquide » valent-ils le coup en production ?

Généralement non, sauf si vous avez un process contrôlé et que la plateforme le supporte. Les TIM conducteurs augmentent le risque : courts-circuits, corrosion, et retouches plus difficiles.
La fiabilité prime sur quelques degrés.

7) Mon CPU est chaud ; cela signifie-t-il automatiquement que la pâte est mauvaise ?

Pas automatiquement. Vérifiez d’abord les températures d’entrée, le RPM des ventilateurs, les chicanes et la politique BMC. Les problèmes de flux d’air sont fréquents et affectent plusieurs composants, pas seulement le package CPU.

8) Pourquoi je vois du throttling sans alarme de température évidente ?

Le throttling peut être déclenché par des points chauds localisés ou des capteurs internes qui ne correspondent pas au capteur que vous regardez. De plus, le firmware peut brider de façon proactive en dessous des seuils « critiques ». Utilisez à la fois les logs OS et les capteurs BMC pour une image plus complète.

9) Quel est le facteur mécanique le plus important après la quantité de pâte ?

La pression et l’uniformité de montage. Une pâte parfaite ne compensera pas un dissipateur incliné, serré de façon inégale, ou utilisant la mauvaise entretoise/plaque arrière.

10) Si je repaste et que les températures s’améliorent, suis-je bon ?

Vous êtes bon quand vous avez validé sous une charge soutenue représentative et enregistré le résultat. Beaucoup de problèmes thermiques apparaissent avec le temps, pas dans la première minute.

Conclusion : prochaines étapes concrètes

La pâte thermique n’est pas magique et n’est pas un projet d’artisanat. C’est une interface contrôlée dans un système de transfert thermique avec des modes de panne connus : trop épaisse, assise inégale,
mauvais matériau, ou blâmer le TIM pour des péchés d’aéraulique. Les repastes les plus salissants viennent souvent de la même cause que les pannes bruyantes : changer des choses sans mesurer.

Prochaines étapes pratiques :

• Choisissez une charge de validation standard et enregistrez les thermiques et fréquences de base pour chaque plateforme.
• Quand les thermiques dérivent, suivez le cahier de jeu de diagnostic rapide avant de toucher au matériel.
• Si vous devez repaster, standardisez le type de pâte, la méthode d’application et la séquence de couple — et documentez cela comme tout autre changement en production.
• Après retouche, validez sous une charge soutenue réaliste, pas seulement « ça boot ».
• Traitez les régressions thermiques comme des risques de fiabilité, surtout sur des nœuds de stockage effectuant des rebuilds et scrubs.

Si vous retenez une chose : la bonne quantité de pâte est la quantité minimale qui rend l’air négligeable. Tout ce qui dépasse, c’est juste décorer un problème de chaleur.

La décision : que vous devriez exécuter et pourquoi

Si vous exécutez Ubuntu 24.04 en production et que vous tenez à ne pas perdre d’événements importants, faites ceci :

1. Conservez journald. Ce n’est pas optionnel sur les systèmes systemd, et c’est votre vue de premier intervenant la plus fiable.
2. Rendez le journal persistant sur tout hôte que vous devrez un jour déboguer après un reboot.
3. Utilisez rsyslog pour un acheminement durable et contrôlable vers une plateforme centrale de logs (SIEM, ELK/OpenSearch, Splunk, ou tout ce que votre organisation appelle « la source de vérité »).
4. N’utilisez pas la stratégie « tout envoyer deux fois ». Les doublons ne sont pas de la redondance ; ce sont du bruit qui vous fait manquer la ligne dont vous aviez besoin.

En d’autres termes : journald pour la capture locale, l’indexation et les métadonnées structurées ; rsyslog pour la compatibilité avec l’écosystème syslog, le queueing et les règles de forwarding délibérées. Vous pouvez transférer depuis journald vers rsyslog, ou laisser les services logger directement vers syslog. La bonne réponse dépend de ce que vous devez prouver pendant un incident ou un audit.

Vérité sèche : vous ne choisissez pas la journalisation au feeling. Vous la choisissez selon le mode de défaillance. Demandez-vous : « Que se passe-t-il quand le disque est plein ? Quand le réseau saute ? Quand la machine redémarre ? Quand l’heure saute ? Quand le processus inonde le logger ? » et choisissez la pile qui échoue d’une façon que vous pouvez accepter.

Un modèle mental qui ne trahit pas sous pression

Ce qu’est vraiment journald

systemd-journald est un collecteur et un magasin d’événements de logs avec des métadonnées attachées : cgroup, nom d’unité, PID, UID, capacités, contexte SELinux/AppArmor (quand disponible), boot ID et horodatages monotoniques. Il stocke les entrées dans des fichiers de journal binaires. « Binaire » n’est pas une tare morale ; c’est un choix de performance et d’intégrité. Cela permet l’indexation et des requêtes relativement rapides comme « montre-moi tout depuis sshd.service lors du dernier boot ».

Par défaut sur beaucoup de systèmes, journald utilise un stockage volatile (en mémoire sous /run/log/journal) sauf si un stockage persistant est configuré. Ce comportement par défaut est adapté aux petits disques et aux machines éphémères, et impitoyable quand vous devez déboguer quelque chose qui s’est produit avant un redémarrage.

Ce qu’est vraiment rsyslog

rsyslog est un démon syslog qui ingère des messages (depuis des sockets locaux, depuis le réseau, depuis journald via un module d’entrée) puis les route selon des règles. Il excelle dans les files d’attente, les limites de débit, le buffering assisté par disque et l’envoi fiable des logs quand le réseau se comporte comme un réseau (c’est-à-dire : mal, parfois).

Les sorties rsyslog sont généralement des fichiers texte dans /var/log ou des destinations syslog distantes. Les logs textes restent la lingua franca d’un nombre déprimant d’outils. Ce n’est pas du nostalgie ; c’est la compatibilité avec des systèmes qui parsèrent syslog comme en 2009.

Le pipeline sur Ubuntu 24.04 (typique)

• Les messages du kernel vont dans le ring buffer du kernel, puis journald les collecte ; rsyslog peut aussi lire les messages kernel selon la configuration.
• Les services systemd loggent sur stdout/stderr ; journald capture cela automatiquement.
• Beaucoup d’apps traditionnelles loggent encore via /dev/log (socket syslog). Cela peut être fourni par rsyslog ou par la compatibilité socket syslog de systemd-journald.
• rsyslog peut ingérer depuis journald (via imjournal) ou depuis le socket syslog, puis écrire des fichiers et/ou transférer.

Si vous vous êtes déjà demandé pourquoi votre /var/log/syslog manque une ligne que vous avez vue dans journalctl, la réponse est généralement « ce sont deux chemins de capture différents ». La journalisation est une chaîne d’approvisionnement. Vous ne remarquez pas la chaîne tant qu’un porte-conteneurs n’est pas bloqué.

Une citation à coller sur votre écran (idée paraphrasée) : le thème de Gene Kim sur les opérations est que l’amélioration vient du raccourcissement des boucles de rétroaction. La journalisation est l’une de vos plus courtes boucles ; traitez-la comme du code de production.

Blague n°1 : La journalisation, c’est comme les dents — on l’ignore jusqu’à ce que ça fasse mal, puis soudain on est prêt à payer n’importe quel prix pour faire cesser la douleur.

Faits intéressants et contexte historique

1. syslog est antérieur à Linux. Le syslog original vient du BSD Unix des années 1980, conçu pour un transport simple de logs en réseau quand le « modèle de sécurité » était surtout « ne laissez pas Dave de la compta toucher le serveur ».
2. rsyslog est plus récent qu’on ne le pense. rsyslog a été créé au début des années 2000 comme remplacement drop-in de sysklogd avec de meilleures performances et des fonctionnalités comme TCP, RELP et le queueing.
3. journald stocke les logs en format binaire par conception. Il est optimisé pour des requêtes indexées et des événements riches en métadonnées ; l’argument « les logs binaires sont mauvais » concerne surtout les attentes des outils, pas la fiabilité sous-jacente.
4. systemd a fait de stdout/stderr une première classe pour la journalisation. Cela a changé la culture de logging des applications : les services n’avaient plus besoin de gérer des fichiers de logs s’ils ne le voulaient pas. La plateforme les capture.
5. La rotation traditionnelle des logs a été inventée pour contrôler l’usage disque des logs texte. Avec journald, la rétention est souvent gérée par des plafonds de taille/temps plutôt que par la rotation basée sur les noms de fichiers, ce qui change la façon de répondre à « avons-nous gardé la semaine dernière ? ».
6. RELP existe car TCP n’était pas suffisant. TCP peut toujours perdre des données quand un expéditeur plante ou qu’une connexion se réinitialise au mauvais moment ; RELP (Reliable Event Logging Protocol) ajoute des accusés de réception au niveau applicatif.
7. Journald tague les logs avec un boot ID. Cela semble anecdotique jusqu’à ce que vous déboguiez un crash intermittent et deviez séparer « ce boot » de « le boot précédent ». C’est un vrai cadeau.
8. Le ring buffer du kernel Linux est fini. Si vous ne le videz pas sous un flux, les anciens messages kernel sont écrasés. Ce n’est pas la faute de journald, mais journald est votre chemin de vidage normal.

Compromis qui comptent vraiment en 2025

Durabilité : ce qui survit au reboot et ce qui ne survit pas

journald peut être volatile ou persistant. Un journald volatile convient aux flottes « cattle » où tout est centralisé immédiatement, et est catastrophique pour les moments « pourquoi a-t-il rebooté ? » quand votre forwarder n’a pas envoyé les dernières 30 secondes.

rsyslog écrivant sur disque est persistant par défaut (à condition qu’il écrive dans /var/log et que ce système de fichiers survive). Mais la persistance sur le même disque que votre workload n’est pas une victoire si le disque se remplit et que votre appli meurt. La durabilité est une propriété du système, pas d’un démon.

Rétro-pression et gestion des rafales

Sous des tempêtes de logs, le système de journalisation devient une partie de votre profil de performance. journald a des limitations de débit et peut supprimer des messages. rsyslog peut mettre en file en mémoire ou déverser sur disque. Si vous tenez à « ne jamais perdre les logs d’authentification » ou « capturer les 60 dernières secondes avant un crash », vous avez besoin de réglages explicites et, généralement, de queues assistées par disque.

Métadonnées et ergonomie des requêtes

journald gagne localement pour le tranchage rapide : par unité, par PID, par cgroup, par boot, par priorité, par temps. Si vous faites de l’intervention sur une seule machine, journalctl est souvent plus rapide que grep dans des fichiers — surtout quand les services spamment des données structurées ou que les PID changent.

rsyslog gagne quand vous devez vous intégrer à tout ce qui attend du syslog, du matériel réseau aux pipelines de conformité anciens. C’est « l’adaptateur universel ».

Sécurité et résistance à la falsification

Aucun des deux démons ne rend magiquement les logs à l’épreuve de la falsification. Un root local peut toujours faire des dégâts. Votre véritable contrôle est : expédier les logs hors hôte rapidement, les conserver immuables dans l’agrégateur, et contrôler l’accès. journald prend en charge des fonctions de scellement, mais ne confondez pas « plus difficile à éditer par hasard » avec « niveau judiciaire ».

Complexité et coût opérationnel

Ne faire tourner que journald est simple jusqu’au moment où vous avez besoin d’un forwarding fiable avec buffering, filtrage et choix de protocoles. Faire tourner journald + rsyslog ajoute un peu de pièces mobiles, mais vous donne un contrôle explicite du pipeline. En production, explicite bat implicite.

Blague n°2 : « Nous n’avons pas besoin de journalisation centralisée » est une stratégie audacieuse ; c’est comme refuser les ceintures de sécurité parce que vous comptez conduire prudemment.

Tâches pratiques (commandes, signification des sorties, décisions)

Voici les vérifications que je lance sur Ubuntu 24.04 quand quelqu’un dit « les logs manquent », « le disque se remplit », ou « le forwarding est instable ». Chaque tâche inclut : la commande, ce que signifie la sortie, et la décision à prendre.

Tâche 1 : Confirmer ce qui tourne (journald, rsyslog)

cr0x@server:~$ systemctl status systemd-journald rsyslog --no-pager
● systemd-journald.service - Journal Service
     Loaded: loaded (/usr/lib/systemd/system/systemd-journald.service; static)
     Active: active (running) since Mon 2025-12-30 09:10:11 UTC; 2h 1min ago
...
● rsyslog.service - System Logging Service
     Loaded: loaded (/usr/lib/systemd/system/rsyslog.service; enabled; preset: enabled)
     Active: active (running) since Mon 2025-12-30 09:10:13 UTC; 2h 1min ago
...

Signification : Les deux services sont actifs ; vous avez probablement une journalisation à double chemin. Si rsyslog est inactif, vous comptez probablement uniquement sur journald.

Décision : Si vous avez besoin d’un forwarding distant avec buffering, activez rsyslog (ou un forwarder dédié) et définissez le chemin intentionnellement.

Tâche 2 : Voir le mode de stockage de journald (volatile vs persistent)

cr0x@server:~$ journalctl --disk-usage
Archived and active journals take up 96.0M in the file system.

Signification : Il y a des fichiers de journal sur le disque quelque part. Si cette commande renvoie une erreur ou montre une très faible utilisation alors que vous attendiez un historique, vous êtes peut-être en mode volatile uniquement.

Décision : Si vous tenez aux logs après reboots, assurez-vous que le stockage persistant est activé et que vous avez des réglages de rétention.

Tâche 3 : Vérifier si journald utilise un stockage persistant

cr0x@server:~$ ls -ld /var/log/journal /run/log/journal
drwxr-sr-x 3 root systemd-journal 4096 Dec 30 09:10 /var/log/journal
drwxr-sr-x 2 root systemd-journal  120 Dec 30 09:10 /run/log/journal

Signification : /var/log/journal existe, donc la persistance est activée (ou au moins disponible). Si il n’existe pas, journald est peut-être volatile.

Décision : Si /var/log/journal manque, créez-le et fixez Storage=persistent (détails dans la section plan).

Tâche 4 : Inspecter la rétention de journald et les limites de débit

cr0x@server:~$ systemd-analyze cat-config systemd/journald.conf
# /etc/systemd/journald.conf
[Journal]
Storage=persistent
SystemMaxUse=2G
SystemKeepFree=1G
RateLimitIntervalSec=30s
RateLimitBurst=10000

Signification : Ce sont les réglages effectifs après drop-ins. Un petit SystemMaxUse signifie une éviction plus rapide. Des limites de débit agressives peuvent supprimer des rafales.

Décision : Ajustez selon votre budget disque et vos besoins d’incident. Si vous voyez des pertes lors de pics, adaptez les limites de débit et expédiez hors hôte.

Tâche 5 : Détecter les messages supprimés dans journald

cr0x@server:~$ journalctl -u systemd-journald --since "1 hour ago" | tail -n 8
Dec 30 10:44:02 server systemd-journald[412]: Suppressed 12845 messages from /system.slice/myapp.service
Dec 30 10:44:02 server systemd-journald[412]: Forwarding to syslog missed 0 messages

Signification : « Suppressed » indique des suppressions dues à la limitation de débit. Ce n’est pas théorique. Ça se produit.

Décision : Si l’unité supprimée est importante (auth, kernel, votre service critique), augmentez les limites et réduisez le spam à la source. Envisagez des queues rsyslog pour la fiabilité du forwarding.

Tâche 6 : Vérifier si rsyslog ingère depuis journald

cr0x@server:~$ grep -R "imjournal" /etc/rsyslog.d /etc/rsyslog.conf
/etc/rsyslog.conf:module(load="imjournal" StateFile="imjournal.state")

Signification : rsyslog lit le journal systemd via imjournal. Si absent, rsyslog peut lire depuis /dev/log à la place.

Décision : Choisissez une stratégie d’ingestion pour éviter les doublons : soit imjournal (le journal comme vérité), soit le socket (syslog comme source). Ne faites pas les deux par accident.

Tâche 7 : Repérer les événements dupliqués (symptôme classique de double-ingestion)

cr0x@server:~$ sudo awk 'NR<=20{print}' /var/log/syslog
Dec 30 11:01:10 server myapp[2211]: started worker=7
Dec 30 11:01:10 server myapp[2211]: started worker=7

Signification : Le même message deux fois au même horodatage suggère fortement une double ingestion (par ex., l’appli logge vers syslog et journald forwarde ensuite dans rsyslog).

Décision : Désactivez un chemin : soit arrêtez le forwarding de journald vers rsyslog, soit empêchez rsyslog de lire /dev/log, selon l’architecture.

Tâche 8 : Vérifier les queues rsyslog et si le forwarding est bloqué

cr0x@server:~$ systemctl status rsyslog --no-pager | sed -n '1,14p'
● rsyslog.service - System Logging Service
     Active: active (running) since Mon 2025-12-30 09:10:13 UTC; 2h 9min ago
   Main PID: 621 (rsyslogd)
      Tasks: 4
     Memory: 8.5M
        CPU: 1.901s
     CGroup: /system.slice/rsyslog.service
             └─621 /usr/sbin/rsyslogd -n -iNONE

Signification : Le statut seul ne vous dira pas la profondeur de la file, mais confirme la santé du démon et signale des crash loops évidentes.

Décision : Si le forwarding à distance est retardé, vérifiez la reachabilité réseau et les queues d’action rsyslog (voir les tâches de validation de config ci-dessous).

Tâche 9 : Valider la config rsyslog (syntaxe, modules, includes)

cr0x@server:~$ rsyslogd -N1
rsyslogd: version 8.2312.0, config validation run (level 1), master config /etc/rsyslog.conf
rsyslogd: End of config validation run. Bye.

Signification : La validation est passée. Si des erreurs apparaissent, rsyslog peut tourner avec une config partielle ou échouer à démarrer après des changements.

Décision : Ne rebootez jamais rsyslog à l’aveugle en production. Validez d’abord, puis rechargez, puis confirmez le flux de messages.

Tâche 10 : Déterminer si le forwarding est UDP (perdu) ou TCP/RELP (meilleur)

cr0x@server:~$ grep -R "@" /etc/rsyslog.d /etc/rsyslog.conf
/etc/rsyslog.d/60-forward.conf:*.* @@logrelay.internal:514

Signification : @ est UDP, @@ est TCP. Le TCP peut encore perdre lors de crashs ; RELP est plus robuste.

Décision : Si « ne pas perdre les logs d’auth » est une exigence, n’utilisez pas UDP. Utilisez TCP avec queues disque ou RELP si votre relais le supporte.

Tâche 11 : Vérifier si journald forwarde vers syslog (et si c’est nécessaire)

cr0x@server:~$ grep -R "^ForwardToSyslog" /etc/systemd/journald.conf /etc/systemd/journald.conf.d 2>/dev/null
/etc/systemd/journald.conf:ForwardToSyslog=yes

Signification : journald forwarde les entrées vers le socket syslog. Si rsyslog lit aussi le journal, cela peut dupliquer.

Décision : Choisissez un seul point de passage : soit ForwardToSyslog (journald → socket syslog), soit rsyslog imjournal (journald → rsyslog directement).

Tâche 12 : Identifier « pourquoi a-t-il rebooté ? » via les vues de journal séparées par boot

cr0x@server:~$ journalctl --list-boots | tail -n 3
-2 2f1c1b2dd0e84fbb9a1f66b2ff0f8d1e Sun 2025-12-29 22:10:17 UTC—Sun 2025-12-29 23:52:01 UTC
-1 7d8c0e3fa0f44a3b8c0de74b8b9f41a2 Mon 2025-12-30 00:10:06 UTC—Mon 2025-12-30 09:09:55 UTC
 0 94f2b5d9f61e4f57b5f3c3c7a9c2a1d1 Mon 2025-12-30 09:10:06 UTC—Mon 2025-12-30 11:19:44 UTC

Signification : Plusieurs boots sont visibles, donc la persistance fonctionne. Si vous ne voyez que « 0 », vous êtes probablement en mode volatile ou l’historique a été vacuumé.

Décision : Si les reboots sont mystérieux, activez la persistance de journald et augmentez la rétention pour que le « boot précédent » existe quand vous en avez besoin.

Tâche 13 : Raconter rapidement la séquence d’arrêt/crash

cr0x@server:~$ journalctl -b -1 -p warning..emerg --no-pager | tail -n 20
Dec 30 09:09:51 server kernel: Out of memory: Killed process 2211 (myapp) total-vm:...
Dec 30 09:09:52 server systemd[1]: myapp.service: Main process exited, code=killed, status=9/KILL
Dec 30 09:09:55 server systemd[1]: Reached target Reboot.

Signification : Le dernier boot montre un OOM kill et la mort d’un service menant au reboot. C’est le genre de vue « une seule écran » pour lequel journald excelle.

Décision : Si les événements kernel/OOM sont critiques, assurez-vous qu’ils sont forwardés hors hôte et qu’ils ne sont pas supprimés par des limites de débit sous pression mémoire.

Tâche 14 : Confirmer la pression disque sur le système de fichiers de journalisation

cr0x@server:~$ df -h /var /run
Filesystem      Size  Used Avail Use% Mounted on
/dev/sda2        40G   34G  4.2G  90% /
tmpfs           3.1G  180M  2.9G   6% /run

Signification : /var est serré. Si les logs partagent le filesystem root, une rafale de logs peut devenir une panne.

Décision : Limitez l’usage de journald (SystemMaxUse), faites correctement tourner les logs texte, et expédiez hors hôte. Si nécessaire, isolez /var sur son propre filesystem en environnements critiques.

Tâche 15 : Quantifier quels consommateurs du journal sont bruyants

cr0x@server:~$ journalctl --since "1 hour ago" -o json-pretty | head -n 20
{
        "_SYSTEMD_UNIT" : "myapp.service",
        "PRIORITY" : "6",
        "MESSAGE" : "processed batch id=9f1c...",
        "_PID" : "2211",
        "__REALTIME_TIMESTAMP" : "1735557650000000"
}

Signification : La sortie JSON montre des champs sur lesquels filtrer. Si votre appli spamme « processed batch … » au niveau info, c’est votre disque et le futur vous qui aurez un problème.

Décision : Réduisez le volume à la source. Les systèmes de logs ne sont pas un substitut aux métriques.

Tâche 16 : Vérifier qui a accès au journal (permissions de débogage)

cr0x@server:~$ id
uid=1000(cr0x) gid=1000(cr0x) groups=1000(cr0x),4(adm)

Signification : Les utilisateurs du groupe adm peuvent souvent lire de nombreux logs ; l’accès à journald est couramment accordé via le groupe systemd-journal ou via sudo.

Décision : Donnez aux ingénieurs d’astreinte le minimum de groupes nécessaires pour lire les logs sans accorder le root complet. Puis auditez cette décision trimestriellement, car les organigrammes dérivent.

Plan d’action pour un diagnostic rapide

Vous êtes d’astreinte. L’alerte indique « service down ». Quelqu’un dit « les logs manquent ». Ne partez pas en exploration. Faites ceci dans l’ordre.

Première étape : savoir si les événements existent localement

1. Vérifiez le journal pour le service et la période. Filtrez par unité et priorité. Si le journal contient l’événement, vous avez un point de vérité de départ.
2. Vérifiez le boot précédent. Si l’hôte a rebooté, vos « logs manquants » peuvent simplement être « vous regardez le mauvais boot ».

cr0x@server:~$ journalctl -u myapp.service --since "30 min ago" -p info..emerg --no-pager | tail -n 30
Dec 30 11:03:01 server myapp[2211]: healthcheck failed: upstream timeout
Dec 30 11:03:02 server systemd[1]: myapp.service: Main process exited, code=exited, status=1/FAILURE

Interprétation : Si le journal contient l’événement, le service logge et journald collecte. Votre problème est probablement le forwarding, les filtres de duplication, ou des attentes basées sur les fichiers syslog.

Deuxième étape : déterminer si des données sont supprimées

1. Cherchez les messages de suppression dans journald.
2. Vérifiez la pression disque. Les disques pleins provoquent des comportements étranges et des écritures manquantes.
3. Vérifiez la santé de rsyslog et la validation de la configuration.

Troisième étape : isoler le goulot : capture, stockage ou expédition

• Goulot de capture : application qui ne logge pas, stdout non connecté, décalage du socket syslog, permissions.
• Goulot de stockage : journald volatile, rétention trop faible, disque plein, vacuuming, rotation trop agressive.
• Goulot d’expédition : forwarding rsyslog sur UDP, pas de queues, pertes réseau, problèmes DNS pour l’hôte de logs, mauvaise configuration TLS.

Quatrième étape : prouvez-le avec un message de test contrôlé

cr0x@server:~$ logger -p authpriv.notice "LOGTEST authpriv notice from $(hostname) at $(date -Is)"
cr0x@server:~$ journalctl --since "1 min ago" | grep LOGTEST | tail -n 1
Dec 30 11:18:22 server cr0x: LOGTEST authpriv notice from server at 2025-12-30T11:18:22+00:00

Interprétation : Si c’est dans le journal mais pas dans /var/log/syslog (ou pas dans votre agrégateur), vous avez restreint la défaillance au chemin de handoff/expédition.

Erreurs courantes : symptômes → cause racine → correctif

1) « Les logs disparaissent après un reboot »

Symptômes : journalctl --list-boots n’affiche que le boot 0 ; l’investigation après un crash n’a aucun historique.

Cause racine : journald utilise un stockage volatile (/run) parce que le stockage persistant n’a pas été activé ou que /var/log/journal n’existe pas.

Correctif : Créez /var/log/journal, définissez Storage=persistent, redémarrez journald et confirmez que plusieurs boots apparaissent. Fixez aussi des plafonds de rétention pour que la persistance ne devienne pas une exhaustion de disque.

2) « Nous avons des doublons partout »

Symptômes : La même ligne apparaît deux fois dans /var/log/syslog ou dans l’agrégateur, souvent avec des horodatages identiques.

Cause racine : Double ingestion : l’appli logge vers le socket syslog tandis que journald forwarde vers syslog et rsyslog lit aussi le journal (ou l’inverse).

Correctif : Choisissez une option : rsyslog lit via imjournal ou journald forwarde vers le socket syslog. Ne combinez pas sans logique de déduplication délibérée.

3) « Les logs d’authentification manquent dans le système central, mais le syslog local les a »

Symptômes : /var/log/auth.log est rempli localement ; le SIEM manque des entrées lors de coupures réseau.

Cause racine : Forwarding UDP, ou TCP sans queues disque, ou relais en panne sans buffering.

Correctif : Utilisez TCP avec queues disque ou RELP vers un relais conçu pour l’ingestion. Vérifiez les paramètres de queue et testez en bloquant temporairement le réseau.

4) « Pendant un incident, journalctl est lent ou timeout »

Symptômes : Les requêtes journalctl prennent beaucoup de temps, le CPU grimpe, I/O wait.

Cause racine : Gros journaux sur disques lents, volume de logs agressif, ou contention sur le filesystem sous-jacent. Parfois, c’est juste que l’on essaie de rendre trop de sortie.

Correctif : Filtrez agressivement (unité, priorité, période), limitez l’usage disque, vacuumez les anciennes entrées, et gardez les logs hors de vos stockages les plus lents quand c’est possible.

5) « /var est plein, et maintenant tout est en feu »

Symptômes : Les services échouent au démarrage, les mises à jour échouent, les logs ne se mettent plus à jour, des daemons plantent.

Cause racine : Logs fichiers non bornés, journald mal configuré côté rétention, ou appli runaway écrivant à haute cadence.

Correctif : Définissez des caps journald (SystemMaxUse, SystemKeepFree), assurez le fonctionnement de logrotate pour les logs texte, et corrigez l’appli bruyante. Si l’environnement est critique, isolez /var sur son propre filesystem.

6) « Je vois les logs avec sudo, mais pas en tant qu’utilisateur d’astreinte »

Symptômes : journalctl affiche « No journal files were found » ou permission denied sans sudo.

Cause racine : L’utilisateur d’astreinte n’appartient pas au bon groupe (systemd-journal ou adm selon la politique), ou des permissions renforcées ont été appliquées.

Correctif : Accordez un accès contrôlé en ajoutant l’utilisateur au groupe approprié, pas en partageant des identifiants root, et documentez-le.

Trois micro-histoires d’entreprise issues du terrain de la journalisation

Micro-histoire 1 : Un incident causé par une mauvaise hypothèse

Une entreprise de taille moyenne a migré une flotte d’Ubuntu 20.04 vers 24.04. Ils avaient un runbook bien rodé : vérifier /var/log/syslog, vérifier /var/log/auth.log, expédier vers un syslog central. La migration « a marché », les services sont revenus, et l’équipe est passée à autre chose.

Deux semaines plus tard, un lot de nœuds a rebooté suite à un kernel panic déclenché par un firmware NIC défaillant. L’astreinte a tiré /var/log/syslog et a vu… pas grand-chose. On aurait dit que la machine avait simplement redémarré proprement. Le responsable d’incident a demandé les « 60 dernières secondes ». L’astreinte avait 3 secondes et un sentiment croissant d’effroi.

L’hypothèse erronée était subtile : ils supposaient que rsyslog restait le collecteur principal pour tout ce qui était important. Mais plusieurs services étaient natifs systemd et loggaient sur stdout ; journald les capturait, et seule une partie étaient forwardée vers rsyslog. Les événements manquants n’étaient pas « perdus ». Ils étaient dans un journal volatile qui disparaissait au reboot selon certains profils de nœuds.

Le correctif était ennuyeux mais efficace : rendre journald persistant sur tous les nœuds non éphémères, définir des caps de taille raisonnables, et router journald vers rsyslog via un chemin unique et explicite. Le reboot suivant a été toujours pénible, mais au moins les logs racontaient l’histoire au lieu de gazouiller tout le monde.

Micro-histoire 2 : Une optimisation qui s’est retournée contre eux

Une grande équipe plateforme interne a décidé qu’ils payaient trop en stockage pour les logs. Ils ont constaté que le journal grossissait vite sur les nœuds bavards. Ils ont donc réduit agressivement la rétention de journald et resserré les limites de débit. Leur but était raisonnable : garder les disques sains et réduire le bruit.

Pendant un mois, tout semblait gagné. L’usage disque a baissé. Les dashboards étaient plus propres. Puis une dépendance a commencé à mal se comporter : des échecs intermittents de poignée de main TLS entre services. Les échecs duraient des secondes, quelques fois par heure. Les métriques montraient des pics d’erreur, mais les logs qui auraient expliqué le pourquoi étaient souvent absents. Les pics étaient exactement ceux qui se faisaient supprimer par les limites de débit et la faible rétention quand plusieurs composants deviennent bruyants simultanément.

Ils ont fini par trouver un motif en corrélant quelques logs survivants avec des captures de paquets : un mismatch de MTU après un changement réseau. La vraie leçon n’était pas le MTU. C’était qu’ils « ont optimisé » la journalisation en supprimant les données nécessaires pour déboguer des événements rares qu’on ne peut pas reproduire à la demande.

L’approche corrigée a été de réduire le volume à la source (niveaux de logs, échantillonnage, conception d’événements structurés), garder une rétention journald suffisante pour un triage local, et se reposer sur un store central pour la forensique longue durée. Couper la rétention doit être un scalpel ; ils l’avaient utilisé comme une tondeuse.

Micro-histoire 3 : Une pratique ennuyeuse mais correcte qui a sauvé la mise

Une équipe liée aux paiements gérait des nœuds Ubuntu qui faisaient de l’authentification. Rien de glamorous : services systemd, forwarding rsyslog, et un relais central de logs. L’équipe avait une habitude qui semblait excessive : chaque trimestre, ils réalisaient un test contrôlé de « défaillance d’envoi de logs » pendant les heures ouvrables sur un hôte canari.

Le test était simple. Ils bloquaient l’egress vers le relais de logs pendant quelques minutes sur une machine canari, généraient une poignée de messages logger de test sur différentes facilities et priorités, puis réactivaient l’egress. L’attente : les messages se mettent en file localement et apparaissent ensuite dans l’agrégateur dans l’ordre, sans perte.

Un trimestre, le test a échoué. Les messages n’apparaissaient jamais en amont. Les logs locaux existaient, mais le forwarding n’a jamais rattrapé le retard. Comme c’était un test et non une panne, ils ont eu le temps d’enquêter sans adrénaline. Il s’est avéré qu’un changement de configuration avait basculé le forwarding en UDP « temporairement » et que personne ne l’avait remis. « Temporaire » est le mot le plus permanent en IT d’entreprise.

Ils ont rétabli TCP avec queues disque et écrit un petit check CI qui signalait la présence d’UDP dans les configs de production. Un mois plus tard, un incident réseau réel a touché leur segment datacenter. La file a absorbé l’interruption, le SIEM a rattrapé son retard ensuite, et le rapport d’incident contenait une phrase inhabituelle : « Aucune perte de données constatée ». L’ennuyeux a gagné. Encore.

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

Plan A (recommandé) : journald persistant + forwarding rsyslog avec un seul point d’ingestion

1. Rendre journald persistant.

   cr0x@server:~$ sudo mkdir -p /var/log/journal
   cr0x@server:~$ sudo systemd-tmpfiles --create --prefix /var/log/journal
   cr0x@server:~$ sudo sed -i 's/^#Storage=.*/Storage=persistent/' /etc/systemd/journald.conf
   cr0x@server:~$ sudo systemctl restart systemd-journald

   Vérification : journalctl --list-boots doit montrer plus que le boot 0 après le prochain reboot, et /var/log/journal doit se remplir.

2. Définir des caps de rétention qui n’écraseront pas les disques.

   cr0x@server:~$ sudo tee /etc/systemd/journald.conf.d/99-retention.conf >/dev/null <<'EOF'
   [Journal]
   SystemMaxUse=2G
   SystemKeepFree=1G
   MaxRetentionSec=14day
   EOF
   cr0x@server:~$ sudo systemctl restart systemd-journald

   Décision : Choisissez des caps selon la taille du disque et les besoins d’incident. Sur de petits systèmes root, soyez conservateur et expédiez hors hôte.

3. Choisir le handoff vers rsyslog : utilisez imjournal OU ForwardToSyslog, pas les deux.

   Option 1 (commune) : rsyslog lit le journal avec imjournal.

   cr0x@server:~$ sudo grep -R "module(load=\"imjournal" /etc/rsyslog.conf
   module(load="imjournal" StateFile="imjournal.state")

   Puis désactivez le forwarding de journald vers syslog pour éviter la duplication si vous n’utilisez pas ce chemin :

   cr0x@server:~$ sudo tee /etc/systemd/journald.conf.d/10-forwarding.conf >/dev/null <<'EOF'
   [Journal]
   ForwardToSyslog=no
   EOF
   cr0x@server:~$ sudo systemctl restart systemd-journald

4. Utilisez un forwarding fiable (TCP + queues ; RELP si disponible).

   cr0x@server:~$ sudo tee /etc/rsyslog.d/60-forward.conf >/dev/null <<'EOF'
   # Forward everything to a relay over TCP with a disk-assisted queue.
   # Adjust rules so you don't forward noisy debug logs if you don't need them.
   
   action(
     type="omfwd"
     target="logrelay.internal"
     port="514"
     protocol="tcp"
     action.resumeRetryCount="-1"
     queue.type="LinkedList"
     queue.filename="fwdAll"
     queue.maxdiskspace="2g"
     queue.saveonshutdown="on"
     queue.dequeuebatchsize="500"
   )
   EOF
   cr0x@server:~$ sudo rsyslogd -N1
   cr0x@server:~$ sudo systemctl restart rsyslog

   Décision : Si vous avez des exigences de conformité, associez cela à un relais interne et envisagez RELP/TLS. Le TCP seul est une bonne base, pas une garantie.

5. Prouvez le flux bout-en-bout avec des messages contrôlés.

   cr0x@server:~$ logger -p user.notice "LOGPIPE e2e test id=$(uuidgen)"
   cr0x@server:~$ journalctl --since "2 min ago" -o short-iso | grep LOGPIPE | tail -n 1
   2025-12-30T11:20:41+00:00 server cr0x: LOGPIPE e2e test id=3e0c2aef-7e0f-4a43-a3c2-9c3e5c4f2f8b

   Décision : Si c’est visible localement mais pas centralement, corrigez l’expédition. Si ce n’est pas visible localement, corrigez la capture.

Plan B : journald seul (acceptable pour des flottes éphémères avec centralisation forte)

• Utilisez journald persistant uniquement si les disques et les politiques de rétention le permettent ; sinon, comptez sur un envoi immédiat via un collecteur compatible journald.
• Réglez strictement les limites de débit : vous protégerez peut-être le nœud au prix de la perte de l’événement unique dont vous aviez besoin.
• Assurez-vous d’avoir quand même une copie hors hôte. « Local uniquement » est un prélude à « nous ne pouvons pas prouver ce qui s’est passé ».

Plan C : rsyslog comme primaire (seulement si contraintes legacy)

• C’est possible, mais vous aurez toujours journald qui capture stdout/stderr pour les services systemd.
• Si vous insistez pour des workflows basés fichiers, assurez-vous que les services loggent vers syslog ou des fichiers de manière intentionnelle. Sinon vous courrez après des événements manquants dans deux mondes.
• Soyez explicite au sujet des sources de logs kernel pour éviter les trous.

FAQ

1) Sur Ubuntu 24.04, ai-je besoin de rsyslog du tout ?

Si vous avez besoin de layouts syslog classiques, de règles de routage fines, de queues assistées par disque, ou d’une large compatibilité avec l’écosystème syslog, oui. Si vous disposez d’un collecteur natif journald qui expédie hors hôte de façon fiable, vous pouvez vous passer de rsyslog.

2) journald perdra-t-il des logs ?

Ça peut arriver. En mode volatile, les logs ne survivent pas au reboot. Si les limites de débit s’activent, il peut supprimer des messages lors de rafales. Si le disque est plein ou que les caps de rétention sont petits, les anciens logs sont vacuumés. Rien de cela n’est malveillant ; c’est juste la physique.

3) Les logs binaires posent-ils un problème pour la conformité ?

Généralement, l’exigence de conformité est « rétention, intégrité, contrôle d’accès, auditabilité », pas « doit être en texte clair ». Le vrai geste de conformité est d’expédier hors hôte vers un stockage immuable et de contrôler l’accès. Binaire vs texte est une préférence d’outillage, pas une garantie.

4) Pourquoi je vois des logs dans journalctl mais pas dans /var/log/syslog ?

Parce que journald capture stdout/stderr des services systemd par défaut. À moins de forwarder ces entrées vers syslog, elles n’apparaîtront pas dans les fichiers syslog. De plus, des filtres ou des mappages de facility peuvent router les messages différemment.

5) Dois-je forwarder depuis journald vers rsyslog ou laisser rsyslog lire le journal ?

Choisissez un seul, pour la clarté et éviter la duplication. Je préfère que rsyslog lise le journal via imjournal pour avoir un point d’ingestion unique avec des queues explicites et des actions de forwarding.

6) Le forwarding syslog UDP est-il acceptable ?

Pour la télémétrie à faible enjeu et les flux debug bruyants où la perte est acceptable, oui. Pour l’auth, la sécurité ou les logs critiques : non. Utilisez TCP avec buffering, ou RELP si possible.

7) Quelle rétention de journald devrais-je garder ?

Gardez suffisamment pour couvrir votre fenêtre de réponse humaine : au moins « le boot précédent + quelques jours » sur les hôtes importants. Puis comptez sur la rétention centrale pour des semaines/mois. Limitez l’usage local pour qu’il ne puisse pas manger la machine.

8) Puis-je faire en sorte que journald écrive directement des logs texte traditionnels ?

Pas comme format primaire. journald peut forwarder vers syslog, et les démons syslog peuvent écrire des fichiers texte. C’est le pont supporté : journald capture, rsyslog écrit/forwarde.

9) Qu’en est-il des logs de containers ?

Si les containers loggent sur stdout/stderr et que le runtime s’intègre à systemd, journald peut capturer avec des métadonnées riches. Si vous utilisez un autre runtime, assurez-vous que votre collecteur récupère explicitement les logs de containers. Ne présumez pas.

10) Comment empêcher les logs de mettre la machine hors service ?

Limitez l’usage disque de journald, assurez-vous que logrotate fonctionne pour les logs texte, et réduisez le volume à la source. Évitez aussi de mettre une journalisation lourde sur le même filesystem contraint que votre base de données.

Conclusion : prochaines étapes qui ne vous trahiront pas

Ubuntu 24.04 ne force pas une guerre religieuse entre journald et rsyslog. Il vous offre deux outils avec des modes de défaillance différents. En production, le schéma souvent approprié est : journald persistant pour la vérité locale, plus rsyslog pour un forwarding délibéré, bufferisé et compatible.

Prochaines étapes :

1. Rendez journald persistant sur tout hôte que vous pourriez déboguer après un reboot, et limitez-le pour qu’il ne puisse pas remplir les disques.
2. Décidez d’un point d’ingestion unique vers rsyslog pour éviter les doublons.
3. Basculez le forwarding vers TCP (ou RELP) avec queues assistées par disque pour tout ce que vous ne pouvez pas vous permettre de perdre.
4. Exécutez trimestriellement un test de « défaillance d’envoi de logs » sur un canari. Si cela vous semble excessif, attendez votre premier audit ou incident de sécurité.

La journalisation n’est pas seulement de l’observabilité. C’est une preuve. Construisez-la comme si vous en auriez besoin au tribunal — parce qu’un jour, en interne, ce sera le cas.