I finally got to write this blog post, I've wanted to write it for a long time now. It contains the different types of sensitive data we've seen so far, where it's coming from, and why it matters. Hope it can be helpful to some of you!
This Thursday, we are having our next OTel Night here in Berlin. You can't miss it!
This edition follows the complete telemetry journey, from instrumenting a Go application to using agents to understand its behavior from the telemetry stored in an observability backend.
Kemal Akkoyun will begin by introducing compile-time instrumentation for Go. He will explain how instrumentation can become part of the build process, allowing applications and their dependencies to produce OpenTelemetry data without requiring manual changes throughout the source code.
Juraci Paixão Kröhling (me!) will then demonstrate how a coding agent equipped with the otel-go skill can instrument and configure a Go application. The agent will use otelc and other OpenTelemetry Go capabilities to inspect the application, select an appropriate instrumentation strategy, configure telemetry export, and verify the result.
Finally, Cedric Ziel will follow the telemetry into the backend. He will show how agents can retrieve actual telemetry, investigate application behavior, and explain what is happening inside a running system.
PS: do you feel like this post should NOT be in this community? Let me know! I had second thoughts myself about it, but thought it would still bring more value than noise (and couldn't think of a better community for it)
One of my last blog posts at Grafana Labs was around vendor neutrality and OTel. Quite a few has changed since 2024, and I thought it's a good time to revisit with 2026 lens.
In short: vendor lock-in isn't as scary today as it once was, as long as the bulk of your workloads are on standards like OTel, and most of the actual lock-in that resides on backends can be "easily" migrated nowadays. But I'm curious about your opinions and actual experience.
I'll tell you a secret: I don't like starting an engagement by telling people that I can cut their costs. I prefer to show them how they can be more efficient in general, and sometimes that means adding stuff instead of removing it.
However, every company out there has excessive telemetry, which is one form of bad telemetry. I'm not afraid to use an absolute here. That's why I have an arsenal of tools for dealing with it, and I describe one of them in this blog post: excessive metric scraping is extremely common, and adjusting scrape intervals is an easy way to reduce waste.
If you need a 10% reduction in your metric volume, read this blog post. You don't need to buy anything from anyone. You can thank me later.
Almost four years ago, I started this cookbook with real world recipes, adapted from cases I've used to reproduce bug reports or show users (and customers) how to accomplish specific scenarios.
I used some tokens today to bring the repo to the latest Collector version, ensuring they all work.
In case you haven't seen this repo before, take a look!
Enjoy 🧑🏼🍳
Hey folks, stopping by today for another announcement: the OTel Compile-Time Instrumentation for Go reached v1!
If you are not a huge fan of eBPF instrumentation (understandably!), but also can't do manual instrumentation, this is a good compromise.
Try it out!
Hey folks, Juraci here. I know the Reddit communities can be sensitive to project announcements, or announcements in general coming from vendors, but I genuinely think a good number of people here could benefit from this one.
We are launching today the OpenTelemetry Agent Skills, an open source set of skills that serve as the base for our products. We're using them for a good variety of things, like in our coding agents to validate and test collector configurations, or instrument applications. Or double check the snippets we've been using in our other blog posts.
They are vendor neutral, non opinionated, and based on what we know from our experience building OpenTelemetry over the years. Use the skills, share your feedback, tell us where they worked and where they failed. Show me your creativity 🧑🏼🎨
While we are not making money on those directly, we do have a commercial interest in seeing them succeed and become truly useful to many of you. I guess what I want to say is: they are not the result of a weekend vibe coding experiment 🙂
And yes, perhaps they might become an official part of the project someday, if we believe there is a vibrant community backing it.
Last Friday, I had the pleasure to have Mike Goldsmith at Telemetry Drops to learn more about the drain processor, an OpenTelemetry Collector component that is useful to understand the log patterns flowing through an OTel Collector pipeline. Once you understand those patterns, you can make your pipeline more efficient: drop the noisy patterns, transform unstructured into structured logs, and so on.
Hope you enjoy the recording, and I'm eager to hear your feedback!
This is one trick I tell people and surprise them most of the time: "the Collector can do this?"
This one took a while to write, the idea came during OTel Night here in Berlin and I noticed that decomposing the config wasn't helpful only for keeping sanity but also to enable small chunks to be tested.
The CNCF technical oversight committee has voted to approve the OTel due diligence document.
This is one of the final steps towards graduation: the thorough due diligence, which included interviews with end users and resolution of the recommendations given in previous steps, has been finished and approved by the TOC 🎉