nvidia_gpu_exporter: GPU-Metriken für Prometheus ohne GPU-Operator

Welche Lücke der Exporter schließt

Prometheus braucht für GPU-Auslastung, Speicherbelegung, Leistungsaufnahme und Temperatur einen Endpunkt, der diese Werte im Textformat ausliefert. Auf Datacenter-Hardware übernimmt das üblicherweise DCGM-exporter, der auf dem GPU Operator aufsetzt. Genau dort beginnt das Problem, das dieses Projekt adressiert. Das README nennt als Zielgruppe ausdrücklich Consumer- und Prosumer-GPUs der GeForce- und RTX-Reihe, kleine Kubernetes-Cluster, Edge-Boxen, Homelabs, virtualisierte oder eingeschränkte Umgebungen wie vGPU-Gäste, MIG-Slices und abgeriegelte Container sowie gemischte Flotten aus alten und neuen Karten. In all diesen Fällen ist nvidia-smi oft die einzige einheitliche Quelle für Auslastung, Speicher, Leistung und Temperatur. Das README formuliert die Abgrenzung selbst: Wer Datacenter-Karten auf Kubernetes mit bereits installiertem GPU Operator betreibt, für den sei DCGM-exporter vermutlich die bessere Wahl. Das ist eine ungewöhnlich klare Selbstbeschränkung und macht die Einordnung leichter als jede Feature-Liste.

nvidia-smi als Subprozess, NVML als zweiter Weg

Der Standardpfad ist bewusst schlicht: Der Exporter ruft das Binärprogramm nvidia-smi auf, parst dessen Ausgabe und übersetzt die Felder in Prometheus-Metriken. Das README beschreibt eine automatische Erkennung der Felder, die nvidia-smi liefern kann, und begründet das mit Zukunftskompatibilität. Ein Nebeneffekt dieses Designs: Der Exporter muss nicht auf der überwachten Maschine laufen, sondern kann so konfiguriert werden, dass er den nvidia-smi-Befehl remote ausführt. Das ist der eigentliche architektonische Unterschied zu Bibliotheks-basierten Exportern, die im Prozess an den Treiber gebunden sind. Optional lassen sich Metriken pro Prozess erfassen, sodass sichtbar wird, welcher Prozess wie viel GPU-Speicher belegt. Ebenfalls optional ist eine Hintergrundsammlung, bei der nvidia-smi auf einem Timer läuft statt bei jedem Scrape. Diese Option existiert, weil ein Scrape sonst jedes Mal einen Subprozess startet. Auf Linux gibt es zusätzlich einen nativen NVML-Backend, der nvidia-smi überspringt und direkt aus der Treiberbibliothek liest. Laut README bleiben dabei Name, Labels und Wert jedes Metrik-Familienmitglieds identisch, bestehende Dashboards und Alarme funktionieren also weiter. Zusätzlich liefert dieser Backend Familien, die nvidia-smi nicht bereitstellen kann: Metriken pro MIG-Instanz, XID-Fehlerzähler, einen Gesamt-Energiezähler und PCIe-Durchsatz. Die offiziellen Grafana-Dashboards haben dafür Panels, die im Standard-Backend leer bleiben.

Installation: Docker, Windows, Kubernetes, Demo-Modus

