Operations | Monitoring | ITSM | DevOps | Cloud

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.

Earlier this year, we launched VictoriaLogs in VictoriaMetrics Cloud, bringing fast and cost-effective log management to everyone. Today we launch the final major step toward full observability: VictoriaTraces is now available to all cloud users. With this release, you can now manage all three signals, metrics, logs, and traces, in one place with the predictable pricing, reliability, and the operational simplicity you’ve come to expect from VictoriaMetrics.

It’s not the outage, it’s the stretch before you know what actually broke In short: VictoriaMetrics Enterprise support is expertise, not a ticket queue. It’s reactive by design (you reach engineers who know the stack when something breaks), with one proactive service, Monitoring of Monitoring, that watches the health of your VictoriaMetrics observability stack (metrics, logs, and traces).