Pourquoi VictoriaMetrics, architecture et mode de déploiement

Module 1 : pourquoi VictoriaMetrics pour les charges LLM

1.1 La difficulté propre aux métriques LLM

Les charges LLM en production produisent un profil de métriques atypique, qui pousse les backends de supervision classiques dans leurs retranchements.

Caractéristique LLM	Impact sur le backend de métriques
Forte cardinalité	modèle x fournisseur x tenant x pipeline donne vite des milliers de séries temporelles et chaque intervalle d’histogramme multiplie ce nombre.
Histogrammes de tokens	Distributions très larges (de 10 à 100 000 tokens par requête), avec des intervalles (buckets) très étalés.
Métriques de coût en USD	Métriques financières qui exigent une précision en virgule flottante et des agrégations par période comptable.
Rétention longue	Audits de coûts et SLA contractuels : une rétention d’un à trois ans peut être exigée.
Pics d’ingestion	Un lot de complétions peut multiplier le débit d’écriture normal en quelques secondes ; l’ampleur du pic dépend de la taille du lot et de l’intervalle de collecte.
Métriques de qualité RAG	Flottants, distributions, scores : beaucoup d’écritures, lectures fréquentes pour l’alerte.

1.2 VictoriaMetrics face à Prometheus, Thanos et Mimir

Prometheus seul stocke ses données sur le disque local d’une instance. Pour une rétention longue, la haute disponibilité ou le multi-tenant, on lui adjoint en général un stockage distant : Thanos, Grafana Mimir (dérivé de Cortex) ou VictoriaMetrics. La comparaison utile oppose donc ces options entre elles, sur des critères vérifiables.

Critère	Prometheus seul	Prometheus + Thanos	Grafana Mimir	VictoriaMetrics
Déploiement	Binaire unique	Prometheus plus plusieurs composants Thanos (sidecar ou receive, querier, store gateway, compacteur)	Microservices, ou mode monolithique en un seul binaire	Binaire unique (Single), ou trois composants (vminsert, vmselect, vmstorage) en Cluster
Stockage et rétention longue	Disque local, non répliqué (rétention par défaut : 15 jours)	Stockage objet (S3, GCS, Azure…) ; sous-échantillonnage par le compacteur	Stockage objet	Disque local ou bloc, rétention par instance (-retentionPeriod) ; sauvegardes vers un stockage objet avec vmbackup ; sous-échantillonnage réservé à l’édition Enterprise
Haute disponibilité	Deux instances identiques, sans dédoublonnage natif	Dédoublonnage au moment de la requête	Réplication à l’ingestion	Deux instances alimentées par vmagent (Single) ; facteur de réplication en Cluster
Multi-tenant	Non	Oui, avec Receive	Natif	Natif en Cluster (accountID)
Langage de requête	PromQL	PromQL	PromQL	MetricsQL, largement compatible avec PromQL, avec des extensions (median_over_time, rollup_candlestick, outliers_mad…)
Réception OTLP	Récepteur OTLP (expérimental depuis 2.47, intégré à Prometheus 3.x)	Via Prometheus ou un Collector	Point OTLP natif	Point OTLP sur le port HTTP : /opentelemetry/v1/metrics sur le port 8428 (Single), /insert/<accountID>/opentelemetry/v1/metrics sur vminsert (Cluster)
Licence	Apache 2.0	Apache 2.0	AGPL 3.0	Apache 2.0 (Single et Cluster) ; édition Enterprise sous licence commerciale (filtres de rétention, sous-échantillonnage, vmanomaly, mTLS de vmauth…)
Compatibilité	Référence	API de requête Prometheus	API de requête et d’écriture Prometheus	API de requête et d’écriture Prometheus : la plupart des tableaux de bord existants fonctionnent sans modification

Les offres hébergées (Grafana Cloud, Amazon Managed Service for Prometheus, Google Cloud Managed Service for Prometheus, l’offre cloud de VictoriaMetrics, entre autres) reprennent ces moteurs ou des API compatibles ; elles déplacent la question vers le coût par série et la localisation des données.

