VictoriaMetrics : la TSDB qui allège votre stack monitoring

Prometheus reste la référence du monitoring cloud-native, mais sa conception monolithique montre ses limites dès qu'on dépasse quelques millions de séries actives. La rétention longue, la haute disponibilité et la mutualisation multi-tenants imposent vite une couche tierce (Thanos, Cortex, Mimir) qui complique l'exploitation.

VictoriaMetrics propose une autre approche : un binaire Go compact, compatible PromQL, capable d'absorber les mêmes charges avec nettement moins de RAM et de disque, déployable en mode single-node ou en cluster horizontalement scalable. Cet article détaille l'architecture, les composants, les chiffres officiels et les cas d'usage où VictoriaMetrics fait la différence.

• Qu'est-ce que VictoriaMetrics
• Architecture : single-node vs cluster
• Les composants de l'écosystème
• Compatibilité PromQL et extension MetricsQL
• Performance : ce que disent les chiffres officiels
• Cas d'usage où VictoriaMetrics fait la différence
• Migration depuis Prometheus
• Limites et points d'attention

VictoriaMetrics est une base de données de séries temporelles open source écrite en Go, distribuée sous licence Apache 2.0. Le projet a été lancé en 2018 par Aliaksandr Valialkin, en s'inspirant de l'architecture colonnaire de ClickHouse pour optimiser le stockage et la performance des requêtes sur les séries temporelles. La première release publique open source date de 2019. La dernière version stable au moment de la rédaction est la v1.142.0, publiée le 28 avril 2026.

Le positionnement est clair : un drop-in replacement de Prometheus pour le stockage long terme, sans imposer une stack distribuée complexe. La base accepte les principaux protocoles d'ingestion (Prometheus remote write, InfluxDB line protocol, Graphite, OpenTSDB, OpenTelemetry, JSON, CSV, format binaire natif) et expose une API HTTP compatible avec celle de Prometheus, ce qui permet de la brancher directement dans Grafana sans modifier les dashboards existants.

Trois éléments distinguent VictoriaMetrics des autres TSDB :

