L’iLO connaît la température, mais pas celle d’hier : un historique thermique pour la baie de mon homelab

🌐 Aussi en: English · Deutsch · Español

Tout a commencé par une question toute simple, un après-midi tranquille : au fait, à quelle température sont mes trois serveurs ? L’iLO a répondu aussitôt : air aspiré entre 22 et 25 °C, ventilateurs au ralenti à 6 %, tout est au vert. Parfait. Puis la question suivante : et pendant la canicule de juillet ? Silence. L’iLO 5 affiche les températures et les ventilateurs uniquement en direct. Pas d’historique, pas de graphique, pas de « mardi dernier ». Alors j’en ai construit un, et il est sur GitHub : aptupgrademe/ilo-thermal.

Même méthode que d’habitude : je pose les questions et je prends les décisions, mon co-admin IA (Claude) interroge les iLO via Redfish, écrit le code et vérifie deux fois chaque chiffre avant de s’y fier. Ce dernier point s’est révélé plus important que prévu.

🌡️ Premier coup d’œil : quel capteur veut vraiment dire quelque chose ?

Un iLO 5 sur un DL20 Gen10 Plus expose une douzaine de capteurs de température. Tous ne sont pas utiles, et deux d’entre eux mentent.

Trois serveurs, des charges différentes, exactement 40 °C partout ? Ça sentait la valeur bouche-trou, alors nous avons contre-vérifié les disques depuis Windows via SMART : 31 à 35 °C. L’iLO ne sait tout simplement pas lire les disques non-HPE et inscrit une constante. Première leçon : vérifiez un capteur avant de bâtir des alertes dessus.

🗺️ La carte des capteurs : l’avant, c’est y = 1, l’arrière, le y le plus élevé

La question suivante était la plus intéressante : est-ce que je remarquerais seulement une accumulation de chaleur derrière la baie ? Ces modèles n’ont pas de capteur d’air extrait. Mais le Redfish de HPE indique où se trouve chaque capteur : Oem.Hpe.LocationXmm et LocationYmm forment une grille où y = 1 correspond à l’entrée d’air à l’avant et le y le plus élevé au fond ; x est la position dans la largeur. Malgré le « mm » dans le nom, ce sont des cases de grille, pas des millimètres : les valeurs ne vont que d’environ 1 à 14 sur un serveur de 43 cm de large. La profondeur de la grille dépend du modèle : sur les DL20, la rangée arrière est à y = 13–14, sur le MicroServer, plus compact, la grille s’arrête à y = 13. À l’arrière, on trouve deux types de capteurs :

• Capteurs de puce (BMC, puce réseau LOM) : dominés par leur propre chaleur, inutiles pour le flux d’air.
• Capteurs de zone d’air (BMC Zone, PCI 1 Zone) : ils mesurent l’air autour d’eux, avec peu d’auto-échauffement. BMC Zone affichait 28 °C sur HP2, seulement 3 °C de plus que son entrée d’air. Voilà mon substitut de capteur d’air extrait.

Et voici l’idée clé : la température à l’arrière, seule, ne dit rien, car elle suit celle de la pièce. Un après-midi chaud fait monter l’avant et l’arrière. Ce qui révèle une accumulation de chaleur, c’est l’écart. Si « arrière moins avant » dépasse ses +3 °C habituels alors que l’entrée d’air et la charge restent les mêmes, l’air chaud ne sort plus. Deuxième signe avant-coureur : des ventilateurs qui accélèrent alors que l’air aspiré n’est pas plus chaud.

📍 L’emplacement, l’emplacement, l’emplacement : quatre degrés de bas en haut

Les premières heures d’historique ont déjà mis une chose en évidence : l’endroit où un serveur se trouve dans la baie compte plus que le serveur lui-même. Même pièce, même baie, même charge au repos, et pourtant l’air aspiré diffère de plusieurs degrés, de façon constante, à chaque mesure :

33 mesures sur les cinq premières heures d’une soirée calme ; tous les ventilateurs à leur minimum de 6–8 %.

