Suite logicielle de supervision : Prometheus, Grafana, DCGM, Loki pour les serveurs d’IA

Un serveur d'IA non surveillé est un serveur qui bride silencieusement ses performances, subit des fuites de VRAM, accumule les erreurs ECC ou est arrêté par manque de mémoire à 3 h du matin ; vous ne vous en apercevez que trois jours plus tard, lorsqu'on vous demande pourquoi les réglages fins ont produit des résultats catastrophiques. La plupart des pannes les plus critiques d'un système GPU sont invisibles pour l'application : la limitation thermique n'est pas consignée dans la sortie d'erreur standard, les corrections ECC ne provoquent pas de plantage immédiat, le processus est interrompu par le processus OOM puis redémarré proprement par l'orchestrateur. Sans surveillance du matériel lui-même, vous ne vous rendez compte de rien avant qu'une semaine ne se soit déjà écoulée.

La boîte à outils standard d'administrateur système (htop, df, uptimeLe système de journalisation système (syslog) ne couvre pas ce cas. Le GPU est le composant le plus coûteux et le plus sujet aux pannes du châssis ; il possède sa propre pile de télémétrie qui nécessite une configuration spécifique. Cet article présente la configuration optimale de cette pile (Prometheus, Grafana, DCGM-exporter, node_exporter, Loki et Alertmanager) déployée dans un seul fichier docker-compose installé sur chaque serveur Kentino AI que nous livrons.

Le public cible est composé de personnes qui mettent en place un serveur d'IA à 4 ou 8 GPU, qui savent écrire un fichier docker-compose et qui souhaitent obtenir la réponse à la question : « Que dois-je surveiller et à quel seuil dois-je déclencher une alarme ? »

La pile standard en 2026

Cinq composants assurent la quasi-totalité du travail. Le reste se fixe facilement.

Cela représente bien moins de 0.5 % d'un cœur de processeur sur un EPYC 96 cœurs avec environ 700 Mo de RAM. Sur un serveur 256 Go / 8 GPU, cette consommation est négligeable. L'argument selon lequel « la surveillance accapare des ressources d'entraînement » n'est plus valable depuis environ 2019.

La seule décision architecturale qu'il vaut la peine de prendre dès le départ : Exécutez la pile sur une machine virtuelle de gestion distincte ou sur un petit boîtier, et non sur le serveur GPU lui-même. Un mini-PC dédié, un NUC, un nœud de service EPYC ou une VM sur l'hyperviseur du laboratoire — tout ce qui n'est pas le serveur GPU. Deux raisons : en cas de panne du serveur GPU (panique du noyau due à un manque de mémoire, coupure d'alimentation, arrêt thermique), il est essentiel de conserver l'historique des métriques pour diagnostiquer le problème, et d'éviter qu'une tâche d'entraînement incontrôlée n'entre en conflit avec Prometheus pour la mémoire et ne déclenche sa propre alerte. DCGM-exporter et node_exporter s'exécutent sur le serveur GPU (ils doivent le faire, car ils lisent les périphériques locaux) ; Prometheus, Grafana, Loki et Alertmanager s'exécutent sur la VM de gestion et collectent les données.

Exportateur de DCGM — un élément incontournable

NVIDIA Data Center GPU Manager (DCGM) est la source officielle et prise en charge pour la télémétrie GPU. dcgm-exporter Le conteneur expose les métriques DCGM au format Prometheus sur le port 9400. C'est le composant le plus important de la pile, et c'est ce qui compte. nvidia-smi Les sondages ne remplaceront jamais…