Der kürzeste Weg steht im Quick Start und setzt einen Linux-Rechner mit NVIDIA-Treiber und NVIDIA Container Toolkit voraus. Der Container wird mit docker run -d --name nvidia_gpu_exporter --restart unless-stopped --gpus all -e NVIDIA_DRIVER_CAPABILITIES=utility -p 9835:9835 utkuozdemir/nvidia_gpu_exporter:latest gestartet, geprüft wird mit curl http://localhost:9835/metrics. Der Port 9835 ist der Standard, die Umgebungsvariable NVIDIA_DRIVER_CAPABILITIES=utility sorgt dafür, dass nvidia-smi im Container verfügbar ist. Für Windows, macOS, Paketinstallationen, Kubernetes und den Betrieb ohne Docker verweist das README auf docs/INSTALL.md. Wer keine GPU zur Hand hat, kann mit nvidia_gpu_exporter --collect.backend demo synthetische Metriken ausliefern lassen. Der Demo-Modus simuliert laut README standardmäßig zwei H200-GPUs mit schwankenden Werten, eine MIG-Topologie und eine XID-Fehlerhistorie, und zwar inklusive der NVML-only-Familien. Für die NVML-Variante gibt es eigene Release-Artefakte mit dem Suffix -nvml sowie Image-Tags wie utkuozdemir/nvidia_gpu_exporter:latest-nvml. Ein Helm-Chart ist über Artifact Hub verfügbar, und das README verlinkt zwei eigene Grafana-Dashboards, eines für die Detailansicht pro GPU und eines für die Übersicht über mehrere GPUs.

Der NVML-Backend ist ausdrücklich experimentell

Die interessanteren Metriken liefert nur der NVML-Pfad, und genau der trägt im README die Kennzeichnung experimentell. Die Begründung ist konkret: Es fehle noch Testing über verschiedene Treiberversionen und GPU-Generationen hinweg. Das ist keine Formalie. Wer XID-Fehlerzähler oder PCIe-Durchsatz auswerten will, sollte damit rechnen, dass einzelne Familien je nach Treiberstand leer bleiben oder sich anders verhalten. Das README bittet ausdrücklich darum, Issues zu öffnen, unabhängig davon, ob der Versuch gut oder schlecht ausging, weil das der Weg sei, das Label loszuwerden. Ein zweiter Punkt betrifft die Wartung und ist ungewöhnlich offen formuliert: Der Autor schreibt in einem Warnhinweis, es handle sich um ein Side Project, das er in seiner Freizeit pflegt, und dass es lange dauern kann, bis er sich Issues oder Pull Requests ansieht, oder dass er gar nicht dazu kommt. Für ein Monitoring-Bauteil ist das eine relevante Größe. Es bedeutet nicht, dass der Code schlecht ist, aber es bedeutet, dass man bei einem Fehler im Zusammenspiel mit einer neuen Treiberversion nicht mit einer schnellen Korrektur rechnen sollte. Wer den Exporter als Teil einer betreuten Plattform einsetzt, sollte diese Erwartung vorher klären.

Wann DCGM-exporter die richtige Wahl bleibt

Der Unterschied liegt nicht in der Zahl der Metriken, sondern im Ansatz. DCGM-exporter setzt auf das NVIDIA Data Center GPU Manager und wird vom README selbst als passendere Option bezeichnet, sobald Datacenter-Karten auf Kubernetes mit installiertem GPU Operator betrieben werden. Dort ist die Tiefe der Zähler größer und die Integration in die übrige Operator-Toolchain gegeben. nvidia_gpu_exporter verfolgt den umgekehrten Weg: Er nimmt in Kauf, weniger zu sehen, und gewinnt dafür Reichweite. Er läuft auf Windows, Linux und macOS, braucht keine C-Bindings und funktioniert in Umgebungen, in denen der GPU Operator gar nicht installierbar ist, etwa in einem vGPU-Gast oder in einem Container mit stark eingeschränkten Rechten. Ein weiterer praktischer Unterschied ergibt sich aus dem Subprozess-Modell. Wer nvidia-smi auf einem Timer statt bei jedem Scrape ausführen lässt, entkoppelt die Abtastrate von der Scrape-Periode. Das ist nützlich, wenn viele Prometheus-Instanzen dieselbe Maschine abfragen, bringt aber eine Verzögerung zwischen Ereignis und Metrik mit sich, die man bei der Wahl der Scrape-Periode und der query.timeout berücksichtigen muss.

Grenzen, die man vor dem Rollout kennen sollte

