Observabilité HPC : les fondamentaux

Mode de lecture

IngénieurDécideur

État des labs

Les leçons et les labs décrits ici sont en préparation et seront mis en ligne module par module. En attendant, le dépôt public training/hpcobs propose un cluster GPU simulé (labSIM) : exportateurs fictifs DCGM, MIG, NVSwitch, InfiniBand, NCCL, IPMI et inférence, VictoriaMetrics, vmalert, Alertmanager, Grafana et injection de pannes. Il ne contient pas Slurm : il ne couvre pas le rattachement des métriques aux jobs.

Mardi, 2 h 42. L’entraînement vient de mourir.

Scénario illustratif, construit pour la formation.

Quatre heures de calcul sur huit GPU A100, perdues : 32 heures-GPU, à multiplier par le prix horaire de votre fournisseur ou votre coût interne. Les prix changent vite et varient selon les contrats : ce guide n’en donne pas ; utilisez la grille datée de votre fournisseur.

02:42:14  INFO   job 184729 step 14 done
02:42:15  INFO   rank 0  allreduce  init
02:42:16  ERROR  ECC error GPU 3
02:42:17  WARN   retrying step 15
02:42:18  WARN   retrying step 15
02:42:19  INFO   job 184729 terminated, exit 137

Sauriez-vous dire, en cinq minutes, quel GPU a lâché, sur quel nœud et pour quel utilisateur ? Si le matériel se dégradait déjà ? Quel compte vient d’absorber ces 32 heures-GPU ?

Sans corrélation préparée à l’avance, la réponse demande de croiser à la main les journaux du job, les métriques GPU et la comptabilité Slurm. Les données existent, mais elles restent dispersées entre des outils que personne n’a reliés.

Trois forces qui convergent

Force	Pourquoi l’observabilité devient nécessaire
L’échelle de l’IA	un entraînement mobilise des dizaines à des milliers de GPU pendant des jours ou des semaines (ordre de grandeur) ; une dégradation GPU silencieuse fait perdre une part de ce calcul
La pression réglementaire	NIS2 pour les entités concernées ; la directive (UE) 2023/1791 relative à l’efficacité énergétique, dont l’article 12 impose aux centres de données d’au moins 500 kW de puissance informatique installée de déclarer chaque année leur performance énergétique ; les comptes rendus d’usage des allocations de calcul. Les auditeurs demandent qui a fait quoi, quand
La responsabilité multi-clients	refacturation et partage équitable supposent de savoir à quel compte attribuer chaque joule

Ce que le HPC change aux métriques, logs et traces

Métriques, logs et traces restent la base. Le HPC y ajoute trois contraintes. La cardinalité est plus forte, puisqu’on suit chaque GPU et chaque rang. La rétention s’allonge, car les chercheurs comparent volontiers avec des exécutions vieilles de plusieurs années. Enfin, chaque observation doit être rattachée à un job, un utilisateur et un compte, faute de quoi elle ne sert ni à la refacturation ni à l’audit.

Contenu : trois modules et un projet final

Module	Contenu	Lab
M1. Anatomie physique du cluster	les cinq composants et ce qu’ils exposent : node_exporter et placement NUMA, exportateur DCGM et labels UUID des GPU, compteurs de ports InfiniBand ou RoCE, Lustre, IBM Storage Scale (ex-Spectrum Scale), BeeGFS, jobs, comptes et partitions Slurm	L1 : un premier exportateur Redfish en Python, collecté par VictoriaMetrics (ou Prometheus), affiché dans Grafana, avec une alerte thermique déclenchée par injection de panne
M2. Télémétrie des jobs	le rattachement des métriques GPU aux jobs : le prolog et l’epilog Slurm écrivent, pour chaque GPU alloué, l’identifiant du job dans un répertoire que lit dcgm-exporter (option --hpc-job-mapping-dir, variable DCGM_HPC_JOB_MAPPING_DIR) ; les métriques reçoivent alors un label hpc_job. On relie ensuite ce job à son utilisateur et à son compte avec sacct ou un exportateur Slurm, pour une réponse métier : la puissance consommée par compte	L2 : dcgm-exporter avec job mapping et exportateur Slurm côte à côte, jointure PromQL sur l’identifiant de job qui attribue la puissance GPU aux comptes, alerte sur budget énergétique. L3 : détecter la contention entre compute instances d’une même GPU instance MIG, qui partagent la mémoire et la bande passante de cette instance, contention invisible aux métriques d’utilisation standard
M3. Intégration	produire un vrai livrable : pour un cluster GPU de plusieurs centaines de nœuds partagé entre 6 comptes, un tableau de bord qui passe le test des cinq secondes devant un directeur et trois alertes qui ne réveillent l’astreinte que si c’est nécessaire	Projet final : concevoir (6 panneaux maximum), construire dans Grafana et vmalert, valider contre trois pannes injectées, puis défendre en cinq minutes

