VictoriaMetrics : alternative Prometheus haute performance — tutoriel 2026

📍 Article principal du cluster : Stack observabilité open-source 2026 : OpenTelemetry, Loki, Tempo, Mimir, VictoriaMetrics
Cet article fait partie du cluster « Stack observabilité open-source 2026 ». Pour la vue d’ensemble complète, commencez par lire le pilier.

Introduction

Prometheus est devenu le standard de fait pour la collecte de métriques dans les environnements cloud-native, mais il souffre d’un défaut bien connu des équipes qui l’opèrent sur des serveurs aux ressources modestes : sa consommation mémoire devient rapidement problématique dès que le volume de séries temporelles croît. VictoriaMetrics résout précisément ce problème. Conçu comme un remplacement drop-in de Prometheus, il consomme jusqu’à dix fois moins de RAM à charge équivalente, offre un meilleur taux de compression sur disque et introduit MetricsQL, une extension de PromQL qui ajoute des fonctions analytiques absentes du langage original. Ce tutoriel vous guide de l’installation à l’alerting en passant par la configuration de vmagent et Grafana, le tout en moins de trente minutes sur un VPS d’entrée de gamme.

Prérequis

• Docker Engine 24+ et Docker Compose v2 installés (docs.docker.com/engine/install)
• 1 Go de RAM disponible minimum (2 Go recommandé pour VM + vmagent + Grafana)
• Ports libres : 8428 (VictoriaMetrics), 8429 (vmagent), 8880 (vmalert), 3000 (Grafana)
• Niveau : intermédiaire — vous savez lire un fichier YAML et exécuter des commandes Docker
• Temps estimé : ~30 minutes pour les étapes 1 à 7

Étape 1 — VictoriaMetrics vs Prometheus vs Mimir : choisir le bon outil

Avant de déployer quoi que ce soit, il est utile de comprendre le positionnement de chacun des trois acteurs principaux dans l’écosystème des métriques open-source. Prometheus est le collecteur et le moteur de requêtes historique : il scrape les cibles, stocke localement les séries temporelles et expose PromQL. Son point faible est la rétention longue durée et la scalabilité horizontale, pour lesquels il n’a jamais été conçu. Mimir, développé par Grafana Labs, est la solution de stockage distribué multi-tenant pour les métriques à très grande échelle : il nécessite un backend objet comme S3 ou GCS et se justifie pour des milliers de services. VictoriaMetrics se place entre les deux.

VictoriaMetrics est un moteur de stockage de séries temporelles conçu pour être à la fois léger et performant. En mode single-node, il peut ingérer plusieurs millions de points par seconde sur un serveur modeste, compresse les données mieux que Prometheus (grâce à son algorithme interne), et supporte nativement le protocole remote_write de Prometheus ainsi que les requêtes PromQL standard. La différence fondamentale avec Mimir est architecturale : VictoriaMetrics single-node ne requiert aucun stockage objet externe, aucun composant Kubernetes, aucune dépendance en dehors de lui-même. C’est précisément ce qui le rend attractif pour les équipes PME en Afrique de l’Ouest qui opèrent sur des VPS à budget contraint.

En résumé : si vous avez moins de 500 services à monitorer et un VPS de 2 à 8 Go de RAM, VictoriaMetrics single-node est le choix rationnel. Si vous anticipez une croissance massive et disposez d’un budget cloud conséquent, Mimir prend le relais. Prometheus reste pertinent comme collecteur frontal, mais son rôle de stockage long terme peut être délégué à VictoriaMetrics via remote_write.

Étape 2 — Déployer VictoriaMetrics single-node via Docker

La forme la plus simple pour prendre en main VictoriaMetrics est le déploiement single-node via Docker. L’image officielle victoriametrics/victoria-metrics est publiée sur Docker Hub et ne nécessite aucune configuration initiale pour fonctionner : elle expose le port 8428, écrit ses données dans le répertoire /storage à l’intérieur du conteneur, et accepte immédiatement les requêtes PromQL et les push remote_write. Nous allons créer un fichier Compose qui montera un volume persistant pour éviter de perdre les données à chaque redémarrage du conteneur.