Der Exporter löst ein Beobachtbarkeitsproblem, kein Isolationsproblem. Er liest Werte, die der Treiber bereits bereitstellt, und kann daher nichts sichtbar machen, was die Umgebung verbirgt. Das README benennt das indirekt über die Zielgruppe: In virtualisierten oder eingeschränkten Setups sind die tieferen GPU-Zähler schlicht nicht exponiert, nvidia-smi antwortet aber weiterhin. Wer also gehofft hat, in einem vGPU-Gast dieselbe Tiefe wie auf Bare Metal zu bekommen, wird enttäuscht. Ein zweiter Punkt ist die Abhängigkeit vom Format der nvidia-smi-Ausgabe. Die automatische Felderkennung federt neue Felder ab, aber sie ist eine Heuristik über Textausgabe, keine stabile API. Der NVML-Backend umgeht das, ist aber auf Linux beschränkt und experimentell. Drittens: Die Prozess-Metriken sind optional, und im Docker-Beispiel hängt ihre Verfügbarkeit an --gpus all. Ohne diese Option sieht der Container die GPUs nicht und damit auch keine Prozesszuordnung. Schließlich bleibt die Betreuungssituation. Ein Monitoring-Baustein, der still aufhört zu funktionieren, ist schlimmer als einer, der nie lief, deshalb gehört ein Alarm auf die eigene Exporter-Instanz selbst zum Mindestaufwand.

Lizenz, Betrieb und Upgrade-Aufwand

Das Projekt steht unter der MIT-Lizenz, die Nutzung, Änderung und Weitergabe mit Copyright-Hinweis erlaubt und keine Copyleft-Pflichten auslöst. Für kommerzielle Setups ist das unkompliziert, rechtliche Beratung ersetzt das nicht. Der Upgrade-Aufwand ist überschaubar, solange man beim Standard-Backend bleibt: Die Release-Historie zeigt kleinere Minor-Sprünge in kurzen Abständen, und die Metriknamen sind über die Backends hinweg stabil. Wer auf den NVML-Backend wechselt, sollte mit einem eigenen Testlauf rechnen, weil das README selbst von fehlender Abdeckung über Treiberversionen spricht. Konkret bedeutet das: den -nvml-Container einmal neben dem bestehenden starten, die Ausgabe von /metrics gegen die bisherige stellen und prüfen, welche der zusätzlichen Familien tatsächlich Werte tragen. Die Konfiguration ist über docs/CONFIGURE.md dokumentiert, dort steht auch der Abschnitt zum experimentellen NVML-Backend mit dem Backend-Vergleich und den aktuellen Grenzen. Auf der Deployment-Seite lohnt ein Blick darauf, ob nvidia-smi pro Scrape oder per Timer läuft, weil das die Last auf dem Host bestimmt, und ob query.timeout zur Scrape-Periode passt, damit langsame nvidia-smi-Aufrufe nicht in abgebrochene Abfragen laufen.

Redaktionelles Fazit

Sinnvoll ist der Exporter für Consumer- und Prosumer-Karten, Homelabs, kleine Kubernetes-Cluster und eingeschränkte Umgebungen wie vGPU-Gäste oder MIG-Slices, in denen nvidia-smi die einzige verlässliche Quelle ist. Wer Datacenter-Karten auf Kubernetes mit bereits installiertem GPU Operator betreibt, sollte bei DCGM-exporter bleiben. Vor dem Rollout im eigenen Cluster zu prüfen sind der konkrete Wert von collect.backend, ob die Scrape-Periode unter query.timeout liegt, ob bei process-Metriken --gpus all gesetzt ist und welche der NVML-Familien auf der eigenen Treiber- und Kartengeneration tatsächlich befüllt werden.

Offizielle Quellen

1. Issues
2. License: MIT
3. README
4. Releases
5. utkuozdemir/nvidia_gpu_exporter on GitHub