Ce que disent les chiffres publiés. La documentation de Prometheus indique un stockage moyen de 1 à 2 octets par échantillon (prometheus.io, Storage, consulté le 2 octobre 2026). Selon l’éditeur, VictoriaMetrics consomme « jusqu’à 7 fois moins de RAM » que Prometheus, Thanos ou Cortex en forte cardinalité (des millions de séries uniques) et demande « jusqu’à 7 fois moins d’espace disque » que ces mêmes outils (documentation VictoriaMetrics, consultée le 2 octobre 2026). Ces deux chiffres viennent d’un banc d’essai publié par l’éditeur lui-même, qui comparait Prometheus 2.22.2 et VictoriaMetrics 1.47.0 sur des métriques node_exporter (article de l’éditeur). Ce sont des maxima obtenus sur une charge précise, avec des versions anciennes : mesurez sur votre propre charge, avec les versions que vous comptez exploiter, avant tout dimensionnement.

Corrections par rapport à la première version de ce guide

La première version de ce guide comparait VictoriaMetrics au seul Prometheus, avec des chiffres non sourcés. Elle présentait aussi anomaly_score comme une fonction MetricsQL et plaçait le point d’entrée OTLP de VictoriaMetrics sur un port 4318 dédié. anomaly_score est une métrique produite par vmanomaly (composant Enterprise) puis interrogée dans VictoriaMetrics ; ce n’est pas une fonction MetricsQL. VictoriaMetrics accepte OTLP sur le chemin /opentelemetry/v1/metrics de son port HTTP habituel (8428 en mode Single). Le port 4318 est celui de l’OTel Collector pour OTLP/HTTP. Enfin, Prometheus ingère désormais OTLP sans passer par un Collector.

Module 2 : architecture complète VM + OTel pour les LLM

2.1 Vue d’ensemble

L’architecture couvre tout le chemin des métriques, des sources LLM jusqu’aux tableaux de bord et aux alertes. Elle peut être déployée dans un environnement totalement isolé. En résumé, elle enchaîne les étapes suivantes :

Étape	Composants	Ce qui se passe
Sources	Application LLM (SDK OTel), vLLM, Ollama, LiteLLM, DCGM exporter	Émettent métriques et traces, ou exposent un point /metrics
Collecte	OTel Collector, vmagent	Reçoivent OTLP, collectent les points Prometheus, enrichissent, dérivent des métriques à partir des traces
Stockage	VictoriaMetrics (Single ou Cluster)	Stocke les séries, sert MetricsQL, héberge vmui
Règles	vmalert, éventuellement vmanomaly	Évalue les règles d’alerte et d’enregistrement, réécrit les résultats
Consommation	Grafana, Alertmanager	Tableaux de bord, routage des alertes

Points clés de l’architecture :

• Les sources instrumentées émettent vers l’OTel Collector en OTLP (gRPC sur le port 4317 ou HTTP sur le port 4318).
• Le Collector filtre, enrichit (labels Kubernetes), dérive des métriques à partir des traces (connecteur spanmetrics) et exporte.
• VictoriaMetrics reçoit les données par remote write Prometheus. Il accepte aussi OTLP directement sur HTTP, en mode Single comme en mode Cluster.
• vmalert évalue les règles MetricsQL et envoie les alertes à Alertmanager.
• Grafana utilise VictoriaMetrics comme source de données (plugin VictoriaMetrics ou source Prometheus standard).
• vmanomaly (Enterprise) ajoute la détection d’anomalies sur les métriques LLM.

2.2 Composants et rôles

