Table of Contents
1. An issue that outlived several ideas
The work started with a broad client question: what should replace or complement the central logging system? Elastic, Loki, OpenObserve, a packaged observability stack and the existing Seq deployment were all considered. It was worth keeping the question open. Picking a log engine is easy in a presentation and expensive to reverse after hundreds of millions of events have been stored.
We eventually chose VictoriaLogs, but not because it won a feature matrix. We built a local proof of concept around the real .NET path: Serilog sent OTLP/HTTP protobuf directly to VictoriaLogs. We checked structured fields, exceptions, correlation, a Grafana alert, restart persistence and a 2,621,440-row load test.
2. Migrating without a leap of faith
The first deployment did not remove Seq. The client's services sent the same logs to the old and new systems in parallel. VictoriaLogs received its own PVC, 14-day retention, an 80% disk usage cap, Prometheus alerts and a Grafana data source. Canary came first, followed by every production workload.
Dual-write was both an insurance policy and a measurement tool. We could compare event counts for the same service and time window, verify field completeness and roll back only the new export branch. We removed the Seq sink only after fresh logs were confirmed from every application covered by the migration. The Seq runtime and PVC were deleted later in a separate, manually controlled step.
PoC
Real log shape, queries, alerts and a load test.
Dual-write
The same traffic reached Seq and VictoriaLogs during comparison.
Cutover
All workloads first, old storage removed in a separate step.
3. What 20.72× compression actually means
VictoriaLogs exposes two metrics: the logical data size before compression and the size of compressed blocks. Their quotient is the compression ratio. In our production snapshot, all storage tiers contained 576,120,523,443 uncompressed bytes and 27,798,540,623 compressed bytes.
576.1 GB ÷ 27.8 GB = 20.72×
This is not a vendor benchmark or a comparison of files with different retention periods. It is a direct reading from our instance: vl_uncompressed_data_size_bytes divided by vl_compressed_data_size_bytes. At the same moment, storage held 433,453,901 rows and the dropped-row counters reported zero.
VictoriaLogs metrics documentation →4. Why 50 GiB is enough
The old Seq deployment had a 450 GiB PVC. VictoriaLogs runs on 50 GiB, a 9× smaller volume, while keeping a 14-day log window. An 80% usage cap leaves room for merges and temporary operations, while a 10 GiB free-space safety threshold protects the database as the filesystem fills up.
20.72× and 9× describe different things. The first is the compression efficiency of the data stored today. The second is the reduction in provisioned capacity versus the old system. We do not publish a bill-saving percentage because that depends on the provider and volume class. We do know that 400 GiB of provisioned central-log capacity is gone without giving up structured fields or the VictoriaLogs retention window.
5. MCP: from dashboards to conversations with logs
VictoriaLogs has an official Grafana data source, so logs and alerts can join an existing observability stack. That is convenient, but it was not a major leap in this deployment. The team mainly uses the native VictoriaLogs VMUI through private Tailscale access, so the everyday manual log-browsing workflow remained familiar.
The real interface change comes from the official VictoriaLogs MCP server. It exposes almost all read-only APIs available in the web UI to AI clients. An agent can discover streams and fields, run LogsQL, count events and consult embedded documentation. It does not need cluster shell access or permission to modify production.
An example from preparing this article
We asked MCP for log counts grouped by service.name over one full day. One query returned 35,171,083 events from seven client services. The busiest worker produced 30,075,497 rows. The agent did not receive a CSV export or click through dashboards. It queried the source, received structured results and could immediately narrow the next diagnostic step.
That is what AI-ready observability should mean. It is not a chatbot bolted onto Grafana. It is a small, controlled interface through which an agent can collect evidence: count errors by service, find correlation fields, compare windows before and after a deployment and surface concrete events. A human still judges the conclusion, but no longer performs every search step manually.
Official VictoriaLogs MCP server →6. What changed in cost and operations
Less storage
50 GiB instead of 450 GiB of provisioned central-log capacity.
Fewer moving parts
Applications send OTLP directly. Alloy and Jaeger are not needed in this path.
The same operational detail
service.name, environment, SourceContext, severity, trace/span IDs and exception.* remain queryable fields.
Faster diagnosis
People use the native VMUI through Tailscale, while MCP gives agents read-only access to the same logs.
The main lesson is not “replace every logging system with VictoriaLogs.” It is the sequence: a production-shaped PoC first, then dual-write and comparison, a coordinated cutover for every log producer, and old storage removal only at the end. Compression creates the saving. MCP makes the same data work harder during everyday development and incidents.
Methodology: the 20.72×, 576.1 GB, 27.8 GB and 433.5 million figures come from the production instance /metrics endpoint on September 9, 2026. Client-identifying details and service names have been omitted.
Have a difficult technical problem to solve?
We build and improve systems guided by DORA metrics, with a focus on precision, reliability and efficiency in CI/CD and production.