1. Un seul binaire Go pour la version single-node, sans dépendance externe (pas de ZooKeeper, pas d'etcd, pas de cache distribué).
2. Un format de stockage colonnaire dérivé des techniques utilisées dans ClickHouse, optimisé pour la compression et la vectorisation des requêtes.
3. Une compatibilité PromQL native, étendue par MetricsQL pour les fonctions analytiques absentes du langage standard.

Single-node

Le mode single-node est un binaire unique (victoria-metrics-prod) qui assume tous les rôles : ingestion, stockage, requêtage. Il scale verticalement et tient sans difficulté plusieurs millions de séries actives sur un serveur correctement dimensionné. Pour la majorité des déploiements de petite et moyenne taille, c'est l'option recommandée par l'éditeur.

# Lancer une instance single-node
./victoria-metrics-prod \
  -storageDataPath=/var/lib/victoria-metrics \
  -retentionPeriod=12mo \
  -httpListenAddr=:8428

Le port 8428 expose à la fois l'API d'écriture (/api/v1/write, /api/v1/import) et l'API de lecture compatible Prometheus (/api/v1/query, /api/v1/query_range).

Cluster

Le mode cluster scinde le single-node en trois services indépendants, déployables séparément :

• vmstorage : stocke les séries sur disque, gère la rétention et la compaction.
• vminsert : reçoit les écritures, les distribue vers les vmstorage selon un hash cohérent.
• vmselect : reçoit les requêtes PromQL, interroge les vmstorage en parallèle, agrège les résultats.

Cette séparation permet de scaler indépendamment l'ingestion et le requêtage, et de répliquer les données sur N nœuds via le paramètre -replicationFactor. Le cluster supporte le multi-tenancy natif via un préfixe d'URL (/insert/<tenantID>/..., /select/<tenantID>/...), utile pour mutualiser une plateforme entre plusieurs équipes ou clients.

Au-delà du moteur de stockage, VictoriaMetrics fournit une suite d'outils complémentaires :

L'agent vmagent mérite une mention particulière : il consomme bien moins de RAM qu'un Prometheus en mode scrape, supporte le clustering avec sharding automatique des cibles, et peut servir de tampon avec persistance disque en cas de coupure du backend distant. Beaucoup d'équipes l'adoptent pour remplacer leurs agents Prometheus avant même de migrer le stockage.

VictoriaMetrics implémente PromQL avec les ajustements documentés dans la page MetricsQL. La majorité des requêtes Prometheus fonctionnent telles quelles, et les dashboards Grafana existants n'ont pas besoin d'être modifiés.

MetricsQL ajoute des fonctions absentes de PromQL standard :

# Détection d'anomalies par déviation standard
range_zscore(node_cpu_seconds_total[1h])

# Conversion d'unités intégrée
node_memory_MemAvailable_bytes / 1024 / 1024 / 1024

# Top-k avec lissage
topk_avg(5, rate(http_requests_total[5m]))

# Différence entre deux ranges
delta_prometheus(http_requests_total[1h])

Ces extensions sont toutes optionnelles : un dashboard rédigé en PromQL pur reste portable entre Prometheus et VictoriaMetrics.

Les benchmarks publiés par l'éditeur (sur le README GitHub officiel) annoncent les ordres de grandeur suivants face aux solutions équivalentes :

• Jusqu'à 7x moins de RAM par rapport à Prometheus, Thanos ou Cortex sur des charges équivalentes.
• Jusqu'à 7x moins d'espace disque pour la même rétention, grâce au format colonnaire et à la compression.
• Jusqu'à 10x moins de RAM que InfluxDB lorsque le nombre de séries actives dépasse le million.
• Jusqu'à 70x plus de points stockés que TimescaleDB pour un même volume disque.

Ces chiffres viennent du dépôt officiel et reflètent des configurations spécifiques. À chacun de les valider sur sa propre charge, mais le saut de magnitude est bien réel : la page case studies recense des retours d'expérience publics (CERN, Spotify, Criteo, adidas, Grammarly, Roblox, Wix) avec des réductions de coût d'infrastructure significatives lors de la migration.

L'efficacité repose sur trois choix d'ingénierie :

1. Storage colonnaire : les valeurs et les timestamps sont stockés séparément, ce qui maximise le ratio de compression (Gorilla + ZSTD).
2. Inverted index optimisé : la résolution des labels est plus rapide que l'index inversé de Prometheus, particulièrement sur les hautes cardinalités.
3. Pas de WAL : VictoriaMetrics écrit directement sur disque par batchs, ce qui réduit l'amplification d'écriture.

VictoriaMetrics se justifie particulièrement dans quatre contextes.

Rétention longue durée

Prometheus n'a pas été conçu pour conserver plus de quelques semaines de métriques en local. Brancher Thanos ou Cortex pour archiver vers S3 fonctionne, mais ajoute une stack complète (sidecars, store gateway, compactor, querier). VictoriaMetrics single-node tient des années de rétention sur un seul serveur, sans sidecar ni stockage objet. Pour les équipes qui ont besoin de conserver 2 à 5 ans d'historique sans construire une plateforme distribuée, c'est la solution la plus simple.

Haute cardinalité

Les workloads modernes (microservices, Kubernetes, traces converties en métriques) génèrent facilement des millions de séries actives. Prometheus tient, mais avec une consommation mémoire qui devient prohibitive. VictoriaMetrics encaisse ces charges avec une fraction de la RAM, ce qui change la donne sur les clusters denses.

Multi-tenants mutualisé

Le mode cluster propose un multi-tenancy natif, sans surcouche. C'est la base d'une plateforme d'observabilité interne où chaque équipe dispose de son propre tenant, isolé des autres en écriture comme en lecture, sans devoir déployer une instance Prometheus par projet.

Edge et IoT

Le binaire single-node léger se déploie sans difficulté sur des nœuds edge contraints en RAM. Couplé à vmagent en mode buffer disque, il encaisse les coupures réseau et synchronise vers un backend central dès la reconnexion.

La migration depuis Prometheus se fait sans rupture grâce à vmctl. Le workflow standard :

# 1. Activer le remote write côté Prometheus vers VictoriaMetrics
# prometheus.yml
remote_write:
  - url: http://victoriametrics:8428/api/v1/write

# 2. Migrer l'historique avec vmctl
./vmctl prometheus \
  --prom-snapshot=/var/lib/prometheus/snapshots/20260501T120000Z \
  --vm-addr=http://victoriametrics:8428

# 3. Mettre Grafana sur la nouvelle datasource
# Type: Prometheus, URL: http://victoriametrics:8428

Pendant cette phase, les deux backends tournent en parallèle. Une fois l'historique importé et les dashboards validés sur la nouvelle datasource, on peut couper Prometheus ou le conserver en frontal vmagent.

VictoriaMetrics n'est pas exempt de compromis qu'il faut connaître avant de l'adopter.

Pas de service discovery natif côté serveur. Le moteur de stockage ne scrape pas : il faut soit conserver Prometheus en mode scrape avec remote write, soit utiliser vmagent. Le service discovery (Kubernetes, Consul, EC2) reste à la charge de l'agent.

Différences subtiles avec PromQL. Quelques fonctions ont un comportement légèrement différent (rate sur des séries à incréments lents, gestion des staleness markers). La page MetricsQL difference documente précisément ces écarts. Pour la plupart des dashboards Grafana standard, l'impact est nul, mais une revue est utile sur les alertes critiques.

Cluster en BSL côté Enterprise. Les fonctionnalités cluster restent en Apache 2.0, mais certaines extensions (downsampling automatique, retention par tenant, vmgateway) sont réservées à la version Enterprise sous licence commerciale. À vérifier selon le besoin.

Écosystème plus jeune que Prometheus. Moins d'opérateurs Kubernetes officiels, moins de Helm charts maintenus par des tiers, moins de retours sur les patterns avancés. La situation s'améliore vite, mais l'écart reste perceptible.

• Prometheus, Grafana et Alertmanager : la stack monitoring de référence
• Stratégies d'alerting : du seuil naïf au SLO
• SLO, SLI et error budget : piloter la fiabilité
• Monitorer un cluster Kubernetes en production
• OpenTelemetry : la couche d'observabilité unifiée
• Pousser les métriques avec Prometheus Pushgateway

• VictoriaMetrics (dépôt GitHub officiel) README, benchmarks, version v1.142.0
• VictoriaMetrics (documentation) architecture, composants, ingestion
• MetricsQL (différences avec PromQL) extensions et écarts documentés
• Cluster version, vminsert, vmselect, vmstorage, multi-tenancy
• vmagent, collecte, relabeling, buffer disque

VictoriaMetrics ne remplace pas Prometheus en tant que collecteur, mais s'impose comme un backend de stockage et de requêtage nettement plus efficient pour les charges qui dépassent les capacités d'un Prometheus solo. La compatibilité PromQL native rend la transition progressive : vmagent côté collecte, remote write vers VictoriaMetrics, dashboards Grafana inchangés. Pour les plateformes qui visent une rétention longue, des millions de séries actives ou un multi-tenancy mutualisé sans construire une stack Thanos ou Cortex, le rapport simplicité/performance est difficile à battre.