Chaque lab fournira un fichier de départ, une solution de référence, des validateurs automatiques et des scripts d’injection de panne.

Objectifs

1. Déployer une pile standard de zéro : VictoriaMetrics (ou Prometheus), Grafana, vmalert, Alertmanager.
2. Lire couramment les métriques DCGM et Slurm et connaître les cinq métriques GPU et les six métriques Slurm qui comptent.
3. Écrire un petit exportateur Prometheus en Python, en respectant les conventions de nommage et la discipline des labels.
4. Rattacher des métriques de collecteurs différents à un job, puis à un compte Slurm, pour attribuer la consommation.
5. Concevoir un tableau de bord qui passe le test des cinq secondes devant un interlocuteur non technique.
6. Écrire une règle d’alerte qui ne bat pas, avec une procédure associée et un seuil justifié.

Public et prérequis

Public visé : SRE et ingénieurs plateforme découvrant le HPC, administrateurs HPC modernisant leur supervision, DevOps accueillant des charges IA, équipes de calcul scientifique sous pression d’audit, équipes de cloud souverain préparant une infrastructure IA.

Hors périmètre : la recherche en apprentissage automatique, l’administration de Slurm, les plateformes centrées sur Kubernetes.

Prérequis : ligne de commande Linux, bases de Prometheus ou Grafana. Débutant complet ? Commencez par Comprendre le HPC.

Approfondissements prévus

Suite	Contenu
Instrumentation, réseau, stockage	écrire en Go un exportateur Slurm de production, avec pour objectif de lab de tenir une charge simulée de 5 000 jobs par seconde ; observabilité InfiniBand, Lustre en profondeur, prévision de capacité et d’attente, refacturation complète
Entraînement IA, pile souveraine, AIOps	détection d’anomalies par rang sur un entraînement simulé à 64 rangs avec un autoencodeur, pour attraper un traînard injecté dont le lab fixe la pénalité (par exemple 30 % de débit, paramètre de simulation et non mesure) ; santé des communications collectives, pile isolée du réseau, prédiction de pannes

---

Révisé le 2 octobre 2026 : prix retirés, coût du scénario exprimé en heures-GPU, rattachement des métriques GPU aux jobs décrit avec le job mapping de dcgm-exporter, contention MIG précisée (compute instances d’une même GPU instance), référence à la directive (UE) 2023/1791, IBM Storage Scale, état réel des labs.

PasserellesCe que cette page change au-delà de l'équipe technique.

BusinessValeur, coût, risque

La jointure DCGM et Slurm attribue l'énergie et le calcul à chaque compte : la base de la refacturation et du pilotage des coûts.

OrganisationQui décide, qui possède

Les heures de calcul accordées par les appels à projets nationaux ou européens (EuroHPC) se décomptent par projet : sans rattachement de chaque job à un utilisateur et à un compte, on ne peut ni rendre compte de la consommation d'une allocation, ni arbitrer entre équipes.

HumainÉquipes, astreinte, compétences

Une alerte rattachée à un job et à son utilisateur permet de prévenir l'équipe de recherche concernée au lieu de réveiller toute l'astreinte et de lui expliquer ce qui est arrivé à son calcul.

MétiersProduit, finance, risque, relation client

Le projet final impose un tableau de bord qui passe le test des cinq secondes devant un directeur non technique, puis une soutenance de cinq minutes.

Pourquoi des passerelles →