Recording exception as standalone events

[scheler]

Changes

Added semantic convention for recording exception on standalone events.

NOTE on when to use what for recording exceptions:

1. When exception occurs in the context of a span, it MAY be recorded as a Span Event with name exception and attributes exception.*.
2. When Log Bridge API is used to map exceptions from logs to OpenTelemetry LogRecords, the exception MAY be recorded as a LogRecord using the exception.* attributes.
3. In other cases, the exception MAY be recorded as an Event with name exception and attributes exception.*.

--

Note: if the PR is touching an area that is not listed in the [existing areas](https://github.com/open-telemetry/semantic-## Merge requirement checklist

• CONTRIBUTING.md guidelines followed.
• Change log entry added, according to the guidelines in When to add a changelog entry.
  • If your PR does not need a change log, start the PR title with [chore]
• schema-next.yaml updated with changes to existing conventions.

[martinkuba]

nit: two blank lines, probably failing lint

[martinkuba]

I feel like we may need to document somewhere the difference of capturing exceptions as events vs logs. IMO, it is clear that "event exceptions" are the same as span exceptions - both captured as events with name exception. Log exceptions, I think, are captured only from logging frameworks as ERROR logs? Should backends interpret event exceptions and log exceptions as the same thing, or is it important to note the difference?

[lmolkova]

Can we entertain the idea of recording stack trace in the payload and not in the attribute to avoid all the common problems (parsing, truncation, etc) ?

[scheler]

@lmolkova Can you elaborate a bit on how recording the stacktrace in the Event Payload (LogRecord Body) address those issues? Even within the any type field, the data would still have to be put into the standard primitive types.

[trask]

Check out open-telemetry/opentelemetry-specification#2839

[scheler]

@trask thanks for the pointer. I guess we were taking the simplistic approach of keeping the exception event consistent with exception spans and exception logs. However, I can see that moving the exception data to Event body/payload would allow us to have richer data in the Event. For eg., in addition to the structured vs plaintext stacktrace representation, we could add context or additonal_data to the Event to capture arbitrary objects which is not possible with attributes which only allow primitive types currently.

[arminru]

Suggested change

	* Spans and Events: Exception recording in Spans and Events follows a similar pattern. Both utilize the event name `exception`. Exceptions MAY be recorded within Span Events if they occur during the span's lifecycle.
	* Spans and Events: Exception recording in Spans and Events follows a similar pattern. Both utilize the event name `exception`. Exceptions SHOULD be recorded within Span Events if they occur during the span's lifecycle.

Is there any reason why we'd diverge from the stable spec statement that makes this a SHOULD here in semconv?
https://opentelemetry.io/docs/specs/otel/trace/exceptions/

[trask]

Suggested change

	* Spans and Events: Exception recording in Spans and Events follows a similar pattern. Both utilize the event name `exception`. Exceptions MAY be recorded within Span Events if they occur during the span's lifecycle.
	* Spans and Events: Exception recording in Spans and Events follows a similar pattern. Both utilize the event name `exception`. Exceptions MAY be recorded as Log-based Events even if they occur during the span's lifecycle.

[trisch-me]

please add changelog entry correctly

[trisch-me]

We are not updating changelog directly. Please check requirements in the description of your PR

[github-actions]

This PR was marked stale due to lack of activity. It will be closed in 7 days.