Créez un répertoire de travail, par exemple ~/observabilite, et placez-y le fichier suivant :

# docker-compose.yml
version: "3.9"

services:
  victoriametrics:
    image: victoriametrics/victoria-metrics:v1.101.0
    container_name: victoriametrics
    ports:
      - "8428:8428"
    volumes:
      - vm_data:/storage
    command:
      - "-storageDataPath=/storage"
      - "-retentionPeriod=12"       # rétention 12 mois
      - "-httpListenAddr=:8428"
    restart: unless-stopped

volumes:
  vm_data:

L’option -retentionPeriod=12 configure une rétention de douze mois, ce qui représente environ 15 à 20 Go pour une infrastructure de cinquante services — largement dans les limites d’un disque local standard. Démarrez le service avec docker compose up -d, puis vérifiez qu’il répond correctement en interrogeant son endpoint de santé :

curl http://localhost:8428/health
# Réponse attendue : OK

Si vous obtenez OK, VictoriaMetrics est opérationnel et prêt à ingérer des métriques. Vous pouvez également ouvrir l’interface web intégrée à http://localhost:8428/vmui : elle propose un explorateur de métriques et un éditeur MetricsQL qui sera utile à l’étape 6.

Étape 3 — Configurer Prometheus pour pousser vers VictoriaMetrics via remote_write

Si vous avez déjà Prometheus en production et que vous souhaitez migrer progressivement sans tout casser, la stratégie remote_write est idéale. Prometheus continue de scraper vos cibles comme avant, mais en plus d’écrire localement, il pousse un duplicata de toutes les métriques vers VictoriaMetrics en temps réel. Vous pouvez ainsi faire cohabiter les deux systèmes pendant une période de transition, comparer les requêtes, puis désactiver le stockage local Prometheus une fois que vous avez validé VM.

Dans votre fichier prometheus.yml, ajoutez la section remote_write à la fin :

# prometheus.yml — extrait
global:
  scrape_interval: 15s
  evaluation_interval: 15s

remote_write:
  - url: http://victoriametrics:8428/api/v1/write
    queue_config:
      max_samples_per_send: 10000
      capacity: 20000
      max_shards: 5

scrape_configs:
  - job_name: "prometheus"
    static_configs:
      - targets: ["localhost:9090"]

