Das iLO kennt die Temperatur, aber nicht die von gestern: eine Wärme-Historie für mein Homelab-Rack

🌐 Auch auf: English · Français · Español

Es fing mit einer simplen Frage an einem faulen Nachmittag an: Wie warm sind meine drei Server eigentlich? Das iLO antwortete sofort: Ansaugluft 22 bis 25 °C, Lüfter im Leerlauf bei 6 %, alles grün. Prima. Dann die Anschlussfrage: Und während der Hitzewelle im Juli? Stille. Das iLO 5 zeigt Temperaturen und Lüfter nur live. Keine Historie, kein Graph, kein „letzten Dienstag“. Also habe ich mir eine gebaut, und sie liegt auf GitHub: aptupgrademe/ilo-thermal.

Gleicher Ablauf wie immer: Ich stelle die Fragen und treffe die Entscheidungen, mein KI-Co-Admin (Claude) liest die iLOs über Redfish aus, schreibt den Code und prüft jede Zahl gegen, bevor er ihr vertraut. Genau dieser letzte Teil war am Ende wichtiger als gedacht.

🌡️ Erster Blick: Welcher Sensor sagt überhaupt etwas aus?

Ein iLO 5 in einem DL20 Gen10 Plus liefert rund ein Dutzend Temperatursensoren. Nicht alle sind nützlich, und zwei davon lügen.

Drei Server, unterschiedliche Last, überall exakt 40 °C? Das roch nach Platzhalter, also haben wir die Platten unter Windows per SMART gegengeprüft: 31 bis 35 °C. Das iLO kann Nicht-HPE-Laufwerke schlicht nicht auslesen und trägt eine Konstante ein. Lektion eins: Erst den Sensor prüfen, dann Alarme darauf bauen.

🗺️ Die Sensorkarte: vorne ist y = 1, hinten das höchste y

Die nächste Frage war die spannende: Würde ich einen Hitzestau hinter dem Rack überhaupt bemerken? Diese Modelle haben keinen Abluftsensor. Aber HPEs Redfish verrät, wo jeder Sensor sitzt: Oem.Hpe.LocationXmm und LocationYmm bilden ein Raster, in dem y = 1 der Lufteinlass vorne ist und das höchste y ganz hinten liegt; x ist die Position in der Breite. Trotz des „mm“ im Namen sind das Rasterfelder, keine Millimeter: Die Werte laufen bei einem 43 cm breiten Server nur von etwa 1 bis 14. Wie tief das Raster reicht, hängt vom Modell ab: Bei den DL20 ist die hintere Reihe y = 13–14, beim kompakteren MicroServer endet das Raster bei y = 13. Hinten gibt es zwei Arten von Sensoren:

• Chipsensoren (BMC, LOM-Netzwerkchip): von ihrer eigenen Wärme dominiert, für den Luftstrom nutzlos.
• Luftzonensensoren (BMC Zone, PCI 1 Zone): Sie messen die Luft um sich herum, mit wenig Eigenerwärmung. BMC Zone lag bei HP2 bei 28 °C, nur 3 °C über dem Einlass. Das ist mein Ersatz für einen Abluftsensor.

Und hier kommt die entscheidende Erkenntnis: Die Temperatur hinten allein sagt gar nichts, denn sie folgt dem Raum. Ein warmer Nachmittag hebt vorne und hinten an. Was einen Hitzestau verrät, ist der Abstand. Wächst „hinten minus vorne“ über die üblichen +3 °C hinaus, während Einlass und Last gleich bleiben, kommt die warme Luft nicht raus. Der zweite Frühindikator: Lüfter drehen hoch, obwohl der Einlass nicht wärmer ist.

📍 Lage, Lage, Lage: vier Grad von unten bis oben

Schon die ersten Stunden Historie machten eines deutlich: Wo ein Server im Rack sitzt, ist wichtiger als welcher Server es ist. Gleicher Raum, gleiches Rack, gleiche Leerlauflast, und trotzdem unterscheidet sich die Ansaugluft um mehrere Grad, konstant, bei jeder einzelnen Messung:

33 Messungen in den ersten fünf Stunden eines ruhigen Abends; alle Lüfter auf ihrem Minimum von 6–8 %.

