Operations | Monitoring | ITSM | DevOps | Cloud

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).

August is a month when things typically quiet down. At VictoriaMetrics, however, we kept up the pace. This month saw two VictoriaMetrics releases, vmanomaly updates, a new Tech Talk, and great blog posts from the VictoriaMetrics team you might have missed.

Tech Talks went dark for a few months, and on episode 13 I finally got to ask why. Mathias Palmersheim’s answer, delivered completely straight, was that his users were unhappy with the availability and usability of their feeders and their litter box, and he wasn’t allowed back on stream until that got fixed. The users are two dogs and two cats, and they have titles. Maisie, a Shiba Inu who came to him through a rescue, is the recently promoted chief executive pawofficer.

Every number on your dashboards has a life story. It is born somewhere inside a running process, lives for a while as a few bytes in memory, travels across the network, settles down on a disk in some compressed shape, gets queried thousands of times, slowly loses its resolution as it ages, and is eventually deleted and forgotten forever.

Summary: Jean-Jérôme Schmidt-Soisson, marketing lead at VictoriaMetrics, shows that open source and marketing are not opposites. Open source itself can be a powerful growth engine through trust, community, content, documentation, and discoverability. The article explains VictoriaMetrics’ pull-based marketing strategy, anchored in open-source values, to support adoption and business growth. This is our second article on the relationship between open source and marketing.

Summary: Machine learning-based anomaly detection improves observability by learning normal system behavior instead of relying only on static thresholds. This article explains how vmanomaly, its MCP server, purpose-built skills, and an LLM-powered UI copilot help engineers explore telemetry, investigate anomalies, build MetricsQL queries, select suitable models, apply business constraints, and validate configurations through natural language.