L’URL /api/v1/write est l’endpoint standard du protocole Prometheus remote_write, que VictoriaMetrics implémente nativement. Le paramètre max_shards contrôle le parallélisme de l’envoi : avec 5 shards, vous évitez les retards d’ingestion en cas de pic. Après avoir rechargé la configuration Prometheus (curl -X POST http://localhost:9090/-/reload), surveillez les métriques internes prometheus_remote_storage_samples_total et prometheus_remote_storage_failed_samples_total pour vérifier que le flux fonctionne sans erreur.

Étape 4 — vmagent comme remplaçant léger du scraper Prometheus

Si vous partez de zéro ou souhaitez remplacer complètement Prometheus, vmagent est la solution recommandée par l’équipe VictoriaMetrics. C’est un collecteur de métriques ultra-léger qui comprend le même format de configuration que Prometheus (scrape_configs identique), consomme sensiblement moins de mémoire et supporte nativement plusieurs backends de destination simultanés. Là où Prometheus est un monolithe qui collecte et stocke, vmagent est un agent pur qui collecte et pousse — le stockage reste l’affaire de VictoriaMetrics.

Ajoutez vmagent à votre fichier Compose :

  vmagent:
    image: victoriametrics/vmagent:v1.101.0
    container_name: vmagent
    ports:
      - "8429:8429"
    volumes:
      - ./vmagent-config.yml:/etc/vmagent/config.yml:ro
      - vmagent_data:/vmagentdata
    command:
      - "-promscrape.config=/etc/vmagent/config.yml"
      - "-remoteWrite.url=http://victoriametrics:8428/api/v1/write"
      - "-httpListenAddr=:8429"
    restart: unless-stopped
    depends_on:
      - victoriametrics

volumes:
  vm_data:
  vmagent_data:

Créez ensuite un fichier vmagent-config.yml à côté du Compose, en utilisant la syntaxe scrape_configs identique à Prometheus. Voici un exemple qui scrape Node Exporter et Cadvisor :

# vmagent-config.yml
global:
  scrape_interval: 15s

scrape_configs:
  - job_name: "node-exporter"
    static_configs:
      - targets: ["node-exporter:9100"]

  - job_name: "cadvisor"
    static_configs:
      - targets: ["cadvisor:8080"]

La bascule de Prometheus vers vmagent est transparente : votre configuration existante est réutilisable sans modification. vmagent dispose également d’un mécanisme de file d’attente persistante sur disque (/vmagentdata) qui protège contre les pics d’ingestion et les coupures réseau temporaires — particulièrement utile dans des contextes où la connectivité est intermittente. Vérifiez l’état de l’agent à http://localhost:8429/targets pour voir si toutes vos cibles sont bien scrapées.

Étape 5 — Connecter Grafana à VictoriaMetrics

Grafana se connecte à VictoriaMetrics exactement comme il se connecterait à Prometheus, car VictoriaMetrics implémente l’API de requête Prometheus. Il n’y a pas de plugin tiers à installer, pas de configuration spéciale : vous créez simplement une datasource de type « Prometheus » et pointez son URL vers VictoriaMetrics. Tous vos dashboards Prometheus existants fonctionneront immédiatement, et vous aurez en bonus accès aux fonctions MetricsQL supplémentaires décrites à l’étape suivante.

Ajoutez Grafana à votre Compose :

  grafana:
    image: grafana/grafana:10.4.2
    container_name: grafana
    ports:
      - "3000:3000"
    environment:
      - GF_SECURITY_ADMIN_PASSWORD=changeme
    volumes:
      - grafana_data:/var/lib/grafana
    restart: unless-stopped
    depends_on:
      - victoriametrics

volumes:
  vm_data:
  vmagent_data:
  grafana_data:

Une fois Grafana démarré, rendez-vous sur http://localhost:3000, connectez-vous avec admin / changeme, puis allez dans Connections → Data sources → Add data source. Choisissez le type Prometheus, saisissez l’URL http://victoriametrics:8428 (nom du service Docker), laissez tous les autres paramètres par défaut, et cliquez sur Save & Test. Grafana doit répondre « Data source is working ». Vous pouvez maintenant importer n’importe quel dashboard Prometheus depuis grafana.com/dashboards — le dashboard Node Exporter Full (ID 1860) par exemple — en le pointant sur cette datasource.

Étape 6 — MetricsQL avancé : rollup_rate et histogram_quantiles

MetricsQL est l’extension de PromQL développée par l’équipe VictoriaMetrics. Elle est rétrocompatible : toute requête PromQL valide fonctionne sans modification. MetricsQL ajoute des fonctions analytiques qui simplifient des calculs autrement verbeux en PromQL pur, et corrige certains comportements surprenants de PromQL liés aux données manquantes. Deux fonctions sont particulièrement utiles au quotidien : rollup_rate et histogram_quantiles.

rollup_rate calcule les statistiques d’une série sur une fenêtre temporelle glissante et retourne le minimum, le maximum et la moyenne en une seule requête. C’est utile pour visualiser la variabilité d’un taux sans écrire trois requêtes séparées :

rollup_rate(http_requests_total[5m])

Cette requête retourne trois séries pour chaque label set : rollup_rate(...){rollup="min"}, rollup_rate(...){rollup="avg"} et rollup_rate(...){rollup="max"}}. Dans Grafana, vous pouvez les afficher simultanément sur le même graphe pour avoir une vue instantanée du plancher, de la moyenne et du pic de trafic sur cinq minutes.

histogram_quantiles calcule plusieurs quantiles d’un histogramme en une seule passe, ce qui réduit la charge de requêtes quand vous voulez afficher p50, p90 et p99 en même temps :

histogram_quantiles("quantile", 0.5, 0.9, 0.99, rate(http_request_duration_seconds_bucket[5m]))

