VictoriaMetrics lance VictoriaStack pour les métriques, les journaux, les traces et le dépannage assisté par l’IA

VictoriaMetrics a présenté VictoriaStack, une plateforme d’observabilité open source qui réunit ses produits de métriques, de journaux et de traçage distribué dans un modèle d’exploitation coordonné. Ce lancement vise à permettre aux équipes d’ingénierie d’élargir la couverture de leur télémétrie sans remplacer tout leur environnement de supervision ni contraindre chaque signal à utiliser la même base de données.

VictoriaStack associe VictoriaMetrics pour les métriques, VictoriaLogs pour les journaux et VictoriaTraces pour les traces. Les équipes peuvent adopter les signaux dont elles ont besoin, puis en ajouter d’autres par la suite, grâce à des outils de déploiement partagés et à la prise en charge d’OpenTelemetry, qui facilitent la connexion des composants.

L’annonce étend également ce modèle aux opérations assistées par l’IA. Les serveurs officiels du protocole Model Context Protocol et les compétences pour agents permettent aux assistants d’analyser la télémétrie dans l’ensemble de la plateforme, tandis que les ingénieurs restent responsables des décisions concernant les modifications à appliquer.

Trois signaux, trois bases de données spécialisées

Les métriques, les journaux et les traces répondent à différentes questions opérationnelles. Les métriques résument le comportement au fil du temps, par exemple le débit des requêtes, le nombre d’erreurs ou la consommation de mémoire. Les journaux consignent les événements et leurs détails. Les traces distribuées suivent une requête à travers plusieurs services et révèlent où le temps a été passé et à quel endroit une défaillance est survenue.

Lors d’un incident, un ingénieur peut d’abord remarquer un pic de latence dans les métriques, circonscrire le problème à un service à l’aide des traces, puis examiner les journaux pour trouver l’erreur sous-jacente. Réunir ces signaux dans un flux de travail cohérent peut accélérer l’enquête sans pour autant rendre identiques leurs besoins en matière de stockage.

La documentation sur l’architecture de VictoriaStack décrit des bases de données indépendantes qui partagent un modèle de composants commun. Chacune peut fonctionner sous la forme d’un binaire unique ou d’un cluster qui sépare l’ingestion, le stockage et les requêtes. La plateforme peut utiliser vmauth comme point d’entrée pour le routage et l’équilibrage de charge.

Les interfaces de requête restent elles aussi spécialisées : VictoriaMetrics utilise MetricsQL, compatible avec PromQL, VictoriaLogs utilise LogsQL, et VictoriaTraces prend en charge LogsQL ainsi que les API compatibles avec Jaeger et Tempo. Un fonctionnement coordonné ne signifie donc ni qu’il n’y a qu’une seule base de données, ni qu’un langage de requête unique convient à tous les usages.

Les trois bases de données principales sont disponibles sous licence Apache 2.0. L’entreprise propose également des fonctionnalités destinées aux entreprises et une assistance commerciale, ainsi que VictoriaMetrics Cloud, un service entièrement géré qui prend en charge les trois signaux.

OpenTelemetry relie la couche de collecte

OpenTelemetry fournit une approche commune pour instrumenter les applications et exporter la télémétrie. Son protocole OTLP est pris en charge par les composants de métriques, de journaux et de traces de VictoriaStack, ce qui offre aux équipes un parcours d’ingestion cohérent, même si les données sont envoyées vers différents systèmes de stockage.

Cette distinction devient importante lorsqu’une application passe de quelques services à un système distribué. L’instrumentation doit aider à décrire le comportement de l’application ; changer la destination de la télémétrie ne devrait pas nécessiter de repenser le code de supervision de chaque service.

La plateforme prend également en charge d’autres formats d’ingestion lorsque cela convient. Les équipes qui collectent déjà leurs métriques avec Prometheus, par exemple, peuvent conserver cet écosystème tout en y ajoutant des journaux ou des traces. La compatibilité des protocoles réduit les efforts de migration, tandis que le choix de la durée de conservation, de la capacité et des modèles de requête reste une décision d’ingénierie.

