Operations | Monitoring | ITSM | DevOps | Cloud

OpenTelemetry for Go: measuring the overhead

Everything comes at a cost — and observability is no exception. When we add metrics, logging, or distributed tracing to our applications, it helps us understand what’s going on with performance and key UX metrics like success rate and latency. But what’s the cost? I’m not talking about the price of observability tools here, I mean the instrumentation overhead.

How to reduce Cloud Costs (with Open Source!)

We strongly believe that simple observability should be an innovation everyone can afford to benefit from: which is why Coroot is open source, and includes cost monitoring for Azure, GCP, AWS, or your own custom settings. eBPF automatically tracks how each deployment impacts your cloud costs, so you can easily roll back changes and avoid lovecraftian monthly bill when necessary.

Working with GPUs on Kubernetes and making them observable

GPUs are everywhere powering LLM inference, model training, video processing, and more. Kubernetes is often where these workloads run. But using GPUs in Kubernetes isn’t as simple as using CPUs. You need the right setup. You need efficient scheduling. And most importantly you need visibility. This post walks through how to run GPU workloads on Kubernetes, how to virtualize them efficiently, and how Coroot helps you monitor everything with zero instrumentation or config.

Real-Time Observability with ClickHouse, Coroot, and GlassFlow

Coroot is excited to feature an editorial from GlassFlow for our first Open Source Spotlight. We hope to improve the workflow of our global community of SREs and DevOps professionals by sharing exciting projects like Glassflow, which make innovation accessible for everyone through the freedom of open source. If you have an open source or open core project you’d like to see on our blog next, send us a message!

How to Improve Uptime and Achieve Root Cause Analysis (with Open Source!)

Observability doesn’t begin and end at telemetry or your ELK stack: most open source or vendor tools require configuration, dashboard customization, and may not actually pinpoint the data you need to mitigate system risks. Coroot was designed to solve the problem of time-consuming root cause analysis: it handles the full observability journey — from collecting telemetry to turning it into actionable insights. We also strongly believe that simple observability should be an innovation everyone can afford to benefit from: which is why our software is open source.

Peacetime Observability: Spotting Risks Before They Become Incidents

Most of the time, nothing’s broken. Traffic’s flowing, alerts are quiet, and everything seems fine. That’s peacetime, when no one’s getting paged. Coroot helps in both peacetime and wartime. When things go wrong, it guides you to the root cause fast. But during peacetime, it helps you spot risks early, clean up inefficiencies, and prevent those incidents from happening in the first place.

We built AI-powered Root Cause Analysis that actually works

Figuring out why things break still sucks. We’ve got all the data: metrics, logs, traces, but getting to the actual root cause still takes way too long. Observability tools show us everything, but they don’t really tell us what’s wrong. So why do we even need to automate root cause analysis? First, time. Outages are expensive. And if your system has hundreds or thousands of services, digging through everything by hand just takes way too long.

Troubleshooting Java Applications with Coroot

Java applications run on top of the JVM — a powerful but complex runtime environment that re-implements many OS features. It has its own memory management, garbage collector, and dynamic code compiler (JIT). While these features help with performance and portability, they often make troubleshooting a real challenge. At Coroot, we recently improved our support for continuous profiling in JVM-based applications.

Team-Oriented Observability with Coroot

Modern apps are built by many teams, each owning a different set of services: APIs, background jobs, databases, platform components, and more. As the system grows, it gets harder for each team to focus on what actually matters to them.When everything is mixed together, dashboards get messy, service maps are too large to be useful, and alerts end up reaching the wrong people. Instead of helping, your observability stack turns into a distraction. It has lots of data, but no clear context.