VictoriaMetrics pour l'observabilité des LLM

Mode de lecture

IngénieurDécideur

Où se situe ce contenu

1. 1. DécouvrirL’IA en coupeles cinq couches, où chercher
2. 2. ComprendreComprendre l’observabilité de l’IA générativeconcepts et définitions
3. 3. PratiquerObservabilité des LLM : les labsles mains dans le cambouis, sur une pile autohébergée
4. 4. Mettre en productionLes playbooks, puis VictoriaMetrics pour les LLM (vous êtes ici)pile de production, conventions OpenTelemetry, licences
5. 5. MaîtriserMéthode d’observabilité GenAISLO de qualité, impact chiffré, conformité, RACI
6. 6. Aller au-delàAu-delà du LLM : GPU et qualité des modèlesinfrastructure GPU, ML classique, dérive statistique

Cette formation complète l’étape « Mettre en production » : elle traite un composant de la pile de production (le backend de métriques) et se suit après les labs et les playbooks de déploiement.

Public : ingénieurs SRE, plateforme et MLOps, architectes observabilité. Prérequis : bases de Prometheus (types de métriques, PromQL), Docker Compose, un peu de Python. Objectif : exploiter VictoriaMetrics comme backend de métriques de production pour des charges LLM et RAG, du premier déploiement jusqu’aux alertes et aux SLO.

Ce guide décrit une mise en place concrète : OpenTelemetry Collector et vmagent pour la collecte, VictoriaMetrics pour le stockage, MetricsQL pour les requêtes, Grafana pour les tableaux de bord, vmalert et Alertmanager pour les alertes. L’architecture peut être déployée dans un environnement isolé (air-gap).

Cette formation reprend et corrige mon guide « VictoriaMetrics as an LLM Observability Backend » (version 3). Les leçons signalent, dans des encadrés, les points corrigés par rapport à cette première version. Les travaux pratiques s’appuient sur le lab public VMLLM de la forge.

Objectifs pédagogiques

À l’issue de ce guide, vous saurez :

• déployer VictoriaMetrics en mode Single pour un environnement de développement LLM ;
• choisir entre les modes Single et Cluster selon votre charge LLM réelle ;
• configurer la chaîne OTel Collector vers VictoriaMetrics pour collecter les métriques LLM ;
• instrumenter une application Python/FastAPI pour qu’elle émette les bonnes métriques LLM ;
• écrire les requêtes MetricsQL des principaux cas d’usage (coût, qualité, latence, GPU) ;
• construire un tableau de bord Grafana LLM en quatre rangées fonctionnelles, avec des alertes en temps réel ;
• configurer vmalert avec des règles d’alerte de niveau production pour les dégradations LLM ;
• optimiser la rétention, le stockage et les règles d’enregistrement pour réduire les coûts d’infrastructure.

Sommaire

1. Pourquoi VictoriaMetrics, architecture et mode de déploiement : le profil des métriques LLM, la comparaison avec Prometheus, Thanos et Mimir, l’architecture VM + OTel, Single ou Cluster.
2. Installation et configuration : pile Docker Compose, OTel Collector avec le connecteur spanmetrics, collecte par vmagent.
3. Métriques et instrumentation : taxonomie des métriques LLM, nommage, cardinalité, instrumentation Python.
4. MetricsQL et tableaux de bord : requêtes de coût, de qualité, de latence et GPU, provisionnement et panneaux Grafana.
5. Alertes, règles d’enregistrement et SLO : jeu de règles vmalert, routage Alertmanager, règles d’enregistrement, budget d’erreur et taux de consommation.
6. Exploitation : rétention et réglages, sécurité et air-gap, migration depuis Prometheus, scénarios illustratifs, FAQ.
7. Labs, checklist et aide-mémoire : quatre travaux pratiques, checklist de mise en production, aide-mémoire MetricsQL, références.
8. Glossaire.

Notation des options

Les composants VictoriaMetrics (victoria-metrics, vmagent, vmalert, vmauth) documentent leurs options avec un seul tiret, par exemple -retentionPeriod. Le double tiret fonctionne aussi. Ce guide utilise partout le tiret simple. vmctl fait exception : c’est un outil en ligne de commande distinct, dont les options s’écrivent avec un double tiret.

Noms des métriques et conventions GenAI

Ce cours nomme ses métriques applicatives llm_* et rag_* et les émet avec le client Prometheus. Ce ne sont pas les noms des conventions sémantiques OpenTelemetry GenAI, dont l’état et l’historique sont tenus dans l’article, section 2. Le principe de correspondance : les grandeurs sont les mêmes, les noms et les unités diffèrent. Si votre pile reçoit aussi des métriques gen_ai.* d’une instrumentation OpenTelemetry, retenez une seule source par grandeur et faites la traduction au Collector ou dans des règles d’enregistrement plutôt que dans chaque tableau de bord. Les noms du cours restent inchangés : ils sont alignés sur le code du lab.

Métrique du cours	Équivalent dans les conventions GenAI	Remarque
llm_requests_total	nombre d’observations de l’histogramme gen_ai.client.operation.duration	le statut d’échec y est porté par error.type
llm_request_duration_ms	gen_ai.client.operation.duration	les conventions mesurent en secondes
llm_ttft_ms	gen_ai.client.operation.time_to_first_chunk (côté client) ou gen_ai.server.time_to_first_token (côté serveur)	en secondes
llm_tokens_total{type}	gen_ai.client.token.usage ventilé par gen_ai.token.type ; sur la branche principale non publiée du dépôt GenAI, gen_ai.client.inference.usage.input_tokens et gen_ai.client.inference.usage.output_tokens	voir l’article, section 2.1
llm_errors_total	attribut error.type des métriques de durée
llm_cost_usd_total	aucun : le coût ne fait pas partie des conventions	métrique applicative, à garder
rag_*	aucune métrique ; spans retrieval avec gen_ai.data_source.id et gen_ai.retrieval.top_k	métriques applicatives
étiquettes model, provider	attributs gen_ai.request.model, gen_ai.provider.name

Pour aller plus loin

• Comprendre l’observabilité de l’IA générative : les concepts et les définitions.
• Observabilité des LLM : les labs : la pratique sur une pile autohébergée.
• Observer un système LLM : les playbooks de déploiement et les conventions OpenTelemetry GenAI.
• Méthode d’observabilité GenAI : SLO de qualité, impact chiffré, conformité.

Révisé le 4 octobre 2026 : page passée en MDX avec l’encart de progression, positionnement dans la pile de production, correspondance entre les métriques llm_* et les conventions GenAI, liens vers le guide, les labs, l’article et la méthode.

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

BusinessValeur, coût, risque

Les métriques de coût, conservées sur plusieurs années, alimentent la refacturation interne et l'audit des dépenses d'IA.

OrganisationQui décide, qui possède

Le choix entre instance unique et cluster, la rétention et l'accès multi-clients sont des décisions de gouvernance autant que techniques.

HumainÉquipes, astreinte, compétences

Des règles d'alerte avec procédure et seuil justifié, plutôt qu'un mur de seuils, préservent l'astreinte.

MétiersProduit, finance, risque, relation client

Des tableaux de bord en lecture seule pour la direction et la finance, sur les mêmes données que l'exploitation.

Pourquoi des passerelles →