NVIDIA-GPUs mit Zabbix und Checkmk überwachen: Vorlagen, Metriken, XID-Alarme und Lücken

NVIDIA-GPU-Monitoring in Zabbix und Checkmk im Überblick

Um NVIDIA-GPUs mit Zabbix zu überwachen, installieren Sie auf dem GPU-Server das NVIDIA-Plugin für Zabbix Agent 2 und verknüpfen die offizielle Vorlage „Nvidia by Zabbix agent 2“ von Zabbix 7.4, die jede GPU über NVIDIAs Verwaltungsbibliothek NVML findet und Auslastung, Temperatur, Leistung, Speicher, Takte, ECC-Fehler und PCIe-Verkehr mit Triggern überwacht. Checkmk überwacht NVIDIA-GPUs mit den eingebauten nvidia_smi-Checks, verfügbar seit Checkmk 2.2.0, die dieselben Grundwerte über das Werkzeug nvidia-smi lesen. Beide lassen XID-Fehler und die Gründe für eine langsamere GPU aus; diese ergänzen Sie aus dem Kernel-Log und bei Bedarf aus NVIDIAs DCGM.

Dieser Leitfaden richtet sich an IT-Teams, die Zabbix oder Checkmk bereits betreiben und einen neuen GPU-Server in dasselbe Monitoring aufnehmen wollen, ohne eigenen Prometheus- und Grafana-Stack. Was Sie messen sollten und welche Werte Ärger bedeuten, beschreibt unser Leitfaden zum Monitoring von GPU-Servern mit DCGM und XID-Fehlern; Werte, die einen hängenden Host überstehen, kommen vom BMC, wie unser Leitfaden zum Out-of-Band-Monitoring mit Redfish erklärt. Hier geht es um die beiden Werkzeuge: was ihre NVIDIA-Vorlagen tun, was Sie ändern und was Sie ergänzen.

Versionen gelten mit Stand Oktober 2026. Zabbix führt in seiner Dokumentation 7.4 als aktuelles Release und 8.0 als in Entwicklung; die Zabbix-Angaben stammen von der Integrationsseite für NVIDIA und aus dem Paket-Repository, die Checkmk-Angaben aus den Check-Handbuchseiten und Werk 14723, alle gelesen am 25. Oktober 2026.

Zabbix: das NVIDIA-Plugin und die Agent-2-Vorlage

Zabbix veröffentlicht zwei offizielle Vorlagen für NVIDIA-GPUs: „Nvidia by Zabbix agent 2“ für passive und „Nvidia by Zabbix agent 2 active“ für aktive Checks. Beide setzen Zabbix 7.4 oder neuer voraus; für 7.2 gibt es eine passive Fassung. Die Einrichtung hat zwei Schritte: „Zabbix agent 2 compiled with the Nvidia monitoring plugin“ einrichten, dann einen Host anlegen und die Vorlage verknüpfen, bei der passiven Variante mit einer Zabbix-Agent-Schnittstelle. Das Zabbix-Repository führt das Plugin als eigenes Paket, zabbix-agent2-plugin-nvidia-gpu; der neueste Build für 7.4 im Debian-Pool ist 7.4.16, hochgeladen am 20. Oktober 2026.

Zabbix prüft die Einrichtung mit einem einzigen Befehl vom Server oder Proxy aus: zabbix_get mit -s nvidia-host und -k nvml.system.driver.version; er liefert die Treiberversion, wenn Agent und Plugin NVML erreichen. Schlägt er fehl, fehlt das Plugin oder der NVIDIA-Treiber ist auf dem Host nicht geladen.

Die Vorlage hat vier Items auf Host-Ebene: Treiberversion, NVML-Version, Zahl der Geräte und eine Geräteliste. Eine Discovery-Regel, GPU Discovery, legt daraus die Items je GPU an. Ihre Filter-Makros {$NVIDIA.NAME.MATCHES} und {$NVIDIA.UUID.MATCHES} stehen standardmäßig auf .*, es wird also jede GPU erkannt; die NOT_MATCHES-Makros schließen Karten nach Name oder UUID aus.