Installation via le conteneur NGC (nvcr.io/nvidia/k8s/dcgm-exporter(actuellement en version 4.x à partir de mi-2026) ou le graphique Helm amont pour Kubernetes. Sur un Docker nu, un docker run --gpus all --rm cela suffit ; le démon publie ensuite environ 80 métriques sur :9400/metricsLes plus importantes, classées selon leur capacité à détecter les problèmes réels :

Les compteurs de régime moteur sont l'atout majeur. DCGM_FI_DEV_THERMAL_VIOLATION Il s'agit d'un compteur monotone en nanosecondes, indiquant le temps passé par le GPU en mode de limitation thermique. Calculez sa valeur sur une période de 5 minutes et vous obtiendrez une réponse précise à la question : « Mon serveur est-il actuellement limité thermiquement ? » Sans ce compteur, vous devez vous fier uniquement à la température, ce qui est erroné : une 4090 se mettra en mode de limitation thermique à 83 °C en charge soutenue, indépendamment de ce qu'indique le panneau de température.

Deux particularités connues des exportateurs de DCGM qu'il est bon de connaître en 2026 : certains codes XID (notamment le XID 62) ne sont pas toujours affichés. DCGM_FI_DEV_XID_ERRORS, et la métrique est une mesure de la dernier L'identifiant XID a été détecté ; il peut donc échouer à se réinitialiser après une récupération sans redémarrer l'exportateur. La solution consiste à : aussi Surveillez le tampon circulaire du noyau via Loki pour le résultat littéral. NVRM: Xid Cordon (plus de détails ci-dessous). Ceinture et bretelles.

Pour les cartes graphiques grand public (RTX 4090, 5090), certaines fonctionnalités de centre de données DCGM sont incomplètes : MIG est absent, NVLink est absent sur les composants grand public Blackwell, et certains compteurs ECC renvoient zéro. DCGM reste fonctionnel et affiche les données exposées ; une alternative communautaire plus légère est disponible. nvidia_gpu_exporter (qui gratte) nvidia-smiCette solution de repli est envisageable si vous ne souhaitez pas utiliser la chaîne de dépendances de DCGM. Pour les modèles Pro 6000 Blackwell, L40 et L4 (et tout autre produit de la gamme datacenter/professionnelle), utilisez DCGM et non son interface.

node_exporter — la moitié du système

Les indicateurs GPU ne révèlent que la moitié de l'histoire. node_exporter couvre le reste :

Le mode de défaillance « mémoire vive système épuisée, processus OOM killer prend en charge vLLM, redémarrage propre du conteneur » est détecté ici, et non par DCGM. Regardez. node_memory_MemAvailable_bytes et une alarme se déclenche lorsque le pourcentage descend en dessous de 5 % du total. Sous Linux, le processus s'arrête par défaut aux alentours de 0 %, mais à ce moment-là, il est déjà terminé.

Prometheus — configuration, rétention, dimensionnement

Prometheus est une base de données de séries temporelles qui orchestre également l'extraction de données. Les paramètres par défaut sont convenables ; les deux paramètres à modifier dès le départ sont l'intervalle d'extraction et la durée de conservation.

Un intervalle de collecte de données de 15 secondes constitue un bon point de départ pour un serveur d'IA : suffisamment court pour détecter un pic de surchauffe avant qu'il ne se prolonge, et suffisamment long pour que le coût sur la série temporelle reste modeste. La durée de conservation par défaut est de 15 jours ; 30 jours sont plus appropriés dans le cadre d'un guide de configuration, où vous pouvez comparer le comportement actuel avec les modifications apportées le mois précédent.

Budget de stockage pour une collecte de données de 15 secondes, environ 80 métriques DCGM × N GPU + environ 400 métriques node_exporter + environ 50 métriques vLLM : environ 1.5 à 2 Go par semaine, soit 6 à 10 Go sur 30 jours pour une machine à 8 GPU. Définissez des seuils de rétention à la fois par durée et par taille.

command:
  - "--storage.tsdb.retention.time=30d"
  - "--storage.tsdb.retention.size=20GB"

La compression s'effectue dès que la limite est atteinte ; la première atteinte est prise en compte. Une allocation de 100 Go vous offre plus d'un an de marge sans vous en soucier.

Tableaux de bord Grafana — commencez par les modèles préconfigurés

Ne créez pas de tableaux de bord à partir de zéro. La communauté l'a déjà fait.

Importez d'abord les fichiers 12239 et 1860. Ils couvrent environ 90 % des informations que vous souhaitez consulter et ont été perfectionnés au fil des ans. Ne créez votre propre configuration qu'après un mois, lorsque vous saurez quels panneaux vous utilisez réellement. Les modifications mineures à apporter pour le matériel Kentino AI sont les suivantes : configurer les panneaux de seuil de température du GPU sur des plages appropriées à Blackwell (la 5090 se bride aux alentours de 87 °C, la RTX Pro 6000 aux alentours de 90 °C) et ajouter un panneau par emplacement PCIe. DCGM_FI_DEV_PCIE_LINK_GEN et DCGM_FI_DEV_PCIE_LINK_WIDTH Vous pouvez ainsi voir d'un coup d'œil si une colonne montante est passée de x16 à x8.

Loki — journaux expliquant ce que montrent les indicateurs

Les indicateurs vous le disent est ce que nous faisons modifié ; les journaux vous le disent whyLoki est la base de données de logs de Grafana ; Promtail est le programme qui suit les fichiers et les envoie. Configurez Promtail pour qu'il s'exécute correctement.

• /var/log/syslog et journalctl -k — Messages OOM du noyau, plaintes des pilotes NVIDIA, vidages XID
• /var/log/nvidia-installer.log — état d'installation du pilote
• Sortie standard du conteneur vLLM (via le pilote de journalisation JSON de Docker)
• Journaux d'application de tout ce que le client exécute

La requête la plus pertinente dans l'onglet Explorer de Grafana est :

{job="syslog"} |= "NVRM:"

Cela permet de récupérer tous les messages des pilotes NVIDIA dans le tampon circulaire du noyau : erreurs XID, pannes de ventilateur, déconnexions du bus, délais d’attente RPC GSP. À associer avec… DCGM_FI_DEV_XID_ERRORS Alerte Prometheus : vous disposez à la fois de la métrique structurée et des détails non structurés dans un seul panneau.

Par défaut, nous ne transférons pas les journaux hors serveur. Loki les conserve localement pendant 30 jours ; un tunnel SSH est établi avec Grafana en cas de besoin. Les clients souhaitant centraliser les journaux sur plusieurs serveurs peuvent configurer Loki pour qu'il utilise S3 ou exécuter une instance régionale ; il s'agit d'une question de déploiement, et non d'architecture.

Métriques vLLM et SGLang — instrumentez l’application, pas seulement le matériel.

DCGM indique que le GPU est occupé. Il ne précise pas si les requêtes d'inférence prennent 200 ms ou 2 s. Pour cela, il faut instrumenter la couche serveur.

vLLM expose /metrics nativement sur le même port que l'API OpenAI. Avec les paramètres par défaut, le point de terminaison à :8000/metrics publie les métriques Prometheus avec le vllm: préfixe (qui devient vllm_ (après le grattage de Prometheus). Ceux qui valent la peine d'être grattés :

La combinaison vllm:num_requests_waiting > 0 et DCGM_FI_DEV_GPU_UTIL < 90% Cela signifie que la file d'attente s'accumule pendant que le GPU est inactif ; il s'agit généralement d'un goulot d'étranglement au niveau du tokenizer ou du planificateur, et non d'un problème de calcul. Ce phénomène n'est visible que lorsque les deux indicateurs sont affichés sur le même tableau de bord, ce qui constitue l'objectif principal de l'unification de la télémétrie applicative et matérielle dans Prometheus.

NVIDIA NIM expose les mêmes métriques vLLM sous /v1/metrics Sans les renommer, vos tableaux de bord vLLM et règles d'alerte existants seront transférés sans modification vers un déploiement NIM. SGLang publie un ensemble similaire sur son propre port (30000 par défaut) ; le serveur HTTP de llama.cpp expose un sous-ensemble plus restreint. Triton publie sa propre taxonomie. Quel que soit le système utilisé, collectez les données de l'application, et non seulement celles du matériel.

Règles Alertmanager — celles que nous expédions

Les tableaux de bord sont esthétiques. Les alertes sont utiles. Les règles ci-dessous sont celles qui ont permis de détecter de véritables problèmes sur du matériel client réel.

groups:
  - name: gpu
    interval: 30s
    rules:
      - alert: GPUTempCritical
        expr: DCGM_FI_DEV_GPU_TEMP > 87
        for: 30s
        labels: { severity: critical }
        annotations:
          summary: "GPU {{ $labels.gpu }} thermal critical ({{ $value }} °C)"

      - alert: GPUThermalThrottling
        expr: rate(DCGM_FI_DEV_THERMAL_VIOLATION[5m]) > 0
        for: 1m
        labels: { severity: warning }

      - alert: GPUECCUncorrectable
        expr: increase(DCGM_FI_DEV_ECC_DBE_VOL_TOTAL[10m]) > 0
        labels: { severity: critical }
        annotations:
          summary: "GPU {{ $labels.gpu }} uncorrectable ECC — schedule replacement"

      - alert: GPUXIDError
        expr: increase(DCGM_FI_DEV_XID_ERRORS[5m]) > 0
        labels: { severity: critical }

      - alert: GPUPowerEnvelopeExceeded
        expr: DCGM_FI_DEV_POWER_USAGE > 590  # 5090 nominal 575 W; alarm above sustained ceiling
        for: 5m
        labels: { severity: warning }

      - alert: GPUIdleDuringWork
        expr: DCGM_FI_DEV_GPU_UTIL < 5 and DCGM_FI_DEV_FB_USED > 1024
        for: 10m
        labels: { severity: warning }
        annotations:
          summary: "GPU {{ $labels.gpu }} idle with VRAM allocated — likely hung"

  - name: system
    interval: 30s
    rules:
      - alert: HostMemoryLow
        expr: (node_memory_MemAvailable_bytes / node_memory_MemTotal_bytes) < 0.05
        for: 2m
        labels: { severity: critical }

      - alert: OOMKillerFired
        expr: increase(node_vmstat_oom_kill[5m]) > 0
        labels: { severity: critical }

      - alert: ContainerRestartLoop
        expr: rate(container_start_time_seconds[15m]) > 3
        for: 10m
        labels: { severity: warning }

  - name: serving
    interval: 30s
    rules:
      - alert: vLLMQueueBacklog
        expr: vllm:num_requests_waiting > 10
        for: 5m
        labels: { severity: warning }

      - alert: vLLMHighLatency
        expr: histogram_quantile(0.95, rate(vllm:e2e_request_latency_seconds_bucket[5m])) > 10
        for: 5m
        labels: { severity: warning }

Des décisions subjectives dans ces règles :

• 87 °C, température critique pour le GPU. La 5090 atteint sa température minimale aux alentours de 80 °C sur la plupart des cartes mères. Si votre pièce ne parvient pas à maintenir les cartes à une température inférieure à 80 °C en charge soutenue, le problème vient de votre système de climatisation, et non du logiciel.
• Toute notification ECC non corrigible appelle le service d'astreinte. Un seul événement ECC double bit invalide le contenu de cette page VRAM : une étape d'apprentissage est erronée, un résultat d'inférence est incorrect. La carte doit être remplacée, pas redémarrée.
• GPUIdleDuringWork Il s'agit du détecteur d'interblocage. Une allocation supérieure à 1 Gio et une utilisation inférieure à 5 % pendant 10 minutes indiquent un blocage. Il détecte les blocages côté CUDA que l'application ignore sans problème.
• L'alerte OOM killer est la règle la plus souvent négligée lors de tout déploiement. Linux qui interrompt discrètement votre formation et Docker qui la redémarre proprement, c'est… le Le mode de défaillance qui engendre le plus de gaspillage d'heures de travail des ingénieurs par an. Signalez-le haut et fort.
• La boucle de redémarrage du conteneur intercepte les cycles de redémarrage de NIM et vLLM qui semblent fonctionner correctement de l'extérieur (le conteneur est « en cours d'exécution ») mais qui plantent en réalité à chaque chargement de modèle.

