proposal to make code.stacktrace (or code.* namespace) stable

[SylvainJuge]

Area(s)

area:code

Is your change request related to a problem? Please describe.

The code.stacktrace is currently experimental, and we think it would make sense to make it stable.

Current known usages:

• inferred-spans module in Java contrib
• span-stacktrace module in Java contrib

Making this attribute stable would allow making features that rely on it stable, relying on an experimental/incubating attribute transitively forces the feature as experimental/incubating.

Describe the solution you'd like

Making the code.stacktrace attribute stable, or making the whole code.* namespace stable.

Describe alternatives you've considered

Making the whole code.* attributes stable would be an alternative as most of those fields are not ambiguous even if some of their values are platform-specific (the code.stacktrace being a good example).

For now keeping the scope to code.stacktrace is a way to reduce the scope as an attempt to making this change easier.

Additional context

Making this attribute stable was discussed in August 29th Java SIG Meeting where the topic was "how to make a component in java contrib stable".

Steps and progress

• promotion to release candidate: mark code.* attributes as release candidate #1599
• renaming some attributes: rename some code attributes #1624
• clarify some attributes values Clarify values for code.function.name and code.namespace #1677
• promotion to stable

[SylvainJuge]

After a bit of research on trying to find usages of fields in the code.* namespace, I found that we have:

• OpenTelemetry PHP instrumentation already uses code.function, code.namespace, code.filepath and code.lineno: https://github.com/open-telemetry/opentelemetry-php/blob/068086347b41c6d31c545cf9b37e3a9a6c1ff59f/src/API/Instrumentation/WithSpanHandler.php#L39
• OpenTelemetry contrib Java use code.stacktrace in inferred-spans and span-stacktrace modules as mentioned initially in the issue description.

In addition, as described in #1012 we know that the code.function, code.filepath and code.lineno have equivalent ECS (Elastic Common Schema), so while it does not count as direct usage, usages of those equivalent ECS fields can be mapped 1:1 to otel semconv.

When searching for text occurrences of those code.* attributes to see if there are other definitions I did not find anything that would contradict the current definitions, which means there is little ambiguity or things left to interpretation.
For example, I found similar references in:

• NewRelic ruby agent: https://github.com/newrelic/newrelic-ruby-agent/blob/c71c1e38e9b3fe9e4ebd2786aa14c1e7a9d67b9b/lib/new_relic/agent/transaction/abstract_segment.rb#L135
• Sentry UI: https://github.com/getsentry/sentry/blob/4639d43292bfe72866d7edbdcaa2bd28c7bdf914/static/app/views/insights/common/components/spanDescription.tsx#L118

Also, the value and format code.stacktrace is platform-specific and might be left to ambiguity or further specification, however it uses exactly the same definition of exception.stacktrace which is already stable.

[brettmc]

In support of this proposal and as described above, PHP SIG uses code.function, code.namespace, code.filepath and code.lineno extensively throughout our auto-instrumentation packages. We find them very useful and would support them being made stable.

[trask]

I've added this to the next Semantic Convention SIG agenda to ask what the semconv maintainers think

[trask]

it turned out this was discussed previously in Semantic Convention SIG 9/9/2024 😄

• Stability for smaller areas (here: code.*): proposal to make code.stacktrace (or code.* namespace) stable #1377
  • Create a group
  • Look at existing implementations for code.*
  • Maybe: .NET, Android, Go
  • Drive stability for the entire code.* namespace rather than just code.stacktrace

@AlexanderWert @SylvainJuge do you want to move forward with this plan? if so, can you create an issue to recruit members and create a new @open-telemetry/semconv-code-approvers team?