Composant	Port(s)	Rôle pour l’observabilité LLM
OTel Collector	4317 (gRPC), 4318 (HTTP)	Normalise et route toutes les métriques. Le connecteur spanmetrics dérive des métriques des traces RAG.
VictoriaMetrics Single	8428	Stockage TSDB, API MetricsQL, remote write, OTLP direct, vmui intégré
vmagent	8429	Collecte de type Prometheus. Adapté au DCGM exporter, au /metrics de vLLM, à LiteLLM
vmalert	8880	Évalue les règles MetricsQL d’alerte et d’enregistrement, dialogue avec Alertmanager
Alertmanager	9093	Routage des alertes (Slack, PagerDuty, e-mail, webhook), déduplication et mise en sourdine
Grafana	3000	Tableaux de bord, avec le plugin VictoriaMetrics ou la source Prometheus standard
vmanomaly (Enterprise)	voir sa documentation	Détection d’anomalies sur les métriques LLM par modèles statistiques et d’apprentissage. Facultatif.

Module 3 : Single ou Cluster, choisir son mode de déploiement

Le mode Single est un binaire unique qui ingère, stocke et interroge. Le mode Cluster répartit ces rôles entre trois composants : vminsert (ingestion), vmstorage (stockage) et vmselect (requêtes), chacun pouvant être dimensionné et répliqué indépendamment.

3.1 Critères de décision dans un contexte LLM

La documentation de l’éditeur recommande la version Single pour une ingestion inférieure à environ un million de points par seconde et invite à « réfléchir à deux fois » avant de choisir la version Cluster, plus complexe à configurer et à exploiter (documentation du mode Cluster, consultée le 2 octobre 2026). Les charges LLM décrites dans ce guide restent en général très en deçà de ce débit : le choix du Cluster tient alors surtout à la haute disponibilité et au multi-tenant.

Critère	Mode Single	Mode Cluster
Débit d’ingestion	Recommandé sous environ un million de points par seconde (documentation de l’éditeur)	Au-delà, ou quand une seule machine ne suffit plus
Haute disponibilité	Non native (deux instances alimentées par vmagent, ou solutions externes)	Native : réplicas par composant, facteur de réplication
Multi-tenant	Non natif (instances séparées ou vmauth)	Natif (accountID dans les chemins d’API)
Déploiement	1 conteneur, 1 binaire	Trois types de composants à déployer
Rétention	Une rétention globale par instance	Une rétention globale par vmstorage ; la rétention par tenant ou par série exige la version Enterprise (-retentionFilter)
Complexité d’exploitation	Faible	Plus élevée : plusieurs composants à dimensionner et à superviser
Licence	Open source (Apache 2.0)	Open source (Apache 2.0)

Correction : niveaux de rétention

La première version de ce guide affirmait que le mode Cluster offre une rétention « par niveau (chaud, tiède, froid) ». Dans la version open source, chaque vmstorage applique une seule valeur de -retentionPeriod. La rétention par tenant ou par filtre (-retentionFilter) et le sous-échantillonnage (downsampling) sont des fonctionnalités Enterprise. Voir rétention et réglages.

Correction : seuils de passage au Cluster

La première version de ce guide recommandait le mode Single sous 500 000 séries actives et fixait des seuils de requêtes, de nombre de modèles et de RAM. Ces repères n’étaient pas sourcés et contredisaient la recommandation de l’éditeur, fondée sur le débit d’ingestion : ils ont été retirés.

Quand passer de Single à Cluster

Envisagez le Cluster quand l’ingestion approche le million de points par seconde, quand les ressources d’une seule machine ne suffisent plus malgré un dimensionnement vertical, ou quand un SLA de haute disponibilité ou un isolement multi-tenant natif est exigé. Les requêtes, l’API compatible Prometheus et les tableaux de bord Grafana restent identiques.

Correction : procédure de migration

La première version de ce guide proposait de restaurer un instantané (snapshot) de vmstorage sur le nouveau cluster. Les formats de stockage Single et Cluster ne sont pas interchangeables (l’index du cluster porte les identifiants de tenant). La voie documentée consiste à copier les données avec vmctl en mode vm-native, de l’instance Single vers vminsert, pendant que vmagent écrit les nouvelles données vers les deux cibles durant la transition. Cette procédure est conçue pour éviter toute interruption de service.

Marquer comme lue