Operations | Monitoring | ITSM | DevOps | Cloud

Historically, non-technical stakeholders would’ve had most of their data questions answered either through pre-built dashboards or by asking their Data team (or equivalent). Self-serve analytics tools went a step further by offering safe, governed datasets built by Data teams which let non-technical users dig into data without having to worry about how it joins together, how metrics like “revenue” are defined, and so on.

AI has quickly become one of the largest and fastest-growing enterprise expenses, exposing many of the same governance and visibility challenges organizations previously faced with cloud. Based on findings from the 2026 State of AI in FinOps report, we explore how mature organizations improve AI cost ownership, reduce waste, and build a culture focused on measurable business value.

Recently someone on our team opened a traffic snapshot and found an HTTP request that was captured with our eBPF capture agent, nettap. Our protocol dissector parsed most of the response correctly, but that correctness ended once the response headers were processed. What they ended up with was a recording of an HTTP request/response where the response body was just an incorrect collection of garbage binary data when it should have been JSON text.

Terraform gives you two ways to express the same infrastructure. You can declare resources directly, or you can wrap them in a module and call that module with inputs. Both produce identical cloud objects. The choice is not about capability, it is about where you want the complexity to live and who you want to be responsible for it. Most teams get this decision wrong in one of two directions.

An AI sandbox is an isolated environment where code from an AI coding agent runs without direct access to your machine or your production systems. If the agent runs a destructive command or a mistaken script, the damage stays contained inside the sandbox. Developers use AI sandboxing to let agents execute code freely while keeping the host and its credentials out of reach.

An incident is open and the evidence is scattered. The application logs point to a connection timeout; the load balancer shows nothing unusual, and the container that produced the original error was replaced eighteen minutes ago. Three engineers are logged into three separate hosts running the same search, and the log line that would explain it has already rotated away. That is the moment most teams start shopping for a log file analysis platform.

Dynatrace gives engineering teams deep, real-time visibility into every service they run. That visibility is the foundation of every effective reliability practice, and it's exactly the foundation Gremlin is built to extend. Once you can see how your distributed systems behave today, the next step is knowing how they'll behave under failure tomorrow—and to do it before those failures happen.