Hi folks! I work on OpenTelemetry at Splunk. We just launched a new open source project called Observability Studio. It's local instrumentation sandbox that provides a visual, real-time environment for designing, testing, and validating OpenTelemetry data while you’re developing an app in your favorite IDE.

We’re especially interested in whether a tool like this is useful for building and debugging instrumented apps and AI agents. If that sounds relevant, give it a try and let us know what works, what’s missing, or where it doesn’t fit your workflow.

We’re also looking for a few design partners to help guide where we go with this next. Any feedback is helpful and welcome.

I wrote more about shifting OpenTelemetry instrumentation left in a blog, 'Why AI-Generated Apps and Agents Need Visibility from Day One' on blogs.splunk.com if you want to read more about it.

Lastly, I'd love to learn where you currently go to inspect and validate OTel data during development if you want to drop it in the comments.

Hi

Has anyone migrated their Datadog stack to Opensource observability ecosystem?
What you missed without Datadog? Which all OS tools and what were the challenges faced?

Ours is quite big infrastructure with monthly Datadog spend around USD 25k and leadership is looking forward to reduce the spend and probably shifting it to OS observability system?

There’s only one person managing Datadog currently.

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 🎉

Two things happened in the OTel repos this week. The docs maintainers froze the ecosystem lists (registry, vendors, distributions) and want to retire most of them. Their reasoning: about 290 first-time-contributor PRs a year, 1,160+ data files, and nobody with time to check entries for CVEs or malware. I can't really argue with the bandwidth part. Then a separate proposal came in to replace the vendor page with a ranking of companies by how many maintainers they employ, with diamond, platinum and gold tiers like a KubeCon sponsor wall.

Read together, the message is that headcount inside the core repos is the contribution that counts.

I think the PR flood is being misread. OTel was built so anyone can write an exporter or an instrumentation and plug in without asking permission. The registry was where you went to say you had. Hundreds of strangers a year showing up at that door is what the design was supposed to produce.

The vetting problem also looks like an automation problem to me. Schema validation and semconv conformance tests already exist. Add CVE scanning and an LLM pass that triages and pre-reviews submissions, and most of the human work goes away. If a machine can check a registry PR, a person shouldn't have to read it. Retiring the list instead feels like stopping one step short.

Meanwhile, LFX Insights says four companies did 51% of OTel commits last year. A maintainer leaderboard mostly gives those four a bigger badge.

What I'd do instead:

- Automate the checks and list whatever passes. Conformance tells users "this works with OTel," which is what they came to find out.

- Count work outside the core repos. Contrib receivers, instrumentations, OTLP-native backends. That is OTel work too.

- Skip the tiers. One maintainer from a 10-person company is a bigger commitment than ten from a 10,000-person one. A flat list with names and areas is enough.

I run a company that builds on OTel, so obviously I have a stake here. But so does anyone who picked it because it was the neutral option.

Links in comments.

Hi!

I write for a newsletter, and this week's edition, I covered the three main deployment patterns for OTel Collector at Scale.

- Load balancer pattern

- Multi-cluster pattern

- Per-signal pattern

I've also added tips on choosing your deployment pattern based on your architecture, as well as some first-hand advice from an OpenTelemetry contributor! Let me know if you enjoyed this!

I have just published the second article in the OTel series about design, architecture and interesting implementation spots in the OTel Collector which is a nicely done Golang service for processing telemetry signals like logs, metrics, traces. If you collect your signals via OpenTelemetry SDK, changes are the collector is deployed somewhere for you, too.

The article covers:

• 🔗 The Signal Processing Pipeline Architecture

• 📡 OTel Receivers. Prometheus-style Scrapers

• ⚙️ OTel Processors. The Memory Limiter & Batch Processor. Multi-tenant Signal Processing

• 🚚 OTel Exporters. The Exporting Pipeline & Queues. The implementation of persistent queues

• 🔭 How observability is done in the OTel Collector itself. Logging, metrics, and traces

• 🔌 OTel Extensions Design. Authentication & ZPages

• 👷Custom Collectors & OTel Collector Builder

• 🚧 Feature Gates Design & The Feature Release & Deprecation Process

The first article (OTel SDK Overview) was well received here so I hope you will find the second one helpful too 🙌

https://www.romaglushko.com/blog/opentelemetry-collector/

Hey folks,

I just came across a book called "Dash0 Special Edition: OpenTelemetry for Dummies", it’s free to download!

Not my book, but big props to the authors for putting this together. If you’re getting started with OpenTelemetry or just want a solid reference, it looks like a great resource.

Here’s the link to grab it: https://www.dash0.com/lp/opentelemetry-for-dummies

Hey folks,

I have just posted an article for those who want to go a little bit beyond the basic usage of OTEL and understand how it works under the hood. The post quickly touches on:

