La pile d'observabilité HPC IA

Métriques, logs et traces dans un cluster d’entraînement

Signal	Contenu	Stockage	Usage
Métriques	utilisation des SM, bande passante HBM, durée de pas, latence NCCL, retransmissions InfiniBand	base de séries temporelles compatible Prometheus : Prometheus avec Thanos ou Mimir, ou VictoriaMetrics	alertes, tendances
Logs	erreurs CUDA, avertissements NCCL, interruptions Slurm, arrêts pour mémoire insuffisante	Loki ou VictoriaLogs	contexte qualitatif que les métriques ne capturent pas
Traces	parcours de bout en bout sur tous les nœuds et processus	Tempo ou Jaeger	savoir sur quel nœud et dans quelle fonction le temps est perdu ; indispensable pour les traînards

Une pile en trois étages

flowchart TB
  subgraph C["Collecte (par nœud)"]
    direction LR
    D["dcgm-exporter (NVIDIA)<br/>ou AMD Device Metrics<br/>Exporter, GPU"]
    NE["node-exporter<br/>CPU, RAM, disque"]
    O["OTel Collector<br/>traces, logs"]
    F["Falco / Tetragon<br/>événements noyau"]
    S["slurm-exporter<br/>jobs, files"]
    I["ibstat + scripts<br/>InfiniBand"]
  end
  subgraph St["Stockage (centralisé)"]
    direction LR
    VM["Prometheus + Thanos ou Mimir,<br/>ou VictoriaMetrics<br/>métriques, 90 j"]
    L["Loki ou VictoriaLogs<br/>logs, 30 j"]
    T["Tempo / Jaeger<br/>traces, 7 j"]
    AM["Alertmanager"]
  end
  subgraph V["Visualisation (Grafana)"]
    direction LR
    V1["Cluster GPU"]
    V2["Réseau et stockage"]
    V3["Entraînement"]
    V4["Sécurité"]
    V5["Jobs Slurm"]
  end
  C --> St --> V

Les durées de rétention sont des valeurs de départ, à ajuster à vos obligations d’audit. Aucun composant n’est propriétaire : tout est open source, autohébergé et auditable et les données ne quittent pas l’infrastructure.

À chaque étage, plusieurs composants open source remplissent le même rôle ; la figure en cite quelques-uns sans en recommander un par défaut. Pour les métriques, Prometheus avec Thanos ou Mimir et VictoriaMetrics se départagent sur les mêmes critères : tenue de la cardinalité (une série par GPU et par rang), rétention longue, haute disponibilité, coût d’exploitation et compétences de l’équipe. Des offres commerciales, comme Grafana Cloud, Datadog ou Dynatrace, couvrent aussi ces besoins ; elles sortent du cadre autohébergé de cette architecture, mais se jugent avec la même grille.

Rattacher au job

En HPC, chaque métrique GPU doit pouvoir être reliée à un job, un utilisateur et un compte. Le label UUID du GPU ne suffit pas : aucune métrique Slurm standard ne porte l’UUID des GPU alloués. Pour les GPU NVIDIA, dcgm-exporter fournit un mécanisme dédié : il lit le répertoire indiqué par l’option --hpc-job-mapping-dir (variable DCGM_HPC_JOB_MAPPING_DIR), où doit se trouver un fichier par GPU, nommé d’après l’identifiant du GPU et contenant l’identifiant du job. L’exportateur se contente de lire ce répertoire : l’écriture des fichiers au début du job et leur retrait à la fin sont à faire par vos propres scripts prolog et epilog Slurm. L’exportateur ajoute alors le label hpc_job aux métriques de ce GPU (documentation de dcgm-exporter). Le rattachement à l’utilisateur et au compte se fait ensuite par l’identifiant de job, avec sacct ou un exportateur Slurm. Pour les GPU AMD, l’AMD Device Metrics Exporter propose une intégration Slurm qui ajoute des labels de job. C’est la base de la refacturation et du diagnostic.

eBPF : observer sans instrumenter

eBPF permet d’attacher des programmes vérifiés par le noyau à des milliers de points d’instrumentation : appels système, fonctions du noyau, événements réseau, accès fichiers et par les uprobes aux fonctions des bibliothèques en espace utilisateur. Le surcoût est faible et le code d’entraînement n’est pas modifié.

