Operations | Monitoring | ITSM | DevOps | Cloud

Q3 2026 has been one of the greatest quarters for VictoriaMetrics Cloud, and that is thanks to the whole team, including open source, of course. The big milestone is that VictoriaTraces is now part of VictoriaMetrics Cloud, which means that the full VictoriaStack lives in one managed place, with a single bill and the same experience users already know.

Grafana’s Logs Drilldown is a point-and-click way to investigate logs without writing queries. Drilldown lets you break the logs down by service, label, pattern, or any other field, and narrow the selection one click at a time until the problem is in view. It’s a powerful tool, but it only works with Loki. So we built the same experience into the VictoriaLogs data source. We’re happy to announce that the VictoriaLogs data source for Grafana now ships with Drilldown integration.

The best thing that can happen to an open-source project is to find its way into some of the world’s largest technology companies. In September 2026, this happened twice in one week: VictoriaMetrics is now officially bundled in the self-managed edition of NVIDIA’s Cloud Functions, and I learned that CoreWeave is using VictoriaMetrics as the metrics backend for all of its infrastructure customers. Both companies adopted VictoriaMetrics independently.

What actually makes a logging system fast? That was the question behind Tech Talk. And if you were expecting the answer to be a collection of clever Go optimizations, Jesús Espino, Principal Engineer at VictoriaMetrics, made an important point pretty early in our conversation: A huge part of VictoriaLogs’ performance comes from architecture and data structures. The micro-optimizations come later. Now that gave my Tech Talk partner in crime, Mathias Palmersheim, and me plenty to dig into.

Modern systems, due to their distributed nature, rarely fail in simple ways. A request might pass through an API gateway, several microservices, a database, a message queue, and a third-party service before a response ever reaches a user. When something slows down or breaks, knowing that something is wrong is only the beginning. You need to figure out.

VictoriaLogs now runs in production everywhere, and many teams running it have told us the same thing: everyone wants new features, but it’s hard to keep upgrading their logging backend every few weeks. They want the mix of stability and up-to-date security that only LTS releases can satisfy. We’re happy to announce the first Long Term Support (LTS) release of VictoriaLogs: v1.52.1. This is the start of a new v1.52.x LTS line.

Another month whooshed by, bringing a slew of updates: 3 vmanomaly and 2 VictoriaMetrics releases, and new versions of vmestimator, VictoriaTraces, and our first ever LTS release of VictoriaLogs. This brings 12 months of stability to VictoriaLogs Enterprise users. But the big one was the launch of VictoriaTraces on VictoriaMetrics Cloud. Finally, we can offer a complete managed observability stack with metrics, logs, and traces. We run it, you use it. This ecosystem update includes.

Imagine this: you are testing the performance of some part of your application. Everything is going smoothly, the numbers look good, and as a last check you turn on Go’s race detector. Then, out of nowhere, it prints a warning you didn’t expect: So you look at it. You look at it again, and again, and you think: “What the…?” The race is between your code and a goroutine you never started, somewhere deep inside net/http. You have no idea how that is possible, or why.

I’m not the one whose phone lights up at 3 a.m. when production breaks. But I’ve spent years working alongside the engineers who are, and I’ve noticed that observability migrations happen for two reasons. Either engineering needed one, or, far more often, a quote landed that looked too good to refuse. The engineers rarely regret the first kind. The second kind they tell me about in year two, usually with a renewal notice in hand.

Most of the time, when we read a file, we do not think much about what happens underneath. You ask for some bytes, you get some bytes. But when getting data off the disk efficiently is at the core of what your application does, what happens underneath starts to matter a great deal, and two identical read() calls can differ enormously in what they cost. So in this post we are going to look at one of the Linux kernel’s optimizations for reading files: readahead.