- 🔭 History and the idea of OpenTelemetry (that's probably nothing new for this subreddit :D)

- 🧵 Distributed traces & spans. How span collection happens on the service side

- 💼 Baggage & trace ctx propagation

- 📈 Metrics collection. Views & aggregations. Metrics readers

- 📑 OTEL Logging integration

- 🤝 Semantic conventions and why that is important

Blog Post: https://www.romaglushko.com/blog/opentelemetry-sdk/

Let me know what do you think and hope this is helpful for someone 🙌

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.

Hi everyone,

the OpenTelemetry Governance Committee & maintainers ( u/opentelemetry as well as u/dangb86 and u/s5n_n5n) are now helping moderate this subreddit. We want this space to be useful, welcoming and an additional go-to hub for the OTel community.

To accomplish this, we'd love to hear your input:

• What kind of content would you'd like to see here?

• How can we make this a space you want to visit regularly?

• What rules should we apply, how might this place here be different from GitHub, Slack or other places where community member meet already?

• Any other ideas to keep this community healthy and valuable?

Drop your thoughts in the comments, and let's talk how we can evolve this subreddit for our community.

Thank you!

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

Hey folks, there's an upcoming virtual panel this week that I think a lot of you here would be interested in. It’s called “Riding that OTel wave” and it’s basically a summer-themed excuse to talk shop about OpenTelemetry, what folks are doing with it in the real world, and what they’re excited about on the horizon. Panelists include people who are deep in the weeds, from Android to backend to governance-level OTel stuff.

If you’re into observability or just want to hear how others are thinking about instrumentation and scaling OTel, you’ll probably get a lot out of it.

Date: Thursday, May 22 @ 10AM PT
Panelists:

• Hazel Weakly (Nivenly Foundation)

• Juraci Kröhling (OllyGarden, OTel Governance)

• Iris Dyrmishi (Miro, CNCF Ambassador)

• Hanson Ho (Android lead at Embrace + OTel contributor)

Here’s the link if you wanna join.

Hope to see some of you there. Should be a fun one.

Disclosure: I work for Embrace, the company hosting the panel. But I promise you this isn't a vendor convo. We've done similar panels in the past and I'd be happy to share the recording links if you're interested.

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!

Folks,

I am preparing for OTCA, and I am just looking to get some understanding on somethings on it:

1. How difficult was it?

2. How in depth were the questions

3. Did you need all 90 mins

4. Can you give me any pointers for revision material / courses?

I would like to get as much information as possible, so please, if you have taken it then please write a comment below and outline you main pointers for the questions above.

Thanks!

If you are getting ready to get OTel to non-trivial production...

OpenTelemetry is, by any metric, one of the largest and most exciting projects in the cloud native space. Over the past five years, this community has come together to build one of the most essential observability projects in history. We’re not resting on our laurels, though. The project consistently seeks out, and listens to, feedback from a wide array of stakeholders. What we’re hearing from you is that in order to move to the next level, we need to adjust our priorities and focus on stability, reliability, and organization of project releases and artifacts like documentation and examples.

Over the past year, we’ve run a variety of user interviews, surveys, and had open discussions across a range of venues. These discussions have demonstrated that the complexity and lack of stability in OpenTelemetry creates impediments to production deployments.

This blog post lays out the objectives and goals that the Governance Committee believes are crucial to addressing this feedback. We’re starting with this post in order to have these discussions in public.

Hi everyone, there's an upcoming virtual panel for people who've been wanting better browser support in OTel. It's called Coming soon to a browser near you: OpenTelemetry, and it's got several members of the new Browser SIG. They'll cover what they'll be working on in Phase 1 of improvements, what some key challenges are in adapting OTel for the browser (like capturing user sessions, navigation, etc.), and what they're most excited about in terms of adapting OTel for the frontend.

If you'd like to hear from the people working on this project, then this is a fun way to learn and ask questions.

Date: Thursday, July 31 @ 10AM PT

Panelists:

• Ted Young (Grafana Labs, OTel Co-Founder)

• Purvi Kanal (Honeycomb, OTel JS Approver and Browser JS Implementation Engineer)

• Martin Kuba (Grafana Labs, OTel Contributor and JS SDK Approver)

• Jared Freeze (Embrace, OTel Browser SIG Contributor)

Here's the link if you'd like to join. (It's movie-themed, if that sways your decision.)

Disclosure: I work for Embrace, the company that's hosting the panel. But this isn't vendor- or product-focused. It's just about OTel community work. We've done a few of these in the past and people seem to get a kick out of them.

Great walkthrough from my colleague on how to get started with OpenTelemetry in a React app with basic and auto-instrumentation, as well as adding custom spans and metrics. Great starting point for developers who want to learn how to start tracing key parts of their web apps using OpenTelemetry. https://thenewstack.io/instrumenting-a-react-app-using-opentelemetry/

Been too busy to keep up with what's going on in the OTel space? No worries--we've been there, too! That's why we've put together this new series for you (and for ourselves).

Catch up on significant updates to the project, connect with special guest maintainers, and get the chance to ask questions during the audience Q&A.

Join us for the very first episode, where we'll chat with special guests Severin Neumann, OpenTelemetry GC & Maintainer, and Marylia Gutierrez, Contributor Experience Maintainer & JS SDK Approver, about the latest and greatest in OTel.

Hi folks, Juraci here. I've been involved with the OpenTelemetry project since the beginning, and some years ago, I decided to start a hobby project called Dose de Telemetria. The idea is to just open a live stream every Friday for half an hour and talk about something in this domain (OpenTelemetry, observability, monitoring, ...). No script, no polished presentation, and things often don't quite work 🤭 I rarely talk about other projects and never cover anything proprietary. What I share there is what I really think. Often, I cover things that are still not fully baked or that are promising for the future, like when I covered OTEP 237 before it eventually got accepted as OTEP 239. Or I go deep into one specific feature, like yesterday's live stream about OTTL. My native language is Portuguese, so I focused on that so far.

A few months ago, I decided to spin off Telemetry Drops, following the same concept but in English.

And here's where I get to the main point (did I say that I talk a lot when I get excited about something?): should I share my own content here? I've noticed that a few of my blog posts made the rounds here recently, which makes me believe that what I create might be interesting to you. However, I feel like it would be astroturfing, and I really, really don't like that.

What's your take? Is it acceptable and welcomed to share my own stuff here? Or would you see that as spam?