De bas en haut, l’air aspiré grimpe par paliers nets de deux degrés : 21,9 → 23,9 → 25,9 °C. Cela fait quatre degrés entre le serveur du bas et celui du haut, avec rien d’autre que la hauteur entre les deux. La physique est simple : l’air chaud monte. L’air extrait de tout ce qui se trouve en dessous s’accumule en haut de la baie, et le serveur du haut en réaspire une partie, surtout si le dessus de la baie est fermé ou si l’espace au-dessus est réduit. À noter : l’écart entre l’arrière et l’avant est le même, +3–4 °C, sur les trois machines. Les serveurs eux-mêmes se comportent de façon identique ; c’est l’air qu’ils reçoivent qui diffère.

Pourquoi c’est important :

• Le serveur du haut atteint chaque limite en premier. Par un après-midi d’été à 30 °C, HP3 serait encore à l’aise alors que HP2 frapperait déjà à la porte du seuil d’alerte. Dimensionnez pour la place la plus chaude, pas pour la moyenne.
• Comparez chaque serveur avec lui-même. Une valeur « normale » fixe pour toute la baie signalerait HP2 comme suspect en permanence. C’est pourquoi les règles d’alerte utilisent la médiane sur 7 jours propre à chaque serveur.
• Le placement est un levier de réglage gratuit. Mettez en bas la machine qui chauffe le plus ou qui compte le plus, fermez les unités de baie inutilisées avec des panneaux d’obturation pour que l’air extrait ne se faufile pas vers l’avant, et laissez le haut de la baie respirer.

Aveu : j’avais sous-estimé tout cela. Quand les serveurs sont entrés dans la baie, la stratégie de placement était, disons, « là où il restait un emplacement libre ». La physique des flux d’air n’avait pas voix au chapitre. Si la baie est un jour réorganisée, les serveurs descendront aussi bas que possible, empilés ensemble tout en bas, là où l’air est le plus frais.

La place du haut a d’ailleurs déjà le bon locataire : le switch. D’après sa fiche technique, il est spécifié pour fonctionner de manière stable à des températures ambiantes nettement plus élevées que les serveurs, il supporte donc l’air chaud de là-haut bien mieux qu’un ProLiant. La règle empirique que je retiens : la place la plus chaude revient à l’appareil qui tolère le mieux la chaleur, pas au dernier arrivé.

Sans conséquence en septembre. Mais je sais maintenant exactement quel serveur surveiller en août, et j’ai les chiffres pour prouver si une baie réorganisée aide vraiment.

🧰 Le script : ennuyeux à dessein

ilo_thermal.py est un unique fichier Python, bibliothèque standard uniquement. Pas de pip, pas de requests, pas de matplotlib, rien qui puisse casser à la prochaine mise à jour de la distribution. Toutes les 10 minutes, cron le lance :

1. Collecter : un seul GET Redfish en lecture seule par iLO pour les données thermiques. Le script se connecte par IP mais vérifie le certificat TLS par rapport à ma propre autorité racine et au nom inscrit dans le certificat, car le jump host n’utilise pas le DNS de l’AD. Oui, la PKI du homelab d’un article précédent est encore rentable.
2. Stocker : tout va dans SQLite. Environ 100–150 Mo pour trois serveurs et 400 jours, soit une année complète pour comparer.
3. Évaluer : les règles d’alerte ci-dessous.
4. Rapporter : un seul fichier HTML autonome avec les graphiques.

🚨 Quand est-ce qu’il crie ?

La « normale » est toujours la médiane propre au serveur sur les sept derniers jours, si bien que la place plus chaude de HP2, tout en haut, ne compte pas comme une anomalie. C’est la normale de HP2. Ces règles de référence ne s’arment qu’après une journée d’historique ; une installation toute neuve ne vous réveillera pas pour du bruit. Les alertes ont un état : un mail au début, un rappel toutes les 12 heures et un mail « résolu » à la fin. Pas de tapis de bombes dans la boîte de réception.

😴 Le collecteur dort, l’iLO non

Le hic : mon jump host ne tourne pas 24 h/24. L’interrogation ne fonctionne que pendant qu’il tourne, et comme l’iLO ne conserve aucun historique de température, les heures pendant lesquelles il était éteint sont tout simplement perdues. Le rapport les montre honnêtement sous forme de trous, au lieu de tracer une ligne droite trompeuse à travers la nuit.

