VictoriaMetrics launches VictoriaStack for three telemetry signals

By Elena Vasquez

VictoriaMetrics has launched VictoriaStack, an open-source observability stack that coordinates three specialized databases: VictoriaMetrics for metrics, VictoriaLogs for logs, and VictoriaTraces for traces.

The release addresses a practical infrastructure constraint described in the announcement: engineering teams need broader telemetry coverage without replacing their entire monitoring environment or forcing every signal into one database.

VictoriaMetrics says teams can adopt the signals they need, add others later, and connect them through shared deployment tooling and OpenTelemetry support. The company says the choice matters as applications grow from a few services into distributed systems.

What does VictoriaStack combine?

VictoriaMetrics's documentation gives each signal a distinct job. According to the company, that separation lets an investigation move from broad symptoms to detailed evidence without pretending every workload has the same storage or query needs.

• VictoriaMetrics says metrics summarize behavior over time, including request rates, error counts, and memory consumption.
• VictoriaMetrics says logs record individual events and their details.
• VictoriaMetrics says distributed traces follow a request through multiple services, showing where time was spent and where a failure emerged.

VictoriaMetrics describes an example incident sequence: an engineer spots a latency spike in metrics, narrows the issue to a service through traces, then checks logs for the underlying error. A coordinated workflow can shorten that process while leaving each signal's storage requirements intact.

VictoriaMetrics's architecture documentation describes independent databases sharing a common component model. Each database can run as a single binary or as a cluster separating ingestion, storage, and querying, and vmauth can serve as the routing and load-balancing entry point.

VictoriaMetrics keeps the query interfaces specialized. VictoriaMetrics uses PromQL-compatible MetricsQL, VictoriaLogs uses LogsQL, and VictoriaTraces supports LogsQL alongside Jaeger- and Tempo-compatible APIs. The company says coordination does not require one database or one universal query language.

VictoriaMetrics says 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. VictoriaMetrics's launch therefore pairs an open-source core with commercial and managed options without requiring an all-at-once migration.

How does OpenTelemetry fit?

VictoriaMetrics's documentation presents OpenTelemetry as a common method for instrumenting applications and exporting telemetry. The company says its OTLP protocol works across VictoriaStack's metrics, logs, and traces, creating a consistent ingestion path even when data lands in separate backends.

VictoriaMetrics says that distinction matters when an application grows from a few services into a distributed system. According to the company, instrumentation should describe application behavior, while changing a telemetry destination should not force engineers to redesign monitoring code across every service.

VictoriaStack also supports other ingestion formats where appropriate. Teams using Prometheus-based metrics collection can retain that ecosystem while adding logs or tracing, which VictoriaMetrics says reduces migration work. Retention, capacity, and query patterns remain engineering decisions.

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

What can AI agents investigate?

VictoriaMetrics frames its AI work in two directions: observability systems must handle telemetry generated by agentic applications, and AI assistants can help engineers interrogate that telemetry. Official Model Context Protocol servers give assistants a way to investigate while engineers retain responsibility for deciding which changes to apply.

VictoriaMetrics documents separate Model Context Protocol, or MCP, servers for metrics, logs, and traces. Their structured capabilities let an assistant query time series, explore log fields, find services and operations, retrieve traces, and investigate cardinality, query behavior, and alerting configuration.

The company's agent skills repository adds reusable workflows for multi-signal investigations and related operational tasks. VictoriaMetrics says an assistant can follow a troubleshooting process across signals instead of working from a single dashboard or a pasted error message.

VictoriaMetrics describes read-only access for Claude Code, Codex, Cursor, and in-house agents. The company describes the intended workflow as gathering evidence, connecting symptoms, and proposing an explanation, but an engineer still decides what gets applied.

VictoriaMetrics also draws a boundary around that workflow. Connecting a telemetry source to an agent does not prove that the agent has identified the root cause correctly. The tools assist investigation, but the company does not claim they replace engineering judgment.

How does the stack scale?

VictoriaMetrics's Quick Start shows both single-node and clustered configurations. Its Docker Compose demonstration includes an OpenTelemetry application and collector, the three databases, Grafana, vmalert, and vmauth. The documentation explicitly labels the local environment a demonstration rather than a production deployment.

VictoriaMetrics's cluster model keeps ingestion and query components stateless and independently scalable, while storage components retain the data. The company says that separation handles different pressures: incoming telemetry raises ingestion demand, while more engineers and agents running investigations raise query demand.

Storage planning remains important, according to VictoriaMetrics's documentation. The databases keep telemetry on local filesystems, while S3 or Google Cloud Storage serves as a backup destination rather than an object-storage query tier. Reducing the number of storage shards is also a complex operation.

VictoriaMetrics's storage constraints affect topology choices and growth forecasts. The company says VictoriaStack leaves teams control over where data lives and how each signal scales, but its storage design still requires planning before production use.

Can teams adopt it without an all-at-once migration?

The practical proposition is incremental adoption. According to VictoriaMetrics, teams can retain a useful collection ecosystem, introduce missing signals, and manage the resulting services through a more consistent model. The company's pitch does not depend on replacing every existing monitoring component at once.

VictoriaMetrics says it is presenting VictoriaStack at KubeCon + CloudNativeCon North America 2026. The announced demonstration features an OTLP-instrumented Kubernetes application sending its three 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.

VictoriaMetrics's value rests on how well the pieces work together as telemetry volume and investigative demand increase. The 2026 KubeCon demonstration will test that claim through a cross-signal workflow. Its practical standard is concrete: add missing telemetry and scale each signal independently without replacing the collection system a team already runs.