Telemetry: retire legacy span attribute dual-emission (useLegacyAttributes)
Summary
pkg/telemetry/middleware.go dual-emits both legacy (pre-OTEL-semconv) and new
span attribute names on every trace span whenever UseLegacyAttributes is
true — the current default. This was introduced in #3729 as a transition
mechanism (see docs/telemetry-migration-guide.md#backward-compatibility) with
an explicit three-stage deprecation timeline:
- Current: default
true, both names emitted.
- Future: default flips to
false (legacy names still available, opt-in).
- Later: legacy names removed entirely.
No release has been pinned to stages 2 or 3. This issue tracks flipping the
default and, eventually, deleting the legacy code path — so the transition
doesn't linger indefinitely.
Scope
Span (trace) attributes only. Metrics/labels have no equivalent legacy
fallback — they were renamed with a hard cutover (see PR #5956) and are out of
scope here. Logs have no dual-emission mechanism today, so there is nothing to
retire on that signal.
What's gated by the flag today
Every occurrence of if m.config.UseLegacyAttributes in
pkg/telemetry/middleware.go — the full old→new attribute mapping is
documented in docs/telemetry-migration-guide.md#attribute-name-mapping:
- HTTP request attributes (
http.method, http.url, http.scheme,
http.host, http.target, http.user_agent, …)
- HTTP response attributes (
http.status_code, http.response_content_length,
http.duration_ms)
- MCP protocol attributes (
mcp.method, rpc.system, rpc.service,
mcp.request.id)
- Tool/prompt attributes (
mcp.tool.name, mcp.tool.arguments,
mcp.prompt.name)
- Transport attribute (
mcp.transport)
Surfaces exposing the flag
- CLI:
--otel-use-legacy-attributes (cmd/thv/app/run_flags.go)
- Config file:
use-legacy-attributes (pkg/config/config.go)
- Operator CRD:
MCPTelemetryConfig.spec.useLegacyAttributes
(cmd/thv-operator/api/v1beta1/mcptelemetryconfig_types.go)
Proposed steps
- Flip the default to
false across all three surfaces above, with a
release-notes callout. Legacy names remain available as an explicit opt-in
for anyone with dashboards/alerts still on the old attribute keys.
- After a further deprecation window, delete the legacy code path in
pkg/telemetry/middleware.go (every if m.config.UseLegacyAttributes
block), the UseLegacyAttributes field from all three surfaces, and the
corresponding sections of docs/telemetry-migration-guide.md.
- Update
docs/telemetry-migration-guide.md to reflect the new state at each
step (this is the doc that currently states the timeline, so it should
track it release-to-release rather than staying static).
Open questions for maintainers
- What release should the default flip land in, and how much notice do
downstream dashboard/alert owners need beforehand?
- Should removal (step 2) be tracked as a sub-task of this issue, or split into
its own follow-up once the default-flip has soaked for a release or two?
Related
Telemetry: retire legacy span attribute dual-emission (
useLegacyAttributes)Summary
pkg/telemetry/middleware.godual-emits both legacy (pre-OTEL-semconv) and newspan attribute names on every trace span whenever
UseLegacyAttributesistrue— the current default. This was introduced in #3729 as a transitionmechanism (see
docs/telemetry-migration-guide.md#backward-compatibility) withan explicit three-stage deprecation timeline:
true, both names emitted.false(legacy names still available, opt-in).No release has been pinned to stages 2 or 3. This issue tracks flipping the
default and, eventually, deleting the legacy code path — so the transition
doesn't linger indefinitely.
Scope
Span (trace) attributes only. Metrics/labels have no equivalent legacy
fallback — they were renamed with a hard cutover (see PR #5956) and are out of
scope here. Logs have no dual-emission mechanism today, so there is nothing to
retire on that signal.
What's gated by the flag today
Every occurrence of
if m.config.UseLegacyAttributesinpkg/telemetry/middleware.go— the full old→new attribute mapping isdocumented in
docs/telemetry-migration-guide.md#attribute-name-mapping:http.method,http.url,http.scheme,http.host,http.target,http.user_agent, …)http.status_code,http.response_content_length,http.duration_ms)mcp.method,rpc.system,rpc.service,mcp.request.id)mcp.tool.name,mcp.tool.arguments,mcp.prompt.name)mcp.transport)Surfaces exposing the flag
--otel-use-legacy-attributes(cmd/thv/app/run_flags.go)use-legacy-attributes(pkg/config/config.go)MCPTelemetryConfig.spec.useLegacyAttributes(
cmd/thv-operator/api/v1beta1/mcptelemetryconfig_types.go)Proposed steps
falseacross all three surfaces above, with arelease-notes callout. Legacy names remain available as an explicit opt-in
for anyone with dashboards/alerts still on the old attribute keys.
pkg/telemetry/middleware.go(everyif m.config.UseLegacyAttributesblock), the
UseLegacyAttributesfield from all three surfaces, and thecorresponding sections of
docs/telemetry-migration-guide.md.docs/telemetry-migration-guide.mdto reflect the new state at eachstep (this is the doc that currently states the timeline, so it should
track it release-to-release rather than staying static).
Open questions for maintainers
downstream dashboard/alert owners need beforehand?
its own follow-up once the default-flip has soaked for a release or two?
Related
stacklok.*, delete legacymetric twins — the metrics-side counterpart to this span-attribute cleanup)
UseLegacyAttributes)