Mais l’iLO conserve bien quelque chose : l’Integrated Management Log. Chaque événement matériel (surchauffe, panne de ventilateur, coupure de courant, erreurs mémoire ou PCIe) y est enregistré avec un horodatage, que quelqu’un regarde ou non. Le script retient donc, pour chaque iLO, le plus grand EventNumber qu’il a vu, et une ligne cron @reboot le lance deux minutes après le démarrage. Tout ce qui est plus récent est signalé avec son horodatage d’origine.

Pour tester, nous avons rembobiné le curseur de HP2. Le script a aussitôt déterré une Uncorrectable PCI Express Error du 23 juillet que personne n’avait jamais remarquée :

IML HP2 CRIT: iLO log 2026-07-23 20:29:31 UTC [PCI Bus]: Uncorrectable PCI Express Error Detected.
              (Segment 0x0, Bus 0x1, Device 0x0, Function 0x2)

Un cas isolé, jamais répété, mais exactement le genre de chose qu’on veut savoir. Deux détails gardent le tout raisonnable : la première exécution se contente de placer le curseur, pour que vous ne receviez pas toute la biographie de vos serveurs dans le premier mail. Et la classe IML Network est ignorée par défaut, car HPE journalise chaque perte de lien comme « Critical », ce qui arrive à chaque redémarrage après les correctifs. (En fouillant, l’IML a aussi révélé que les trois serveurs avaient perdu leur lien réseau à la même seconde exacte le 26 septembre, pendant 90 secondes. Ce ne sont pas trois serveurs en panne, c’est un switch qui redémarre.)

📈 Le rapport

• Trois graphiques : air aspiré (avec la ligne d’alerte), écart arrière moins avant, ventilateurs. Une grandeur par graphique, pas de crimes à double axe.
• Périodes 24 h / 7 / 30 / 90 jours, infobulles au survol avec tous les serveurs à cet instant, trous là où le collecteur était éteint.
• Tuiles d’état, une bannière d’alerte et l’historique des alertes, y compris les rattrapages de l’IML.
• Mode clair et sombre, un seul fichier HTML, aucune dépendance externe. Ouvrez-le en local ou déposez-le sur un partage.

📦 À vous de jouer

Tout est dans le dépôt : github.com/aptupgrademe/ilo-thermal. Documentation complète en anglais, allemand, français et espagnol : installation, un compte iLO en lecture seule (le privilège Login suffit), chaque clé de configuration, chaque règle d’alerte, le dépannage et la façon d’adapter les deux motifs de noms de capteurs à d’autres modèles ProLiant. Le rapport et les alertes parlent anglais ou allemand.

git clone https://github.com/aptupgrademe/ilo-thermal.git ~/ilo-thermal
cd ~/ilo-thermal
cp ilo_thermal.conf.example ilo_thermal.conf && chmod 600 ilo_thermal.conf
# edit: iLO account, CA file, hosts, optional SMTP
./ilo_thermal.py collect && ./ilo_thermal.py report

# crontab
*/10 * * * * $HOME/ilo-thermal/run.sh
@reboot      sleep 120; $HOME/ilo-thermal/run.sh

⚠️ Avertissement

Ceci est un projet personnel, publié en l’état sous licence MIT. Je décline toute responsabilité quant à son bon fonctionnement, aux alertes manquées ou erronées, ou à tout dommage au matériel, aux données ou à quoi que ce soit d’autre résultant de son utilisation. Il ne remplace ni la protection thermique intégrée de vos serveurs ni un système de supervision professionnel. Vérifiez toujours les valeurs dans l’iLO avant d’agir. Testé sur iLO 5 avec DL20 Gen10 Plus et MicroServer Gen10 Plus v2 ; pour le reste, c’est à vous de voir.

🎯 À retenir

L’iLO est un instantané fantastique et une mémoire désastreuse. Un demi-après-midi a suffi pour transformer l’instantané en historique, et m’a appris au passage que deux de mes capteurs racontent des fictions, que le haut de la baie est toujours la place chaude (quatre degrés de plus, dans mon cas) et que le vrai indicateur de l’air extrait est une différence, pas une température. C’est l’automne maintenant, et tout est ennuyeux et vert. L’été prochain, j’aurai une année de données pour comparer. C’est tout l’intérêt. 🌡️📉