Tracer les allocations mémoire CUDA d’un processus (fonction de la bibliothèque libcuda, donc une uprobe et non une kprobe) :

# Le chemin de libcuda dépend de la distribution et du pilote.
bpftrace -e 'uprobe:/usr/lib/x86_64-linux-gnu/libcuda.so.1:cuMemAlloc_v2
  /pid == $1/ { printf("alloc %lu octets\n", arg1); }' <PID>

Détecter les connexions sortantes inattendues d’un processus Python :

bpftrace -e 'kprobe:tcp_connect /comm == "python3" || comm == "pt_main_thread"/ {
  $sk = (struct sock *)arg0;
  printf("%s -> %s\n", comm, ntop($sk->__sk_common.skc_daddr));
}'

Les versions 2.3 et 2.4 de PyTorch renomment le thread principal pt_main_thread (ajout par la PR 121170, retrait avant la 2.5 par la PR 134066) : avec ces versions, un filtre sur python3 seul ne voit pas les processus d’entraînement. Filtrez de préférence par PID (/pid == $1/) ou par cgroup du job (cgroup) plutôt que par nom de processus. Le champ skc_daddr ne couvre que l’IPv4 ; pour l’IPv6, il faut lire skc_v6_daddr.

Surveiller les ouvertures de fichiers dans le répertoire des points de reprise :

bpftrace -e 'tracepoint:syscalls:sys_enter_openat
  /strncmp(str(args->filename), "/checkpoints", 12) == 0/ {
  printf("[%s] ouvre %s\n", comm, str(args->filename));
}'

Ce filtre ne voit que les chemins absolus : un fichier ouvert par un chemin relatif, par exemple checkpoints/step_100.pt depuis le répertoire de travail, lui échappe.

Correction

Une version précédente de ces exemples utilisait kprobe:cuMemAlloc (fonction en espace utilisateur, inaccessible par kprobe), ntop() sur un pointeur de sockaddr et un opérateur startswith qui n’existe pas en bpftrace. Les versions ci-dessus supposent un noyau avec BTF.

En cours de validation en lab

Configuration pas encore exécutée de bout en bout dans un lab : les noms, versions et paramètres peuvent demander des ajustements.

En production, deux outils s’appuient sur eBPF :

• Falco détecte et alerte en temps réel sur les comportements suspects : accès fichiers inhabituels, connexions inattendues, modification de binaires.
• Tetragon (projet Cilium) applique des politiques d’appels système par processus et peut bloquer une opération non autorisée avant qu’elle aboutisse : ioctl CUDA, connexion réseau, lecture de points de reprise.

Les outils de la pile

Outil	Rôle
Prometheus avec Thanos ou Mimir, ou VictoriaMetrics	stockage des métriques compatible Prometheus ; à départager sur la tenue de la cardinalité (par GPU, par rang), la rétention et le coût d’exploitation
dcgm-exporter	métriques des GPU NVIDIA via DCGM : SM, HBM, ECC, NVLink, énergie ; point d’entrée pour les GPU NVIDIA, avec le label hpc_job pour le rattachement au job
AMD Device Metrics Exporter	équivalent pour les GPU AMD (ROCm), avec une intégration Slurm
OpenTelemetry	traces et logs, SDK Python pour PyTorch, protocole OTLP, Collector
Grafana	tableaux de bord corrélant métriques, logs et traces
Loki ou VictoriaLogs	agrégation de logs indexée par labels, efficace pour Slurm, NCCL et Python
Falco	détection comportementale par eBPF
Tetragon	application de politiques d’appels système par eBPF
Slurm	ordonnanceur ; prolog et epilog pour l’instrumentation par job

Révisé le 2 octobre 2026 : rattachement des métriques GPU au job par le label hpc_job de dcgm-exporter (la jointure par UUID ne fonctionne pas), équivalent AMD ajouté, options de stockage des métriques présentées avec les mêmes critères, filtre bpftrace adapté au thread pt_main_thread des versions 2.3 et 2.4 de PyTorch, rôle des scripts prolog et epilog précisé, limites IPv4 et chemins relatifs signalées.

Marquer comme lue