nvidia_gpu_exporter : exposer les GPU NVIDIA à Prometheus sans la pile DCGM

Le problème : les cartes grand public n'exposent presque rien

Les cartes GeForce et RTX ne remontent pas les compteurs détaillés que les outils datacenter attendent. Le README le formule sans détour : sur ce segment, nvidia-smi est souvent la seule source uniforme d'utilisation, de mémoire, de puissance et de température. C'est là que l'exportateur intervient. Il s'adresse aussi aux petits clusters Kubernetes, aux machines en périphérie et aux homelabs qui veulent des métriques GPU sans installer la pile complète du NVIDIA GPU Operator. Un troisième cas est mentionné : les environnements virtualisés ou restreints (invités vGPU, tranches MIG, conteneurs verrouillés) où les compteurs plus profonds ne sont pas exposés mais où nvidia-smi répond toujours. Enfin, les parcs mélangeant cartes anciennes et récentes, avec un seul exportateur au comportement identique partout. Le projet assume son positionnement : si vous exploitez des cartes datacenter sur Kubernetes avec le GPU Operator déjà installé, le README renvoie vers DCGM-exporter. C'est un choix honnête, et il évite de promettre une couverture que l'outil n'a pas.

Deux backends, un même jeu de métriques

Le backend par défaut exécute le binaire nvidia-smi, analyse sa sortie et la convertit en métriques Prometheus. Ce détour par un binaire externe explique la portabilité annoncée : Linux, Windows et macOS, sans liaison C. Le README précise que l'exportateur n'a même pas besoin de tourner sur la machine surveillée, puisqu'il peut être configuré pour exécuter nvidia-smi à distance. Il existe aussi une découverte automatique des champs que nvidia-smi peut exposer, présentée comme compatible avec les évolutions futures. Deux options complètent le tableau : des métriques par processus, pour voir quel programme consomme quelle mémoire GPU, et une collecte en arrière-plan qui lance nvidia-smi à intervalle régulier plutôt qu'à chaque scrape. Le second backend, natif, lit les métriques directement depuis la bibliothèque du pilote NVIDIA (NVML) sous Linux. Le README affirme que chaque métrique servie par le backend par défaut reste identique en nom, en étiquettes et en valeur, donc les tableaux de bord et les alertes continuent de fonctionner. S'y ajoutent des familles que nvidia-smi ne fournit pas : métriques par instance MIG, compteurs d'erreurs XID, compteur d'énergie total et débit PCIe. Les tableaux de bord Grafana officiels ont des panneaux pour ces familles : ils restent vides sur le backend par défaut et se remplissent sur celui-ci.

Mise en route : Docker, binaire, mode démo

Le README donne un démarrage rapide sur une machine Linux disposant du pilote NVIDIA et du NVIDIA Container Toolkit. La commande est : 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, suivie de curl http://localhost:9835/metrics pour vérifier la sortie. Le port exposé est donc 9835, et la variable NVIDIA_DRIVER_CAPABILITIES=utility est nécessaire pour que le conteneur accède aux utilitaires du pilote. Pour le backend NVML, le README indique d'utiliser une archive ou une image suffixée -nvml, par exemple utkuozdemir/nvidia_gpu_exporter:latest-nvml, avec la même variable d'environnement. La différence tient au suffixe de l'étiquette, pas à la configuration. Sans GPU sous la main, la commande nvidia_gpu_exporter --collect.backend demo sert des métriques synthétiques, y compris les familles réservées à NVML. Par défaut, le README précise que ce mode simule deux GPU H200 avec des valeurs fluctuantes, une topologie MIG et un historique d'erreurs XID. C'est un moyen de valider un tableau de bord avant d'avoir le matériel. Pour Windows, macOS, les paquets, Kubernetes et l'exécution sans Docker, le README renvoie à docs/INSTALL.md, et la comparaison complète des backends ainsi que leurs limites actuelles se trouvent dans docs/CONFIGURE.md.

Le backend NVML reste marqué expérimental, et c'est justifié

