VictoriaLogs : la TSDB de logs qui allège votre stack observabilité

Loki a popularisé l'idée d'un store de logs léger et compatible avec l'écosystème Grafana, et Elasticsearch reste la référence pour les recherches plein texte avancées. Entre les deux, VictoriaLogs occupe un créneau précis : la simplicité opérationnelle de Loki, avec des performances de requête bien meilleures et une empreinte mémoire/disque réduite.

Cet article présente VictoriaLogs (architecture, ingestion, LogsQL), le compare à Loki et Elasticsearch sur les axes qui pèsent en pratique, et détaille les cas d'usage où il prend l'avantage.

• Qu'est-ce que VictoriaLogs
• Architecture et schema-free
• Protocoles d'ingestion
• LogsQL : un langage taillé pour l'analyse de logs
• Comparaison avec Loki et Elasticsearch
• Déploiement single-node et cluster
• Cas d'usage pertinents

VictoriaLogs est une base de données de logs open source, distribuée sous licence Apache 2.0. Le projet est développé par la même équipe que VictoriaMetrics, avec la même philosophie : un binaire Go compact, une empreinte minimale, des performances élevées sans dépendance externe.

La dernière version stable au moment de la rédaction est la v1.50.0, publiée le 14 avril 2026. Le projet est encore plus jeune que VictoriaMetrics, mais les retours communautaires et les benchmarks publiés par l'éditeur le placent déjà comme une option crédible pour des déploiements en production allant de la petite plateforme à plusieurs téraoctets/jour.

Trois éléments structurent le projet :

1. Schema-free. Aucune définition d'index ou de mapping à maintenir. On ingère des logs avec des champs arbitraires, le moteur gère.
2. LogsQL. Un langage de requête conçu spécifiquement pour les logs, plus expressif que LogQL et plus simple que la combinaison KQL/Painless d'Elasticsearch.
3. Single binary, multi-modes. Le même binaire couvre le mode single-node et les rôles cluster (vlinsert, vlselect, vlstorage) pour les déploiements horizontaux.

VictoriaLogs stocke chaque entrée de log comme un ensemble de paires clé/valeur. Les champs n'ont pas besoin d'être déclarés à l'avance : un nouveau champ qui apparaît dans un log est indexé automatiquement.

Le moteur applique en interne :

• Un index inversé par champ pour les recherches structurées rapides (par exemple level=ERROR).
• Un index plein texte sur le champ _msg (le message brut) pour les recherches en langage naturel.
• Une compression colonnaire dérivée du moteur VictoriaMetrics : par défaut Gorilla pour les timestamps + ZSTD pour les valeurs.

Cette combinaison donne un ratio de compression typique très favorable, avec une empreinte mémoire réduite par rapport à Elasticsearch sur des charges équivalentes.

VictoriaLogs accepte les principaux formats d'ingestion utilisés en pratique :

Cette compatibilité explique l'attrait de VictoriaLogs comme drop-in replacement : un Promtail existant qui pousse vers Loki peut basculer vers VictoriaLogs en changeant uniquement l'URL. Aucun changement côté agents.

LogsQL est conçu pour exprimer en peu de caractères les requêtes typiques sur logs. Quelques exemples :

# Tous les logs ERROR sur la dernière heure
_time:1h level:ERROR

# Logs d'un service contenant un mot-clé
service:api "timeout"

# Filtrage structuré + plein texte
_time:24h app:nginx status:5* "GET /api/orders"

# Agrégation : top 10 des codes d'erreur
_time:1h status:>=400 | stats by (status) count() | sort by (count) desc | limit 10

# Extraction de champs à la volée
_time:1h "duration=" | extract "duration=<duration>" | stats by (service) avg(duration)

Plusieurs convertisseurs sont fournis pour faciliter la migration :

• LogQL → LogsQL : pour les utilisateurs Loki.
• SQL → LogsQL : pour ceux qui viennent d'un dialecte SQL.
• Lucene/KQL → LogsQL : pour les équipes Elasticsearch.

L'interface web embarquée (port 9428) propose un playground où tester les requêtes en direct.

Pour un cas d'usage logs DevOps purs (recherche par service, niveau, période, mot-clé), VictoriaLogs offre un compromis difficile à battre. Loki reste tout à fait viable pour de petits déploiements ou ceux déjà investis dans l'écosystème Grafana. Elasticsearch garde sa pertinence quand on a besoin d'une recherche plein texte avancée (analyzers, scoring custom, facets) ou pour des cas SIEM/audit qui s'appuient sur la richesse de Kibana et de l'écosystème Elastic.