Zabbix-Integrationsseite „NVIDIA“ (Vorlage für Zabbix 7.4), Item- und Item-Prototyp-Listen, gelesen am 25. Oktober 2026.

Zabbix nennt als Testhardware „Nvidia GTX 1650s“ und „Nvidia RTX 2070Ti“; für Rechenzentrumskarten ist die Vorlage also nicht beschrieben. Auf einer passiven Karte wie der RTX PRO 6000 Blackwell Server Edition oder der H200 NVL, die keinen eigenen Lüfter hat, liefert das Lüfter-Item keinen brauchbaren Wert; die Gehäuselüfter sind ein BMC-Wert. Prüfen Sie jedes Item einmal am gelieferten Server, bevor Sie den Dashboards trauen.

Zabbix-Trigger und Makros, die Sie für GPU-Server ändern

Die Trigger der Vorlage lösen aus, wenn ein Wert drei Minuten über einer Schwelle bleibt, mit einem Trigger des Schweregrads Warning bei 80 und einem des Schweregrads Average bei 90 für GPU-, Speicher-, Encoder- und Decoder-Auslastung, Lüfterdrehzahl, Temperatur und Leistung. Auf einem Server mit KI-Lasten sollten Sie die meisten ändern.

Standardwerte aus der Zabbix-NVIDIA-Vorlage für 7.4 (Makros {$NVIDIA.*.WARN} und {$NVIDIA.*.CRIT}), gelesen am 25. Oktober 2026; unsere Empfehlungen in der dritten Spalte.

Hohe Auslastung ist der Normalzustand einer GPU, die ein Modell bedient, und NVIDIAs Definition zählt nur die Zeit, in der irgendein Kernel läuft; der 90-Prozent-Trigger sagt also nichts über Störungen. Die Framebuffer-Items zeigen eine Karte, die ein Modell bedient, absichtlich fast voll: vLLM reserviert seit Version 0.20.0 standardmäßig 92 Prozent des GPU-Speichers beim Start, ein Alarm auf belegten Framebuffer-Speicher würde also den ganzen Tag auslösen.

Bei der Temperatur kommt es auf den richtigen Trigger an. Die Vorlage beschreibt {$NVIDIA.TEMPERATURE.WARN} und .CRIT als „in %“, das verglichene Item misst aber Grad Celsius; die Standardwerte bedeuten also 80 °C und 90 °C. Nehmen Sie die Schwellen von der Karte: nvidia-smi -q meldet für jede GPU Slowdown Temp, Max Operating Temp und Shutdown Temp, wie unser DCGM-Leitfaden beschreibt, und die Warnung sollte einige Grad unter dem Slowdown-Punkt liegen. Setzen Sie sie als Host-Makros am GPU-Server, damit andere Hosts die Standardwerte behalten.

Leistung über 90 Prozent der Grenze ist das, was eine gut ausgelastete Karte tut. Nützlicher ist der Trigger „Power limit changed“: Meldet eine RTX PRO 6000 Server Edition, die nicht mit 450-W-Grenze bestellt wurde, 450 W statt 600 W, ist die übliche Ursache das Stromkabel, wie unser DCGM-Leitfaden erklärt; die Leistungsstufen der Karte beschreibt unser Beitrag zur RTX PRO 6000 Server Edition mit 600, 450 und 300 W. Heben Sie „Number of devices has changed“ auf den Schweregrad High an, denn eine Karte, die aus NVML verschwindet, ist ein Hardware-Ereignis, und behandeln Sie steigende unkorrigierte ECC-Speicherfehler als Störung, nach unserem Beitrag zu XID 94 und 95 und Row Remapping.

Auf Wunsch kommen unsere KI-Server mit installiertem Betriebssystem, NVIDIA-Treiber, CUDA und Container-Laufzeit, sodass Ihr Monitoring-Agent wie auf jedem anderen Linux-Host installiert wird; nennen Sie uns Ihr Monitoring-System, und unser Team antwortet mit einer Konfiguration.