Châssis et stockage — IPMI et SMART

DCGM s'arrête au niveau du GPU. node_exporter s'arrête au niveau du système d'exploitation. Le reste du châssis (ventilateurs, alimentations, température ambiante, état du stockage) nécessite deux exportateurs supplémentaires.

ipmi_exporter (prometheus-community) communique avec le BMC via IPMI/RMCP et fournit des données télémétriques au niveau du châssis : vitesse de rotation de chaque ventilateur, tension et courant d'entrée de l'alimentation, entrées du journal des événements système, température ambiante d'entrée, état du chien de garde du BMC. Sur un châssis Supermicro ou Bone64c avec un BMC fonctionnel, cela représente une demi-journée de travail et permet de détecter des problèmes que DCGM ne peut pas voir : une alimentation défaillante sur une configuration à 8 GPU avec deux alimentations se traduit par une chute de tension dans les données du capteur IPMI, quelques minutes avant qu'un GPU ne passe à l'identifiant XID 79. Exécutez-le sur l'hôte (il nécessite /dev/ipmi0) ou à distance avec des informations d'identification BMC stockées en utilisant le modèle d'exportateur multi-cible.

smartctl_exporter (ou les plus anciens) smart_exporter) lit les attributs SMART NVMe et SATA : indicateur d’usure du support, espace de stockage disponible, température, nombre d’erreurs. Les charges de travail d’IA sont extrêmement exigeantes pour les disques NVMe : les chargeurs de jeux de données, les écritures de points de contrôle et les caches Hugging Face atteignent les objectifs d’usure des disques d’entreprise en quelques mois seulement, même pour les disques grand public. Le paramètre à surveiller est : nvme_available_spare tomber en dessous de 20 % et nvme_percentage_used (L'indicateur d'usure) dépasse les 80 %. Une panne de disque dur est la deuxième panne matérielle la plus fréquente sur un serveur d'IA très sollicité, après une panne de la carte d'extension/du bloc d'alimentation.