Von unten nach oben steigt der Einlass in sauberen Zwei-Grad-Schritten: 21,9 → 23,9 → 25,9 °C. Das sind vier Grad zwischen dem Server weit unten und dem ganz oben, und dazwischen liegt nichts als Höhe. Die Physik ist simpel: Warme Luft steigt auf. Die Abluft von allem darunter sammelt sich oben im Rack, und der oberste Server atmet einen Teil davon wieder ein, besonders wenn das Rack oben geschlossen oder der Platz darüber knapp ist. Bemerkenswert: Der Abstand von hinten zu vorne beträgt bei allen drei Maschinen dieselben +3–4 °C. Die Server selbst verhalten sich identisch; unterschiedlich ist nur die Luft, die sie abbekommen.

Warum das wichtig ist:

• Der oberste Server erreicht jede Grenze zuerst. An einem 30 °C heißen Sommernachmittag hätte HP3 es noch gemütlich, während HP2 schon an der Warnschwelle klopft. Plane für den wärmsten Platz, nicht für den Durchschnitt.
• Vergleiche jeden Server mit sich selbst. Ein fester „Normalwert“ für das ganze Rack würde HP2 dauerhaft als verdächtig markieren. Deshalb nutzen die Alarmregeln den eigenen 7-Tage-Median jedes Servers.
• Die Platzierung ist ein kostenloser Stellhebel. Stell die Maschine, die am heißesten läuft oder am wichtigsten ist, nach unten, schließ ungenutzte Höheneinheiten mit Blindblenden, damit die Abluft nicht nach vorne zurückschleicht, und lass dem oberen Teil des Racks Luft zum Atmen.

Geständnis: Das habe ich unterschätzt. Als die Server ins Rack kamen, lautete die Platzierungsstrategie, sagen wir, „wo gerade ein Slot frei war“. Die Strömungsphysik hatte kein Stimmrecht. Falls das Rack jemals umgebaut wird, wandern die Server so weit nach unten wie möglich, dicht gestapelt ganz unten, wo die Luft am kühlsten ist.

Der oberste Platz hat übrigens schon den richtigen Mieter: den Switch. Laut Datenblatt ist er für stabilen Betrieb bei deutlich höheren Umgebungstemperaturen spezifiziert als die Server, er kommt mit der warmen Luft da oben also weit besser klar als ein ProLiant. Die Faustregel, die ich mitnehme: Der wärmste Platz gehört dem Gerät, das Hitze am besten verträgt, nicht dem, der zuletzt kam.

Im September harmlos. Aber jetzt weiß ich genau, welchen Server ich im August im Auge behalten muss, und ich habe die Zahlen, um zu belegen, ob ein umgeräumtes Rack wirklich hilft.

🧰 Das Skript: absichtlich langweilig

ilo_thermal.py ist eine einzelne Python-Datei, nur Standardbibliothek. Kein pip, kein requests, kein matplotlib, nichts, was beim nächsten Distro-Upgrade kaputtgehen kann. Alle 10 Minuten startet Cron es:

1. Sammeln: ein lesender Redfish-GET pro iLO für die Thermodaten. Das Skript verbindet sich per IP, prüft das TLS-Zertifikat aber gegen meine eigene Root-CA und den Namen im Zertifikat, weil der Jump-Host das AD-DNS nicht nutzt. Ja, die Homelab-PKI aus einem früheren Beitrag zahlt sich schon wieder aus.
2. Speichern: Alles landet in SQLite. Grob 100–150 MB für drei Server und 400 Tage, also ein volles Jahr zum Vergleichen.
3. Auswerten: die Alarmregeln weiter unten.
4. Berichten: eine einzige, in sich geschlossene HTML-Datei mit den Diagrammen.

🚨 Wann schlägt es Alarm?

„Normal“ ist immer der eigene Median des Servers über die letzten sieben Tage, deshalb zählt HP2s wärmerer Platz ganz oben nicht als Anomalie. Er ist HP2s Normalzustand. Diese Baseline-Regeln werden erst nach einem Tag Historie scharf; eine frische Installation weckt dich also nicht wegen Rauschen. Die Alarme haben einen Zustand: eine Mail zu Beginn, eine Erinnerung alle 12 Stunden und am Ende eine „behoben“-Mail. Kein Flächenbombardement im Postfach.

😴 Der Sammler schläft, das iLO nicht