Single-node

./victoria-logs-prod \
  -storageDataPath=/var/lib/victorialogs \
  -retentionPeriod=30d \
  -httpListenAddr=:9428

Le port 9428 expose toutes les API : ingestion, requêtage, UI web. Pour la majorité des déploiements de petite et moyenne taille, c'est suffisant.

Cluster

Le mode cluster scinde le binaire en trois rôles déployables séparément, sur le modèle de VictoriaMetrics :

• vlstorage : stockage et requêtage local.
• vlinsert : reçoit les écritures, les distribue aux vlstorage.
• vlselect : reçoit les requêtes, agrège les résultats des vlstorage.

# Démarrer un vlstorage
./victoria-logs-prod -storageNode -httpListenAddr=:9428 \
  -storageDataPath=/var/lib/vlstorage

# Démarrer un vlinsert pointant vers les vlstorage
./victoria-logs-prod -insertNode -storageNode.addr=http://vlstorage1:9428,http://vlstorage2:9428

# Démarrer un vlselect
./victoria-logs-prod -selectNode -storageNode.addr=http://vlstorage1:9428,http://vlstorage2:9428

Cette architecture permet de scaler indépendamment l'ingestion et le requêtage, et d'absorber les gros volumes (téraoctets/jour) sans dégradation.

VictoriaLogs prend l'avantage dans plusieurs contextes.

Remplacement de Loki sans changer les agents

Pour une équipe déjà sur Loki + Promtail/Alloy mais frustrée par les performances de requête sur des cardinalités élevées, le swap est trivial : changer l'URL de remote write côté agent, garder les dashboards Grafana (LogsQL est compatible avec le datasource Loki via convertisseur).

Stack légère pour PME/MSP

Pour un MSP qui veut héberger les logs de plusieurs clients sur une plateforme commune, le multi-tenancy via header + l'empreinte minimale font qu'une seule instance VictoriaLogs peut servir des dizaines de tenants sur du matériel modeste.

Logs longue rétention

Pour les charges qui réclament de conserver 90 jours, 6 mois ou plus de logs (audit, conformité, retours d'expérience), la compression colonnaire de VictoriaLogs limite drastiquement les besoins disque. Combiné à un object store S3 ou Garage en archive offload (via vmctl), on tient des rétentions très longues à coût maîtrisé.

Plateforme observabilité unifiée

Pour une stack qui combine VictoriaMetrics + VictoriaLogs + Grafana, on dispose d'un trio cohérent sur un même socle technique : même équipe d'éditeur, même philosophie d'opération, mêmes patterns d'optimisation. La courbe d'apprentissage et la maintenance sont mutualisées.

Écosystème jeune. Moins de plugins Grafana tiers, moins de connecteurs prêts à l'emploi que Loki ou Elasticsearch. La situation s'améliore vite mais l'écart reste perceptible.

Recherche full-text moins riche qu'Elasticsearch. Pas d'analyzers personnalisables, pas de scoring custom, pas de fuzzy search avancé. Pour de la pure recherche documentaire ou des cas SIEM avec correlation rules complexes, Elastic reste plus adapté.

Pas de DSL d'alerting natif. Pas d'équivalent direct à vmalert côté logs (c'est en cours d'évolution). Les alertes sur logs passent par un agrégateur externe ou par des recording rules qui transforment les logs en métriques côté VictoriaMetrics.

Edition Enterprise pour certaines fonctionnalités. Comme VictoriaMetrics, certaines features avancées (downsampling logs, statistiques avancées) sont sous Enterprise.

• VictoriaMetrics : la TSDB qui allège votre stack monitoring
• Stack logging avec Loki
• Cluster Elasticsearch en haute disponibilité
• Pipeline de logs avec Fluentbit
• OpenTelemetry et l'observabilité moderne

• VictoriaLogs (dépôt GitHub) code, releases, version v1.50.0
• Documentation VictoriaLogs, architecture, ingestion, requêtage
• LogsQL Reference, syntaxe complète
• Cluster mode, déploiement horizontal

VictoriaLogs est aujourd'hui l'option la plus crédible pour qui veut un store de logs léger et performant sans s'engager dans la complexité d'Elasticsearch. La compatibilité avec les agents Loki rend la migration triviale, le moteur de requête est plus rapide sur les cardinalités élevées, et l'empreinte ressources reste la signature des projets VictoriaMetrics.