Un déploiement complet de la surveillance par IA Kentino inclut les deux. Le coût marginal se compte en minutes ; la valeur ajoutée, dès la première panne silencieuse d’un ventilateur ou lorsque le débit d’air maximal d’un Samsung 990 Pro est atteint, se chiffre en heures.

Un véritable docker-compose pour la machine virtuelle de gestion

Ce que nous déployons réellement sur le boîtier de gestion. Ajuster host.docker.internal (ou utilisez le nom d'hôte/l'adresse IP du serveur GPU) pour indiquer à Prometheus les ports d'exportation de l'hôte GPU.

version: "3.8"

networks:
  monitoring: { driver: bridge }

volumes:
  prometheus_data:
  grafana_data:
  loki_data:

services:
  prometheus:
    image: prom/prometheus:v3.0.0
    restart: unless-stopped
    volumes:
      - ./prometheus.yml:/etc/prometheus/prometheus.yml:ro
      - ./rules:/etc/prometheus/rules:ro
      - prometheus_data:/prometheus
    command:
      - "--config.file=/etc/prometheus/prometheus.yml"
      - "--storage.tsdb.path=/prometheus"
      - "--storage.tsdb.retention.time=30d"
      - "--storage.tsdb.retention.size=20GB"
      - "--web.enable-lifecycle"
    ports: ["9090:9090"]
    networks: [monitoring]

  grafana:
    image: grafana/grafana:11.4.0
    restart: unless-stopped
    environment:
      - GF_SECURITY_ADMIN_PASSWORD__FILE=/run/secrets/grafana_pw
      - GF_USERS_ALLOW_SIGN_UP=false
    volumes:
      - grafana_data:/var/lib/grafana
      - ./grafana/provisioning:/etc/grafana/provisioning:ro
    secrets: [grafana_pw]
    ports: ["3000:3000"]
    networks: [monitoring]

  alertmanager:
    image: prom/alertmanager:v0.28.0
    restart: unless-stopped
    volumes:
      - ./alertmanager.yml:/etc/alertmanager/alertmanager.yml:ro
    ports: ["9093:9093"]
    networks: [monitoring]

  loki:
    image: grafana/loki:3.3.0
    restart: unless-stopped
    command: -config.file=/etc/loki/loki.yml
    volumes:
      - ./loki.yml:/etc/loki/loki.yml:ro
      - loki_data:/loki
    ports: ["3100:3100"]
    networks: [monitoring]

