Operations | Monitoring | ITSM | DevOps | Cloud

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.