Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Specify which exceptions SHOULD be recorded #761

Closed
3 changes: 2 additions & 1 deletion CHANGELOG.md
Original file line number Diff line number Diff line change
Expand Up @@ -11,7 +11,8 @@ New:

- Add resource semantic conventions for operating systems ([#693](https://github.com/open-telemetry/opentelemetry-specification/pull/693))
- Add Span API and semantic conventions for recording exceptions
([#697](https://github.com/open-telemetry/opentelemetry-specification/pull/697))
([#697](https://github.com/open-telemetry/opentelemetry-specification/pull/697),
[#761](https://github.com/open-telemetry/opentelemetry-specification/pull/761))

Updates:

Expand Down
36 changes: 35 additions & 1 deletion specification/trace/semantic_conventions/exceptions.md
Original file line number Diff line number Diff line change
Expand Up @@ -13,9 +13,43 @@ exceptions.

## Recording an Exception

An exception SHOULD be recorded as an `Event` on the span during which it occurred.
An exception that escapes the scope of a span
SHOULD be recorded as an `Event` on that span.
Oberon00 marked this conversation as resolved.
Show resolved Hide resolved
Oberon00 marked this conversation as resolved.
Show resolved Hide resolved
An exception is considered to have escaped the scope if the span is ended
while the exception is still "in flight". Note:

* While it is usually not possible to determine whether some exception thrown
now *will* escape the scope of a span, it is trivial to know that an exception
will escape, if one checks for an active exception just before ending the span.
See the [example below](#exception-end-example).
* Special considerations may apply for Go, where exception semantic conventions
might be used for non-exceptions.
See [issue #764](https://github.com/open-telemetry/opentelemetry-specification/issues/764).

The name of the event MUST be `"exception"`.

Note that multiple events (on the same or different Spans)
might be logged for the same exception object instance.
Oberon00 marked this conversation as resolved.
Show resolved Hide resolved
E.g. one event might be logged in an instrumented exception constructor
and another event might be logged when an exception leaves the scope of a span.
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Should we do this? Can we avoid it?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm, it does add information about the path of the exception although the full stacktrace would not be relevant each time. I don't think this can be easily avoided.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Hmm.. is the stacktrace not captured when the exception is generated (at least in some languages)? Also what is the point of having stacktrace twice?

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

There is no point, but you usually dont't know if the exception was already/will again be recorded.

Maybe a clever exporter can do de-duplication.

Copy link
Member Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Note that this is a "Note" stating what I think can happen in practice.

To allow improving this situation, we could do something like assign an ID to each exception when it is first observed and only record the ID for each further occurrence. But that's probably an after-ga thing.


<a name="exception-end-example"></a>

A typical template for an auto-instrumentation implementing this semantic convention
could look like this:

```java
Span span = myTracer.startSpan(/*...*/);
try {
// original code
} catch (Throwable e) {
span.recordException(e); // We know that the exception is escaping here.
throw e;
} finally {
span.end();
}
```

## Attributes

The table below indicates which attributes should be added to the `Event` and
Expand Down