Le README est explicite : ce backend est expérimental principalement parce qu'il a besoin de davantage de tests sur les versions de pilotes et les générations de GPU. Autrement dit, la compatibilité de nom, d'étiquette et de valeur avec le backend nvidia-smi est une promesse de conception, pas un résultat que la documentation présente comme validé sur un large parc. Le mainteneur demande d'ailleurs explicitement de remonter les retours, bons ou mauvais, via les issues, en indiquant que c'est ce qui fera sortir la fonctionnalité de son étiquette. Deuxième limite, plus structurelle : le backend natif est décrit comme disponible sous Linux uniquement, alors que le backend nvidia-smi fonctionne aussi sur Windows et macOS. Si votre parc est hétérogène, vous ne pouvez donc pas aligner tout le monde sur NVML. Troisième point, le README lui-même prévient qu'il s'agit d'un projet personnel maintenu sur le temps libre du développeur, avec un délai possible, voire inexistant, sur les issues et les pull requests. Ce n'est pas une critique de la qualité du code, c'est une contrainte de support à intégrer avant de bâtir une supervision critique dessus.

Quand DCGM-exporter est le meilleur choix

Le README cite DCGM-exporter comme l'alternative probablement mieux adaptée pour les cartes datacenter sur Kubernetes avec le GPU Operator déjà installé. La différence d'approche n'est pas cosmétique. DCGM-exporter s'appuie sur la bibliothèque DCGM de NVIDIA et suppose donc une pile datacenter en place : pilote, GPU Operator, conteneurs privilégiés. nvidia_gpu_exporter prend le chemin inverse. Il se contente d'un binaire nvidia-smi présent sur la machine, ce qui le rend utilisable sur un poste Windows, dans un conteneur restreint ou sur un invité vGPU, là où la pile complète n'a pas sa place. Le compromis est clair : moins de profondeur de mesure, mais beaucoup moins de prérequis. Sur un cluster datacenter déjà équipé, ajouter cet exportateur revient à maintenir un second chemin de collecte pour des métriques que DCGM fournit déjà, avec en prime les familles NVML qui ne sont pas encore stables ici. À l'inverse, sur un parc de RTX ou un homelab, vouloir installer DCGM pour obtenir l'utilisation et la température serait disproportionné.

Maintenance, licence et coût de mise à jour

Le dépôt est publié sous licence MIT, ce qui autorise la réutilisation, la modification et la redistribution, y compris dans un contexte commercial, à condition de conserver l'avis de licence. Ce paragraphe n'est pas un conseil juridique : pour un usage en entreprise, faites relire le fichier LICENSE par qui de droit. Sur le rythme de publication, les informations fournies montrent une version v1.15.1 datée du 2 septembre 2026, précédée de v1.15.0 le même jour et de v1.14.0 le 12 août 2026. Le projet n'est pas archivé et le dernier push est daté du 10 septembre 2026. Ces éléments indiquent une activité récente, rien de plus : ils ne disent rien de la stabilité dans le temps ni de la couverture des cas particuliers. Le coût de mise à jour se concentre sur un point précis. Le backend nvidia-smi analyse la sortie d'un binaire externe, dont le format peut varier selon la version du pilote. La découverte automatique des champs est justement présentée comme un moyen de rester compatible avec ces évolutions, mais elle déplace le risque : une nouvelle colonne mal interprétée ou un libellé modifié peut produire des métriques silencieusement fausses plutôt qu'une erreur visible. Un test de non-régression sur les métriques attendues, lancé après chaque montée de pilote, coûte moins cher qu'une alerte qui ne se déclenche plus.

Conclusion éditoriale

À adopter si vous avez des GeForce ou des RTX, un homelab, un petit cluster Kubernetes sans GPU Operator, ou des invités vGPU et des tranches MIG où les compteurs profonds ne sont pas exposés et où nvidia-smi répond encore. À éviter si vous exploitez des cartes datacenter sur Kubernetes avec le GPU Operator déjà installé : DCGM-exporter couvre mieux ce cas. Avant de vous engager, vérifiez sur une machine représentative que nvidia-smi expose bien les champs attendus, puis comparez la sortie de --collect.backend demo avec celle de votre backend réel pour repérer les familles vides.

Sources officielles

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