Le premier argument est le nom du label qui sera ajouté pour distinguer les quantiles. Le résultat est trois séries portant respectivement quantile="0.5", quantile="0.9" et quantile="0.99". En PromQL standard, ce calcul nécessiterait trois expressions histogram_quantile() distinctes. L’interface vmui accessible sur http://localhost:8428/vmui est un excellent terrain de jeu pour expérimenter ces fonctions avant de les intégrer dans vos dashboards Grafana.

Étape 7 — vmalert pour l’alerting

VictoriaMetrics délègue l’évaluation des règles d’alerte à un composant séparé appelé vmalert. Ce composant lit des fichiers de règles au format Prometheus standard (identique à ceux utilisés par le rules de Prometheus), interroge VictoriaMetrics pour évaluer les conditions, et envoie les alertes déclenchées à Alertmanager. Séparer l’évaluation des règles du stockage est une décision architecturale saine : cela permet de mettre à jour les règles sans toucher au moteur de métriques.

Commencez par créer un fichier de règles d’exemple :

# rules/node-alerts.yml
groups:
  - name: node-health
    interval: 30s
    rules:
      - alert: HighCPUUsage
        expr: 100 - (avg by(instance) (rate(node_cpu_seconds_total{mode="idle"}[5m])) * 100) > 85
        for: 2m
        labels:
          severity: warning
        annotations:
          summary: "CPU élevé sur {{ $labels.instance }}"
          description: "CPU à {{ $value | printf \"%.1f\" }}% depuis 2 minutes."

      - alert: DiskAlmostFull
        expr: (node_filesystem_avail_bytes{mountpoint="/"} / node_filesystem_size_bytes{mountpoint="/"}) * 100 < 10
        for: 5m
        labels:
          severity: critical
        annotations:
          summary: "Disque presque plein sur {{ $labels.instance }}"

Ajoutez ensuite vmalert dans votre Compose :

  vmalert:
    image: victoriametrics/vmalert:v1.101.0
    container_name: vmalert
    ports:
      - "8880:8880"
    volumes:
      - ./rules:/etc/vmalert/rules:ro
    command:
      - "-datasource.url=http://victoriametrics:8428"
      - "-remoteWrite.url=http://victoriametrics:8428/api/v1/write"
      - "-notifier.url=http://alertmanager:9093"
      - "-rule=/etc/vmalert/rules/*.yml"
      - "-httpListenAddr=:8880"
      - "-evaluationInterval=30s"
    restart: unless-stopped
    depends_on:
      - victoriametrics

Notez que -remoteWrite.url est utilisé pour que vmalert écrive les résultats d'évaluation (séries ALERTS et ALERTS_FOR_STATE) directement dans VictoriaMetrics : cela vous permet de requêter l'historique des alertes depuis Grafana. L'interface de vmalert est disponible à http://localhost:8880 et affiche l'état courant de chaque règle — utile pour déboguer une alerte qui ne se déclenche pas comme prévu.

Erreurs fréquentes

Adaptation au contexte ouest-africain

VictoriaMetrics est l'outil de métriques idéal pour les équipes techniques en Afrique de l'Ouest qui opèrent sur des infrastructures à budget maîtrisé. Prenons l'exemple concret d'un Hetzner CX22 : deux vCPU, quatre gigaoctets de RAM, quarante gigaoctets de disque NVMe local, pour environ cinq euros par mois. Sur cette machine, faire tourner Prometheus avec une rétention de six mois pour cinquante services est difficile — Prometheus consomme à lui seul plus d'un gigaoctet de RAM, laissant peu de place pour le reste de la stack. VictoriaMetrics single-node sur la même machine consomme entre 100 et 200 mégaoctets de RAM pour le même volume de données, libérant de l'espace pour vmagent, vmalert, Grafana et vos applications.

La question du stockage objet est souvent un frein pour les PME de la région : S3 d'Amazon est accessible mais représente un coût récurrent en devises étrangères, et la latence depuis Dakar, Abidjan ou Bamako peut être significative selon la région AWS choisie. VictoriaMetrics single-node n'a pas besoin de S3. Une rétention d'un an pour une infrastructure de cinquante services occupe environ 15 à 25 gigaoctets sur disque local — le CX22 avec son disque de 40 Go est largement suffisant, et le CX32 (80 Go, 4 vCPU) couvre confortablement une rétention de deux ans. Cette absence de dépendance externe est également un avantage de résilience : votre stack de monitoring reste opérationnelle même si la connexion internet est dégradée ou coupée, ce qui n'est pas une hypothèse théorique dans certains contextes locaux.

