Add code.stacktrace attribute

[AlexanderWert]

Changes

There are use cases when it's desirable to collect a stacktrace that is not necessarily attached to an exception (e.g. to identify the exact stack of a span).

This PR proposes a new attribute code.stacktrace for the above-mentioned use cases.

Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• CHANGELOG.md updated for non-trivial changes.
• schema-next.yaml updated with changes to existing conventions. (N/A)

[trask]

Would we deprecate exception.stacktrace in favor of this generalization?

[AlexanderWert]

Would we deprecate exception.stacktrace in favor of this generalization?

@trask I wasn't intending to imply changes to exception.stacktrace with that, but I'm open to it if we want to. code.stacktrace would cover other non-exception-related use cases. Also as you can see in the example value in this case the exception message is not present here.

But, you are right that code.stacktrace is a more general attribute that theoretically could be reused / referenced in the exception semantic conventions.

[pyohannes]

Would we deprecate exception.stacktrace in favor of this generalization?

Re-using a generic stacktrace field might be another option (hypothetical until there's progress on #339).

[trask]

Also as you can see in the example value in this case the exception message is not present here.

👍

[jack-berg]

I have also had use cases for including a stack trace outside of an exception and came to the same conclusion that the attribute should be named code.stacktrace.

Thanks for beating me too it 😁!

[Oberon00]

I didn't read everything, but please note that exception.stacktrace is not a plain stacktrace but the default detailed textual exception representation (including, usually, exception type, message, caused-by, etc). There was a long discussion about the name (IIRC I was strongly against exceptions.stacktrace since in many languages there is also the possibility to get a textual representation of just the exception stacktrace), but there is no other common name for that concept.

[AlexanderWert]

I didn't read everything, but please note that exception.stacktrace is not a plain stacktrace but the default detailed textual exception representation (including, usually, exception type, message, caused-by, etc). There was a long discussion about the name (IIRC I was strongly against exceptions.stacktrace since in many languages there is also the possibility to get a textual representation of just the exception stacktrace), but there is no other common name for that concept.

Thanks @Oberon00 , that's also how I understood exception.stacktrace. For code.stacktrace the intention is to capture the textual representation of just the exception stacktrace. What do you think in general about the proposal in this PR?

[trask]

should this have a change log entry?