A registry of what telemetry OpenTelemetry components actually emit, pinned to upstream versions.
Note: The telemetry emissions in these files were detected by LLM analysis of the upstream source and may contain errors. Verify against the component's source or docs before relying on a row for critical decisions.
Layout
<repo basename>/<path in repo>/v<version>.md
Example: opentelemetry-collector-contrib/receiver/kafkareceiver/v0.158.0.md
One file per scanned version. The files in a component directory are its
telemetry history; index.md lists every file — start there to see what is
covered.
Looking up a component at a version
- Find the component's directory (or its row in
index.md). - Pick the file matching the target version exactly.
- If there is no exact match, use the file with the highest version below the target and say the exact version is unverified.
- If the component or version is not covered at all, say so — do not infer telemetry from semantic conventions.
What a data file contains
Frontmatter (repo, path, version, scope_name, source_commit,
last_verified), then per-signal tables:
- Traces — span name, kind, attributes, notes
- Metrics — metric name, instrument type, unit, attributes, notes
- Logs — log/event name, attributes, notes
scope_name is the component's instrumentation scope — the anchor for
matching runtime telemetry back to the component. Absent signals are omitted
entirely. Notes marks conditional emission (feature gates, opt-in config,
experimental semconv). Sources lists the upstream files the data came from.