secrets:
  grafana_pw: { file: ./secrets/grafana_pw.txt }

Sur le serveur GPU lui-même (composition séparée, sur le serveur GPU) :

services:
  dcgm-exporter:
    image: nvcr.io/nvidia/k8s/dcgm-exporter:4.5.1-4.8.0-ubuntu22.04
    restart: unless-stopped
    runtime: nvidia
    environment: [NVIDIA_VISIBLE_DEVICES=all]
    cap_add: [SYS_ADMIN]
    ports: ["9400:9400"]

  node-exporter:
    image: prom/node-exporter:v1.9.0
    restart: unless-stopped
    pid: host
    volumes:
      - /proc:/host/proc:ro
      - /sys:/host/sys:ro
      - /:/rootfs:ro
    command:
      - "--path.procfs=/host/proc"
      - "--path.sysfs=/host/sys"
      - "--path.rootfs=/rootfs"
    ports: ["9100:9100"]

  ipmi-exporter:
    image: prometheuscommunity/ipmi-exporter:v1.10.0
    restart: unless-stopped
    privileged: true
    volumes: ["/dev/ipmi0:/dev/ipmi0"]
    ports: ["9290:9290"]

  smartctl-exporter:
    image: prometheuscommunity/smartctl-exporter:v0.13.0
    restart: unless-stopped
    privileged: true
    ports: ["9633:9633"]

  promtail:
    image: grafana/promtail:3.3.0
    restart: unless-stopped
    volumes:
      - /var/log:/var/log:ro
      - ./promtail.yml:/etc/promtail/promtail.yml:ro
    command: -config.file=/etc/promtail/promtail.yml