Checkmk: die nvidia_smi-Checks

Checkmk hat seine NVIDIA-Unterstützung mit Werk 14723 in Version 2.2.0b1 vom 14. Dezember 2022 eingeführt: ein Windows-Agent-Plugin namens nvidia_smi mit einstellbarem Pfad zu nvidia-smi.exe und fünf Check-Plugins. Die Check-Handbuchseiten nennen Linux und Windows als unterstützte Agenten und schreiben, jeder Check „only works if that tool is installed“, gemeint ist nvidia-smi, das mit dem NVIDIA-Treiber kommt.

Checkmk Werk 14723 und die Check-Handbuchseiten zu nvidia_smi_temperature, nvidia_smi_gpu_util, nvidia_smi_power und nvidia_smi_memory_util, gelesen am 25. Oktober 2026.

Jeder Check legt je Karte einen Service an, und das Item ist die PCI-Bus-ID der Karte, nicht ihr Index. Auf Servern mit vier oder acht Karten ist das ein Vorteil: Die Bus-ID bleibt beim Steckplatz, wenn sich die Index-Reihenfolge ändert, und es ist dieselbe Adresse, die der Kernel in eine XID-Zeile schreibt. Unser Leitfaden zum Erkennen einer defekten GPU über Bus-ID und Seriennummer zeigt den Weg von dieser Adresse zur Seriennummer für den Austausch.

Die Handbuchseiten nennen keine Standardschwellen; setzen Sie die Temperaturregel daher je Host nach der Slowdown Temp wie oben. Der Speicher-Check überwacht FB- und BAR1-Speicher getrennt; Checkmk erklärt BAR1 als das Fenster, über das CPU oder andere Geräte den Kartenspeicher direkt erreichen. Ein voller Framebuffer ist auf einem Inferenz-Server auch hier normal.

Auf der Checkmk Exchange stammt das Paket NVIDIA_GPU, Version 2.0 vom 9. Dezember 2021 für Checkmk 2.0.0p3, aus der Zeit vor den eingebauten Checks. Ab Checkmk 2.2 würden wir die eingebauten Plugins verwenden und zwei Quellen für dieselben Services vermeiden.

Was die NVIDIA-Vorlagen nicht sehen

Beide Werkzeuge lesen, was NVML und nvidia-smi standardmäßig melden. Die Werte, die einen fehlgeschlagenen Job oder einen langsamen Server erklären, liegen woanders.

Item-Listen der Zabbix-Vorlage und Checkmk-Check-Handbücher (25. Oktober 2026); Quellen der Signale wie in unseren Leitfäden zu DCGM, XID und BMC beschrieben.

Die Clock Event Reasons sagen, warum Takte sinken: SW Power Cap an der Leistungsgrenze, HW Slowdown durch ein thermisches oder elektrisches Bremssignal, SW Thermal Slowdown über der Max Operating Temp. Auf einem Server, dessen Karten langsamer laufen als erwartet, erklären sie mehr als jede Temperaturkurve. Row Remapping und NVLink-Fehler zählen für die Austauschentscheidung und, auf H200-NVL-Servern mit Brücken, dafür, ob ein Kartenpaar noch mit voller Verbindungsgeschwindigkeit läuft; unser Beitrag zu XID 74 und NVLink-Fehlern behandelt Letzteres.

XID-Fehler in Zabbix oder Checkmk

Ein XID ist eine Fehlermeldung, die der NVIDIA-Treiber ins Kernel-Log schreibt, eine Zeile mit NVRM: Xid, der PCI-Adresse der GPU und einem Code, wie unsere Übersicht der XID-Fehlercodes erklärt. NVIDIA schreibt, dass die Meldungen im Kernel-Log-Puffer landen, meist im Journal und von dort in /var/log/messages oder /var/log/syslog, und empfiehlt die Suche nach „NVRM: Xid“. XID-Alarme sind damit in beiden Werkzeugen eine Aufgabe der Log-Überwachung.

