Is your feature request related to a problem?
Yes. The plugin only supports OPENCODE_RESOURCE_ATTRIBUTES, which attaches custom
key=value pairs to the OTel Resource (producer-level metadata). Some observability
backends — AppSignal in particular — filter, group, and route telemetry based on
attributes attached directly to spans and metric data points, not on resource fields.
With only resource attributes available, there's no way to tag individual spans/metrics
so they can be segmented in those backends (e.g. by team, environment, or an
app/namespace tag). Today the only workaround is forking the plugin or relying on the
collector to copy resource attributes down onto spans, which many setups (including
AppSignal's direct OTLP ingestion) don't do.
Describe the solution you'd like
Add a new OPENCODE_SPAN_ATTRIBUTES environment variable, parsed the same way as
OPENCODE_RESOURCE_ATTRIBUTES (comma-separated key=value pairs), whose values are
attached to every emitted span, log, and metric data point — not the resource.
Example:
export OPENCODE_SPAN_ATTRIBUTES="team=platform,deployment.environment=production"
Expected behavior:
- The pairs are merged into the common attributes the plugin already applies to all
spans/metrics/logs (alongside project.id), so no per-signal changes are needed.
- OPENCODE_RESOURCE_ATTRIBUTES keeps its current resource-level semantics; the two are
independent and documented side by side (resource = describes the producer,
span = filterable/groupable per data point).
- Empty/malformed pairs are ignored; only the first "=" is treated as the separator so
values may contain "=".
- Unset by default (no behavior change for existing users).
This makes the plugin usable with attribute-based backends like AppSignal without a fork.
Describe alternatives you've considered
- Using OPENCODE_RESOURCE_ATTRIBUTES instead: rejected because those land on the OTel
Resource, not on individual spans/metrics. Backends like AppSignal filter and group on
span/metric-level attributes, so resource attributes don't surface where they're needed.
- Copying resource attributes onto spans at the collector (e.g. an OpenTelemetry Collector
with a transform/attributes processor): works, but requires running and configuring a
collector in front of the backend. It doesn't help setups that export OTLP directly to
the backend (AppSignal's direct ingestion), and pushes plugin configuration into separate
infrastructure.
- Forking the plugin to hardcode the extra attributes: unmaintainable, has to be re-applied
on every upstream release, and isn't shareable with other users who need the same thing.
- Relying on existing per-signal attributes (project.id, session.id, model, agent, etc.):
these are fixed and not user-controllable, so they can't express deployment/team/tenant
dimensions that vary per environment.
A single OPENCODE_SPAN_ATTRIBUTES env var avoids all of the above: no extra infrastructure,
no fork, and it mirrors the familiar OPENCODE_RESOURCE_ATTRIBUTES syntax.
Telemetry type
Logs/Events
Additional context
No response
Checklist
Is your feature request related to a problem?
Yes. The plugin only supports OPENCODE_RESOURCE_ATTRIBUTES, which attaches custom
key=value pairs to the OTel Resource (producer-level metadata). Some observability
backends — AppSignal in particular — filter, group, and route telemetry based on
attributes attached directly to spans and metric data points, not on resource fields.
With only resource attributes available, there's no way to tag individual spans/metrics
so they can be segmented in those backends (e.g. by team, environment, or an
app/namespace tag). Today the only workaround is forking the plugin or relying on the
collector to copy resource attributes down onto spans, which many setups (including
AppSignal's direct OTLP ingestion) don't do.
Describe the solution you'd like
Add a new OPENCODE_SPAN_ATTRIBUTES environment variable, parsed the same way as
OPENCODE_RESOURCE_ATTRIBUTES (comma-separated key=value pairs), whose values are
attached to every emitted span, log, and metric data point — not the resource.
Example:
export OPENCODE_SPAN_ATTRIBUTES="team=platform,deployment.environment=production"
Expected behavior:
spans/metrics/logs (alongside project.id), so no per-signal changes are needed.
independent and documented side by side (resource = describes the producer,
span = filterable/groupable per data point).
values may contain "=".
This makes the plugin usable with attribute-based backends like AppSignal without a fork.
Describe alternatives you've considered
Resource, not on individual spans/metrics. Backends like AppSignal filter and group on
span/metric-level attributes, so resource attributes don't surface where they're needed.
with a transform/attributes processor): works, but requires running and configuring a
collector in front of the backend. It doesn't help setups that export OTLP directly to
the backend (AppSignal's direct ingestion), and pushes plugin configuration into separate
infrastructure.
on every upstream release, and isn't shareable with other users who need the same thing.
these are fixed and not user-controllable, so they can't express deployment/team/tenant
dimensions that vary per environment.
A single OPENCODE_SPAN_ATTRIBUTES env var avoids all of the above: no extra infrastructure,
no fork, and it mirrors the familiar OPENCODE_RESOURCE_ATTRIBUTES syntax.
Telemetry type
Logs/Events
Additional context
No response
Checklist