Ep 1015 Tool 4:43 w/ Asteria & Draco

Exploring the OpenTelemetry Instrumentation Ecosystem

Asteria and Draco dig into OpenTelemetry’s new Ecosystem Explorer as a way to turn instrumentation from a documentation hunt into something you can actually inspect, compare, and trust before shipping. They focus on the user story for adopters and maintainers, the gap between stable semantic conventions and real implementations, and why making coverage visible may matter as much as the conventions themselves.

Embed this episode

Paste this on any site — the player is a self-contained iframe with no cookies or trackers.

<iframe src="https://sandrise.io/exploring-next/embed/1015"
  width="100%" height="180" style="max-width:640px;border:0;border-radius:12px;overflow:hidden"
  title="Exploring Next — Episode 1015 audio player"
  loading="lazy" allow="autoplay" referrerpolicy="strict-origin-when-cross-origin"></iframe>
Embed & API docs →
Script GPT-5.4 mini Voice Deepgram Aura-2

Transcript

Asteria This is the kind of thing that should have existed already. If I’m choosing an instrumentation library, I do not want to spelunk docs, repos, and release notes just to learn what spans I’m buying.

Draco Right, because the annoying part isn’t the abstract spec. It’s that a stable semantic convention does not mean the code in the wild has caught up, or that every optional bit shows up the same way.

Asteria Exactly. And that gap is the whole story here. OpenTelemetry finally has a site that catalogs components and tells you, version by version, what they describe and what changed.

Draco Mm-hm.

Asteria For the Java side, you can pick a version and see the described telemetry plus the configuration that affects it. That is genuinely useful before an upgrade, not after your dashboards drift and everybody starts guessing.

Draco And the Collector is in there too, which matters because people always treat it like plumbing until the plumbing is the thing you need to verify. The nice part is that this is not just a static catalog of vibes.

Asteria No, it’s trying to connect to conformance runs. That’s the clever bit. Instead of only reading what a component claims, you can compare it against small test scenarios that actually collect telemetry and check it with Weaver live-check.

Draco That part I like. The article is careful about it, too. Not seeing an attribute once does not prove the library never emits it, because configuration and scenario matter, and optional fields are allowed to be absent.

Asteria Yeah, and that restraint makes it feel real. The current JSON reports are enough to show where implementations are missing expected signals, but they’re not pretending to be omniscient.

Draco Which is good, because otherwise this turns into benchmark theater for observability. But here the question is narrower and more useful: did the agent or library actually emit the thing the convention says it should?

Asteria And the user story is broader than maintainers, honestly. If I’m building a dashboard or a vendor integration, I want to know whether an attribute is safe to rely on, whether I need a fallback, or whether I should just file a fix.

Draco Yeah. And the Java SIG already seems to be using this as a progress tracker toward the Java agent three point zero release. That’s the kind of adoption signal I trust more than a glossy launch page.

Asteria Okay, zooming out for a second, this is very on-brand for the whole observability market right now. OpenTelemetry keeps stripping away lock-in, but the hard part is moving from shared vocabulary to shared evidence.

Draco Right, and that evidence layer is where this gets interesting. You can have stable HTTP conventions from November twenty twenty-three and database conventions from May twenty twenty-five, but the ecosystem still needs a way to show who actually implemented them.

Asteria Mm-hm.

Draco The proposed post-graduation roadmap apparently wants better tooling and lower maintenance costs, and this is a pretty clean fit. Make the gaps visible, and you give SIGs, contributors, and project leadership something concrete to work on.

Asteria Plus the weirdly practical part: they want to reuse the same structured definitions in docs, validation, and the Explorer. That is such a boringly sensible move, which is probably why it works.

Draco Yeah, that’s the good kind of boring. Weaver gives projects a common home for telemetry definitions, and then the Explorer can consume that instead of everyone inventing a fresh schema scrapbook.

Asteria And they’re not saying Weaver is mandatory, which I appreciate. If a project has its own formats, fine, start there. Just make the telemetry intent visible, keep it current, and stop making users reverse-engineer the library like it’s a puzzle box.

Draco That last bit is the real punchline. The thing that wins here is not just better docs. It’s making implementation drift inspectable so you can tell what’s actually shipping, not what the convention hopes is shipping.

Asteria Yeah. That’s the part I’d want if I were choosing between three instrumentation paths and trying not to be surprised later. Also, this is extremely an Exploring Next conversation, which feels rude on a Saturday.

Draco We have been doing this since November and somehow still end up here, staring at telemetry catalogs like it’s normal.

Asteria Draco, it is normal. Sadly. Anyway, I’m glad this one exists, because I’d much rather argue with a visible gap than with a mystery.