Pour les déploiements Kubernetes, VictoriaMetrics recommande son opérateur et ses graphiques Helm comme outils de gestion courants. L’objectif est d’uniformiser les déploiements et les mises à niveau tout en conservant la possibilité de faire évoluer chaque signal en fonction de sa propre charge de travail.

Les agents d’IA peuvent mener des investigations sur l’ensemble de la télémétrie

VictoriaStack aborde l’IA sous deux angles : les systèmes d’observabilité doivent pouvoir traiter la télémétrie produite par les applications agentiques, et les assistants d’IA peuvent aider les ingénieurs à interroger ces données.

La documentation des outils d’IA de l’entreprise décrit des serveurs MCP distincts pour les métriques, les journaux et les traces. Ils proposent des fonctionnalités structurées, comme interroger des séries temporelles, explorer les champs des journaux, rechercher des services et des opérations, et récupérer des traces. L’intégration des métriques permet également d’examiner la cardinalité, le comportement des requêtes et la configuration des alertes.

Son dépôt de compétences pour agents propose des flux de travail réutilisables pour les investigations portant sur plusieurs signaux et d’autres tâches opérationnelles connexes. Un assistant peut suivre une procédure de dépannage qui recoupe plusieurs signaux, au lieu de s’appuyer sur un seul tableau de bord ou un message d’erreur copié-collé.

L’annonce décrit un accès en lecture seule pour les assistants, notamment Claude Code, Codex, Cursor et les agents internes. Le flux de travail prévu est donc axé sur l’investigation : recueillir des éléments, relier les symptômes et proposer une explication, tandis que les ingénieurs décident des modifications à appliquer. Le fait de connecter une source de télémétrie à un agent ne suffit pas à établir que celui-ci a correctement identifié la cause première.

Faire évoluer séparément l’ingestion et les requêtes

Le guide de démarrage rapide de VictoriaStack présente des configurations à nœud unique et en cluster. Sa démonstration avec Docker Compose comprend une application et un collecteur OpenTelemetry, les trois bases de données, Grafana, vmalert et vmauth. La documentation précise que cet environnement local sert à la démonstration et non à un déploiement en production.

Dans le modèle en cluster, les composants d’ingestion et de requête sont sans état et peuvent être mis à l’échelle indépendamment, tandis que les composants de stockage conservent les données. Cette séparation répond à des besoins distincts : l’augmentation du volume de télémétrie entrant peut nécessiter une plus grande capacité d’ingestion, tandis que l’augmentation du nombre d’ingénieurs ou d’agents menant des investigations peut accroître la demande de requêtes.

La planification du stockage reste importante. La documentation indique que les bases de données conservent la télémétrie sur des systèmes de fichiers locaux ; S3 ou Google Cloud Storage sert aux sauvegardes, et non de couche de requête sur stockage objet. Elle précise également que la réduction du nombre de partitions de stockage est une opération complexe. Ces caractéristiques comptent dans le choix d’une topologie et la prévision de la croissance.

Une pile coordonnée sans migration globale immédiate

VictoriaMetrics présente VictoriaStack à KubeCon + CloudNativeCon North America 2026, avec une démonstration d’une application Kubernetes instrumentée avec OTLP qui envoie ses trois signaux de télémétrie aux systèmes dorsaux correspondants, suivie d’un processus de dépannage croisé entre les signaux.

« L’ère agentique va entraîner une hausse du volume de télémétrie et accroître les exigences liées à son traitement », a déclaré Roman Khavronenko, cofondateur de VictoriaMetrics et responsable de l’ingénierie, dans l’annonce. Il a précisé que VictoriaStack est conçu pour répondre à ces besoins croissants en privilégiant l’évolutivité et l’efficacité.

La proposition concrète repose sur une adoption progressive : conserver un écosystème de collecte utile, ajouter les signaux manquants et gérer les services qui en résultent selon un modèle plus cohérent. La valeur de VictoriaStack tient à la qualité de la coordination entre ces éléments lorsque le volume de télémétrie et les besoins d’investigation augmentent, tout en laissant aux équipes le contrôle de l’emplacement de leurs données et de la mise à l’échelle de chaque signal.