Pour les équipes qui démarrent sans expérience DevOps approfondie, la simplicité opérationnelle de VictoriaMetrics est un argument décisif. Il n'y a pas de cluster à configurer, pas de composant Zookeeper ou etcd à maintenir, pas de tuning Kubernetes complexe. Un seul conteneur Docker, un volume, et vous avez un système de métriques production-ready. Les mises à jour se font en remplaçant la version de l'image dans le Compose — la migration des données est transparente car le format de stockage est rétrocompatible entre les versions mineures.

Tutoriels frères

• Loki : centraliser vos logs Docker sans Elasticsearch — tutoriel 2026 — mettre en place la collecte de logs avec Promtail et Loki sur le même VPS
• OpenTelemetry Collector : instrumenter une app Node.js — tutoriel 2026 — envoyer traces et métriques OTLP vers votre stack observabilité

Pour aller plus loin

• 🔝 Retour au pilier : Stack observabilité open-source 2026
• Documentation officielle VictoriaMetrics — référence complète MetricsQL, configuration, cluster mode
• GitHub VictoriaMetrics — code source, issues, releases et guides de migration
• Prochain tutoriel recommandé du cluster : Grafana Tempo pour le tracing distribué

FAQ

Q : VictoriaMetrics est-il compatible avec tous mes dashboards Grafana Prometheus existants ?
R : Oui. VictoriaMetrics implémente l'API de requête Prometheus (/api/v1/query, /api/v1/query_range, /api/v1/labels, etc.) de façon complète. Il suffit de pointer votre datasource Grafana existante vers le port 8428 de VictoriaMetrics pour que tous vos dashboards fonctionnent sans modification.

Q : Puis-je utiliser VictoriaMetrics en cluster pour la haute disponibilité ?
R : Oui. VictoriaMetrics propose un mode cluster composé de trois composants séparés : vminsert (ingestion), vmselect (requêtes) et vmstorage (stockage). Le mode cluster est disponible sous licence open-source et documenté sur docs.victoriametrics.com/cluster-victoriametrics. Pour la plupart des PME, le mode single-node suffit largement.

Q : Quelle est la différence entre vmagent et Prometheus en termes de consommation mémoire ?
R : vmagent consomme généralement 5 à 10 fois moins de mémoire que Prometheus pour la même configuration de scraping. Prometheus stocke un cache mémoire de toutes les séries actives pour accélérer les requêtes locales ; vmagent, n'ayant pas de moteur de requêtes intégré, n'a pas besoin de ce cache et se contente d'un tampon pour la file d'envoi.

Q : Comment migrer mes données Prometheus existantes vers VictoriaMetrics ?
R : VictoriaMetrics fournit l'outil vmctl qui supporte l'import depuis Prometheus via son API (vmctl prometheus). Pour les données historiques, vous pouvez aussi utiliser l'endpoint /api/v1/import/prometheus de VictoriaMetrics avec des snapshots Prometheus. La documentation de migration est disponible sur docs.victoriametrics.com/vmctl.

Q : VictoriaMetrics supporte-t-il les métriques OpenTelemetry ?
R : Oui, depuis la version 1.91. VictoriaMetrics accepte les métriques OTLP via l'endpoint /opentelemetry/api/v1/push (format Protobuf). Vous pouvez configurer l'OpenTelemetry Collector pour exporter directement vers VictoriaMetrics sans passer par Prometheus.

Q : Que se passe-t-il si VictoriaMetrics redémarre pendant l'ingestion ?
R : VictoriaMetrics utilise un mécanisme de write-ahead log (WAL) qui garantit qu'aucune donnée déjà reçue n'est perdue lors d'un redémarrage propre ou d'un crash. vmagent, de son côté, dispose d'un buffer persistant sur disque qui rejoue automatiquement les données non confirmées après reconnexion.

Site réalisé par [ITS] ITSkillsCenter