In Zabbix ist die Log-Datei-Überwachung eine Funktion der Zabbix-Agent-Item-Typen und im Handbuch unter diesem Namen beschrieben. Ein Log-Item auf dem Systemlog des GPU-Servers, gefiltert auf NVRM: Xid, liefert ein Ereignis je XID-Zeile, und ein Trigger kann dann die Codes erfassen, die Handeln verlangen. In Checkmk können dieselben Zeilen über die Log-Überwachung oder als vom Server weitergeleitete Syslog-Meldungen ankommen. Eine Item-Syntax geben wir hier nicht an: Folgen Sie der Seite zur Log-Überwachung Ihres Releases und testen Sie mit einer harmlosen, von Hand ins Log geschriebenen Zeile.

Ordnen Sie die Codes in drei Klassen, wie NVIDIAs XID-Katalog. Anwendungsfehler wie 13, 31 und 43 deuten auf einen Job und können Warnung bleiben. Codes, deren Sofortmaßnahme ein GPU-Reset ist, etwa 95, 119 und 120, muss sich noch am selben Tag jemand ansehen. Ein Xid 79, also eine GPU, die vom Bus gefallen ist, verlangt einen geleerten Knoten und einen Anruf beim Systemhersteller. Nehmen Sie die PCI-Adresse in den Alarmtext auf, damit er dem Checkmk-Service der Karte oder der UUID in Zabbix zugeordnet werden kann.

Wann dcgm-exporter trotzdem dazukommt

Die NVML-Vorlage und die nvidia_smi-Checks decken einen Server mit zwei oder vier Karten ab, der wenige Modelle für ein Team betreibt. In drei Fällen gehört zusätzlich NVIDIAs Data Center GPU Manager dazu: bei H200-NVL-Servern mit NVLink-Brücken, deren Verbindungszähler nur DCGM hat; bei Servern, auf denen Sie mit der SM-Aktivität eine voll beschäftigte Karte von einer nur dem Anschein nach ausgelasteten unterscheiden müssen; und bei Serverflotten, auf denen Profiling und Health Checks überall gleich aussehen sollen.

Ein zweites Monitoring-System brauchen Sie dafür nicht. dcgm-exporter liefert seine Metriken auf Port 9400 im Prometheus-Format, wie unser DCGM-Leitfaden beschreibt, und Zabbix führt seit Version 4.2 eine offizielle Prometheus-Integration, „Prometheus checks“, beschrieben als native Unterstützung von PromQL. Halten Sie Port 9400 im Management-Netz. Unser DCGM-Leitfaden nennt auch die Sicherheitskorrektur für dcgm-exporter, die installiert sein sollte, bevor Sie ihn im Netz erreichbar machen.

Für den BMC, die Gehäuseseite desselben Servers, nutzen Sie die Wege, die unser Redfish-Leitfaden je Hersteller aufführt. Der BMC meldet Temperaturen, Leistung und Lüfter auch bei ausgefallenem Betriebssystem, was kein Agent kann.

Was wir liefern

Wir bauen KI-Server nach Maß: einen Einstiegsserver mit zwei RTX PRO 6000 Server Edition, einen Inferenzknoten mit vier und einen Trainingsknoten mit acht H200 NVL, jeweils mit zwei AMD-EPYC-Prozessoren, vor der Lieferung montiert und getestet und in der ganzen EU mit einem Vertrag und einer Rechnung geliefert. Auf Wunsch kommen sie mit installiertem Betriebssystem, Treiber und Container-Laufzeit; der Zabbix- oder Checkmk-Agent kommt dann dazu wie auf jedem anderen Linux-Host. Schicken Sie uns Ihr Monitoring-Setup und die Alarme, die Sie brauchen, und unser Team antwortet innerhalb eines Werktages. Bevor der Server in Betrieb geht, hilft unser Leitfaden zur Abnahmeprüfung von GPU-Servern, zu prüfen, dass jede Karte meldet, was sie soll.

FAQ