Exploring the OpenTelemetry Instrumentation Ecosystem

Official OpenTelemetry blog post by Jay DeLuca (Grafana Labs), published 25 September 2026, introducing the Ecosystem Explorer project. Routed by the hub; runner-up ../dev-tooling-wiki.

Tier: T3, not T1

Both existing OTel sources in this spoke (opentelemetry, otel-observability-primer) are T1 — pure artifact facts (what the framework is, its parts). This page is different: its load-bearing claim is a conformance audit the project ran on itself — testing real instrumentation libraries against their own semantic-convention specs and reporting how many pass. Per this wiki's tiering rule, a self-run benchmark is the maker speaking about how well its own ecosystem works, which is T3 even when the publisher is the standards body. The parts of the post that just describe what the Explorer is (a catalog, a comparison tool) would be T1 on their own; the reason this source is here is the audit.

The argument

A stable semantic convention is "more of a starting point rather than a finish line." Publishing a convention does not update the libraries that implement it — that takes separate, uncoordinated work across every language and every library maintainer, and it can lag the spec by years:

HTTP: entered the spec June 2019, reached stable November 2023.
Database: entered the spec May 2019, reached stable May 2025.

Even after a convention goes stable, adoption is not automatic. The post's own audit found HTTP attribute gaps in the OpenTelemetry Java agent after the Java SIG had already adopted the stable HTTP conventions in its 2.0 release — the SIG is now using the same data to track progress toward a 3.0 release.

What the Explorer measures

The semantic-conventions-conformance project (github.com/open-telemetry/semantic-conventions-conformance) runs small, scripted scenarios against real instrumentation and checks the emitted telemetry with Weaver's live-check feature — see otel-ecosystem-explorer for what Weaver is and how the two projects fit together. Results are published as JSON and surfaced on explorer.opentelemetry.io. The post is explicit about the method's limit: "an empty cell means an attribute wasn't observed in these runs, not that the instrumentation can never emit it" — absence of evidence, not evidence of absence.

HTTP client snapshot across seven languages (.NET, Go, Java, JavaScript, PHP, Python, Ruby):

Required attributes (http.request.method, server.address, server.port, url.full) showed up in nearly every instrumentation tested.
Recommended attributes (network.peer.address, network.protocol.version) showed up far less often — the gap the required/recommended split in the spec was meant to make visible, now measured instead of assumed.

Where the metadata comes from

Three sources feed the catalog: code generation, maintainer-written descriptions, and runtime conformance checks (the audit above). The post says Java alone took over a year to go from basic metadata to a full instrumentation catalog — cataloging an ecosystem costs real, ongoing maintainer time, it isn't a one-off script.

Scope and open edges

Today the Explorer catalogs the OpenTelemetry Java agent and the Collector, with release comparisons; other languages are not yet catalogued at this depth.
Weaver is recommended for defining telemetry schemas but not required — other ecosystems can participate with their own formats.
Third-party (non-OTel) projects are named as a goal, not a delivered feature: the post says an earlier registry-freeze effort found that simply listing a project doesn't say what it does, and that onboarding/acceptance criteria for third-party conformance checks are still unresolved.
Call to action: maintainers are invited to bring a single component to the Explorer or conformance project as a starting contribution.

Weakness recorded

Every number in the post is the project's own measurement of its own ecosystem, run with the project's own tool (Weaver), on scenarios the project itself wrote. No independent party has re-run the conformance checks, and the post does not say what fraction of the wider instrumentation ecosystem (beyond Java + Collector) the audit actually covers.

otel-ecosystem-explorer · semantic-conventions · opentelemetry · otel-observability-primer · distributed-tracing · jay-deluca · grafana-labs · platform-ops