Configuration de la récupération Prometheus sur la machine virtuelle de gestion :

global:
  scrape_interval: 15s
  evaluation_interval: 15s

rule_files:
  - /etc/prometheus/rules/*.yml

alerting:
  alertmanagers:
    - static_configs:
        - targets: ["alertmanager:9093"]

scrape_configs:
  - job_name: dcgm
    static_configs:
      - targets: ["k-ai-01.lan:9400", "k-ai-02.lan:9400"]

  - job_name: node
    static_configs:
      - targets: ["k-ai-01.lan:9100", "k-ai-02.lan:9100"]

  - job_name: ipmi
    static_configs:
      - targets: ["k-ai-01.lan:9290", "k-ai-02.lan:9290"]

  - job_name: smart
    static_configs:
      - targets: ["k-ai-01.lan:9633", "k-ai-02.lan:9633"]

  - job_name: vllm
    metrics_path: /metrics
    static_configs:
      - targets: ["k-ai-01.lan:8000"]

Il s'agit d'une configuration fonctionnelle pour un laboratoire de un à trois serveurs. Au-delà de quatre ou cinq serveurs, basculez la configuration de récupération Prometheus vers la découverte de services basée sur les fichiers ou, si vous utilisez Kubernetes, vers le graphique Helm de l'exportateur DCGM intégré à l'opérateur GPU et l'opérateur Prometheus. ServiceMonitor CRD.

OpenTelemetry, Pixie, eBPF — le tableau de 2026

Une petite précision concernant les éléments en mouvement, car la question revient toujours.

OpenTélémétrie OTel est la norme CNCF pour l'instrumentation d'observabilité, et début 2026, les trois types de signaux (métriques, traces, journaux) sont stables. Le pipeline OTel Collector remplace les agents spécifiques aux fournisseurs dans de nombreuses organisations en tant que routeur de télémétrie universel. Pour un serveur d'IA, la solution pragmatique en 2026 est la suivante : conserver Prometheus pour les métriques (DCGM-exporter et node_exporter communiquent nativement avec Prometheus, et PromQL est le langage utilisé pour vos règles d'alerte), et ajouter un OTel Collector uniquement lorsque vous avez besoin d'un traçage distribué sur un graphe de service d'inférence (requête → passerelle API → vLLM → appel d'outil → base de données vectorielle → réponse). Pour une installation sur un seul serveur avec un seul modèle derrière nginx, OTel engendre des coûts supplémentaires sans valeur ajoutée. Les 71 % d'organisations qui utilisent les deux solutions emploient Prometheus pour les métriques et OTel pour les traces d'application — une répartition judicieuse.

Pixie est un outil d'observabilité natif de Kubernetes qui utilise eBPF pour collecter des métriques, des traces et des journaux au niveau du noyau sans modification du code. Le développement à suivre en 2026 est le travail sur eBPF sur GPU (bpftime, eGPULes modules noyau ouverts de NVIDIA (DCGM) étendent l'instrumentation eBPF aux noyaux GPU via l'injection PTX à l'exécution. Cette technologie est actuellement réservée à la recherche et n'est pas intégrée à nos solutions de production. Pour l'instant, DCGM est la solution recommandée.

Profilage continu Grafana Phlare et Pyroscope constituent un troisième module complémentaire intéressant. Pour les charges de travail d'inférence où vous contrôlez le code du framework (correctifs vLLM personnalisés, optimisations du tokenizer), il vous indique quelles fonctions consomment le plus de ressources CPU. Pour le simple déploiement de modèles avec des conteneurs standard, il est superflu.

Ce qui casse (édition de surveillance)

Modes de défaillance prévisibles de la pile elle-même, classés par fréquence d'apparition :

• Le disque de Prometheus est plein. La durée de rétention par défaut est de 15 jours ; nous la paramétrons à 30 jours avec une limite de 20 Go. Au-delà de 60 jours sur un serveur très sollicité, prévoyez une marge de plusieurs dizaines de Go. Configurez la durée de rétention en fonction du temps et de la taille des données.
• L'exportateur DCGM perd des GPU après une mise à jour du pilote. Symptôme : tous les panneaux GPU deviennent noirs. Solution : redémarrer le conteneur ; relancer la commande. nvidia-ctk runtime configure si l'exécution a changé.
• Alertmanager n'est pas configuré pour le récepteur que vous utilisez. On installe Prometheus et Grafana, on oublie de configurer Alertmanager pour qu'il envoie des alertes par e-mail ou Slack, et on découvre six mois plus tard qu'aucune alerte n'a été déclenchée. Testez en déclenchant volontairement les alertes. GPUTempCritical avec une charge de travail stressante, ou utiliser amtool alert add déclencher une alerte synthétique dès le premier jour.
• Explosion de cardinalité due aux étiquettes par requête. Ne pas étiqueter les métriques vLLM avec user_id or request_idPrometheus n'est pas conçu pour cela — vous allez saturer la base de données.
• Fuite du mot de passe Grafana via l'environnement Compose. Utilisez les secrets Docker, pas GF_SECURITY_ADMIN_PASSWORD dans le bloc environnement. docker inspect et les journaux divulguent des valeurs d'environnement.
• Jauge XID qui ne se réinitialise pas. Comme indiqué, la jauge XID de l'exportateur DCGM peut rester bloquée sur la dernière valeur enregistrée après la récupération. Combinez cette mesure avec celle de Loki. NVRM: Afficher la trace syslog pour éviter un faux sentiment de confiance.

Le point de vue honnête

La plupart des laboratoires installent Grafana une seule fois, créent un tableau de bord que l'équipe admire pendant une semaine, puis l'oublient. Ce tableau de bord est un objet satisfaisant, mais il ne permet pas de déceler les problèmes. Les alertes permettent de détecter les problèmes. Configurez Alertmanager avec un système de réception fiable (e-mail, Slack, PagerDuty) et un petit ensemble de règles de haute précision (température du GPU, ECC double bit, XID, gestionnaire de mémoire insuffisante, boucle de redémarrage des conteneurs) et optimisez-les pour qu'elles ne se déclenchent qu'en cas de problème réel. Commencez par cette étape. Ensuite, créez des tableaux de bord pour le débogage post-incident.

L'autre aspect de la question, en toute honnêteté : sur un serveur Kentino unique, vous recevrez une alerte de ce système environ une fois par mois, et la plupart du temps, il s'agira d'une fausse alerte que vous ignorerez. C'est le fonctionnement normal du système. Son véritable intérêt réside dans l'alerte déclenchée le jour où une carte d'extension commence à surchauffer, deux jours avant que la carte n'atteigne le niveau XID 79, ce qui laisse encore le temps de reconnecter un câble au lieu de renvoyer une carte graphique en SAV. Ce seul événement justifie à lui seul l'investissement dans la surveillance, et même bien plus.

---

Ceci fait partie du Kentino Wiki, une série de référence sur l'intelligence artificielle, la robotique et les systèmes qui les connectent. Commentaires et corrections bienvenus. info@kentino.com.