Der Haken: Mein Jump-Host läuft nicht rund um die Uhr. Das Abfragen klappt nur, solange er läuft, und weil das iLO keine Temperaturhistorie führt, sind die Stunden, in denen er aus war, einfach weg. Der Bericht zeigt sie ehrlich als Lücken, statt eine irreführende gerade Linie durch die Nacht zu ziehen.

Aber etwas behält das iLO doch: das Integrated Management Log. Jedes Hardware-Ereignis (Überhitzung, Lüfterausfall, Stromausfall, Speicher- oder PCIe-Fehler) wird dort mit Zeitstempel abgelegt, ob jemand hinschaut oder nicht. Also merkt sich das Skript pro iLO die höchste EventNumber, die es gesehen hat, und eine @reboot-Cronzeile startet es zwei Minuten nach dem Booten. Alles Neuere wird mit seinem ursprünglichen Zeitstempel gemeldet.

Zum Testen haben wir den Cursor von HP2 zurückgedreht. Prompt grub das Skript einen Uncorrectable PCI Express Error vom 23. Juli aus, den nie jemand bemerkt hatte:

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)

Ein Einzelfall, nie wieder aufgetreten, aber genau die Art Ding, von der man wissen will. Zwei Details halten das Ganze vernünftig: Der erste Lauf setzt nur den Cursor, damit du nicht die komplette Lebensgeschichte deiner Server in der ersten Mail bekommst. Und die IML-Klasse Network wird standardmäßig ignoriert, weil HPE jeden Link-Down als „Critical“ protokolliert, und das passiert bei jedem Patch-Reboot. (Beim Graben verriet das IML außerdem, dass alle drei Server am 26. September in exakt derselben Sekunde für 90 Sekunden ihren Netzwerklink verloren haben. Das sind nicht drei ausfallende Server, das ist ein Switch, der neu startet.)

📈 Der Bericht

• Drei Diagramme: Ansaugluft (mit Warnlinie), Abstand hinten minus vorne, Lüfter. Eine Messgröße pro Diagramm, keine Verbrechen mit doppelter y-Achse.
• Zeiträume 24 h / 7 / 30 / 90 Tage, Hover-Tooltips mit allen Servern zum jeweiligen Zeitpunkt, Lücken, wo der Sammler aus war.
• Statuskacheln, ein Alarmbanner und die Alarmhistorie, inklusive nachgeholter IML-Ereignisse.
• Hell- und Dunkelmodus, eine HTML-Datei, keine externen Abhängigkeiten. Lokal öffnen oder auf eine Freigabe legen.

📦 Hol es dir

Alles liegt im Repo: github.com/aptupgrademe/ilo-thermal. Vollständige Dokumentation auf Englisch, Deutsch, Französisch und Spanisch: Installation, ein lesender iLO-Account (das Recht Login genügt), jeder Konfigurationsschlüssel, jede Alarmregel, Fehlersuche und wie du die zwei Sensornamen-Muster an andere ProLiant-Modelle anpasst. Bericht und Alarme sprechen Englisch oder Deutsch.

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

⚠️ Haftungsausschluss

Das ist ein Hobbyprojekt, veröffentlicht wie es ist unter der MIT-Lizenz. Ich übernehme keine Haftung für seine korrekte Funktion, für verpasste oder falsche Alarme oder für Schäden an Hardware, Daten oder sonst etwas, die aus seiner Nutzung entstehen. Es ersetzt weder den eingebauten Temperaturschutz deiner Server noch ein professionelles Monitoring-System. Prüfe die Werte immer im iLO, bevor du danach handelst. Getestet mit iLO 5 auf DL20 Gen10 Plus und MicroServer Gen10 Plus v2; alles andere liegt bei dir.

🎯 Fazit

Das iLO ist eine fantastische Momentaufnahme und ein miserables Gedächtnis. Ein halber Nachmittag hat aus der Momentaufnahme eine Historie gemacht und mir nebenbei beigebracht, dass zwei meiner Sensoren Fiktion melden, dass oben im Rack immer der warme Platz ist (bei mir vier Grad wärmer) und dass der echte Abluftindikator eine Differenz ist, keine Temperatur. Jetzt ist Herbst, und alles ist langweilig und grün. Nächsten Sommer habe ich ein Jahr Daten zum Vergleichen. Genau darum geht es. 🌡️📉