VictoriaMetrics Launches VictoriaStack for Metrics, Logs, Traces and AI-Assisted Troubleshooting

VictoriaMetrics has introduced VictoriaStack, an open-source observability stack that brings its metrics, logs, and distributed-tracing products into a coordinated operating model. The launch aims to give engineering teams a way to expand telemetry coverage without replacing their entire monitoring environment or forcing every signal into the same database.

VictoriaStack combines VictoriaMetrics for metrics, VictoriaLogs for logs, and VictoriaTraces for traces. Teams can adopt the signals they need and add others later, with shared deployment tooling and OpenTelemetry support helping connect the pieces.

The announcement also extends that model to AI-assisted operations. Official Model Context Protocol servers and agent skills give assistants a way to investigate telemetry across the stack, while engineers retain responsibility for deciding which changes to apply.

Three Signals, Three Specialized Databases

Metrics, logs, and traces answer different operational questions. Metrics summarize behavior over time, such as request rates, error counts, or memory consumption. Logs record events and their details. Distributed traces follow a request through multiple services, revealing where time was spent and where a failure emerged.

During an incident, an engineer might first notice a latency spike in metrics, narrow the problem to a service through traces, then inspect logs for the underlying error. Bringing those signals into a consistent workflow can shorten the investigation without making their storage requirements identical.

VictoriaStack’s architecture documentation describes independent databases sharing a common component model. Each can run as a single binary or as a cluster separating ingestion, storage, and querying. The stack can use vmauth as an entry point for routing and load balancing.

The query interfaces also remain specialized: VictoriaMetrics uses PromQL-compatible MetricsQL, VictoriaLogs uses LogsQL, and VictoriaTraces supports LogsQL alongside Jaeger- and Tempo-compatible APIs. Coordinated operation therefore does not mean a single database or one universal query language.

All three core databases are available under the Apache 2.0 license. The company also offers enterprise capabilities and commercial support, plus a fully managed VictoriaMetrics Cloud service supporting the three signals.

OpenTelemetry Connects the Collection Layer

OpenTelemetry provides a common approach to instrumenting applications and exporting telemetry. Its OTLP protocol is supported across VictoriaStack’s metrics, logs, and traces, giving teams a consistent ingestion path even though data lands in different backends.

That distinction matters when an application grows from a few services into a distributed system. Instrumentation should help describe the application’s behavior; changing the destination for telemetry should not require redesigning every service’s monitoring code.

The stack also supports other ingestion formats where appropriate. Teams with existing Prometheus-based metrics collection, for example, can retain that ecosystem while introducing logs or tracing alongside it. Protocol compatibility reduces migration work, while the choice of retention, capacity, and query patterns remains an engineering decision.

For Kubernetes deployments, VictoriaMetrics points to its Operator and Helm charts as the common management tools. The aim is to make deployments and upgrades more consistent while preserving the ability to scale each signal according to its own workload.

AI Agents Can Investigate Across Telemetry

VictoriaStack approaches AI from two directions: observability systems must handle telemetry generated by agentic applications, and AI assistants can help engineers interrogate that telemetry.

The company’s AI tools documentation describes separate MCP servers for metrics, logs, and traces. They expose structured capabilities such as querying time series, exploring log fields, finding services and operations, and retrieving traces. The metrics integration also supports investigations into cardinality, query behavior, and alerting configuration.

Its agent skills repository adds reusable workflows for multi-signal investigations and related operational tasks. An assistant can follow a troubleshooting process across signals rather than relying on a single dashboard or a pasted error message.

The announcement describes read-only access for assistants including Claude Code, Codex, Cursor, and in-house agents. That makes the intended workflow investigative: gather evidence, connect symptoms, and propose an explanation while engineers decide what gets applied. Connecting a telemetry source to an agent does not itself establish that the agent has identified the root cause correctly.

Scaling Ingestion and Queries Separately

The VictoriaStack Quick Start illustrates both single-node and clustered configurations. Its Docker Compose demo includes an OpenTelemetry application and collector, the three databases, Grafana, vmalert, and vmauth. The documentation explicitly positions this local environment as a demonstration rather than a production deployment.

In the cluster model, ingestion and query components are stateless and can be scaled independently, while storage components maintain the data. This separates distinct pressures: more incoming telemetry can require ingestion capacity, while more engineers or agents running investigations can increase query demand.

Storage planning remains important. The documentation says the databases keep telemetry on local filesystems; S3 or Google Cloud Storage is used for backups rather than an object-storage query tier. It also notes that reducing the number of storage shards is a complex operation. Those characteristics matter when choosing a topology and forecasting growth.

A Coordinated Stack Without an All-at-Once Migration

VictoriaMetrics is presenting VictoriaStack at KubeCon + CloudNativeCon North America 2026, with a demonstration of an OTLP-instrumented Kubernetes application sending its three telemetry signals to the corresponding backends, followed by a cross-signal troubleshooting workflow.

“The agentic era will bring more telemetry and greater demands on how we process it,” said Roman Khavronenko, VictoriaMetrics co-founder and engineering manager, in the announcement. He said VictoriaStack is designed around scalability and efficiency as that demand grows.

The practical proposition is incremental adoption: retain a useful collection ecosystem, introduce the missing signals, and manage the resulting services through a more consistent model. VictoriaStack’s value lies in how well those pieces work together as telemetry volume and investigative demand increase, while leaving teams control over where their data lives and how each signal scales.