Skip to content

exceptions-spans.md

Latest commit

 

History

History
113 lines (88 loc) · 6.38 KB

exceptions-spans.md

File metadata and controls

113 lines (88 loc) · 6.38 KB

Semantic conventions for exceptions on spans

Status: Deprecated
Use Semantic conventions for exceptions in logs instead.

This document defines semantic conventions for recording application exceptions associated with spans.

Important

Existing instrumentations that record exceptions as span events:

  • SHOULD introduce an environment variable OTEL_SEMCONV_EXCEPTION_SIGNAL_OPT_IN supporting the following values:
    • logs - emit exceptions as logs only.
    • logs/dup - emit both span events and logs, allowing for a phased rollout.
    • The default behavior (in the absence of one of these values) is to continue emitting exceptions as span events (existing behavior).
  • SHOULD maintain (security patching at a minimum) their existing major version for at least six months after it starts emitting both sets of conventions.
  • MAY drop the environment variable in their next major version and emit exceptions as logs only.

Even after instrumentations start emitting exceptions only as logs, users will still have the option to route those to span events at the SDK layer.

Exception event

Status: Stable

The event name MUST be exception.

This event describes a single exception.

Attributes:

Key Stability Requirement Level Value Type Description Example Values
exception.message Stable Conditionally Required [1] string The exception message. [2] Division by zero; Can't convert 'int' object to str implicitly
exception.type Stable Conditionally Required [3] string The type of the exception (its fully-qualified class name, if applicable). The dynamic type of the exception should be preferred over the static type in languages that support it. [4] java.net.ConnectException; OSError
exception.escaped Deprecated
It's no longer recommended to record exceptions that are handled and do not escape the scope of a span.		 Recommended boolean Indicates that the exception is escaping the scope of the span.
exception.stacktrace Stable Recommended string A stacktrace as a string in the natural representation for the language runtime. The representation is to be determined and documented by each language SIG. Exception in thread "main" java.lang.RuntimeException: Test exception\n at com.example.GenerateTrace.methodB(GenerateTrace.java:13)\n at com.example.GenerateTrace.methodA(GenerateTrace.java:9)\n at com.example.GenerateTrace.main(GenerateTrace.java:5)

[1] exception.message: Required if exception.type is not set, recommended otherwise.

[2] exception.message:

Warning

This attribute may contain sensitive information.

[3] exception.type: Required if exception.message is not set, recommended otherwise.

[4] exception.type: If the recorded exception type is a wrapper that is not meaningful for failure classification, instrumentation MAY use the type of the inner exception instead. For example, in Go, errors created with fmt.Errorf using %w MAY be unwrapped when the wrapper type does not help classify the failure.

Stacktrace representation

The table below, adapted from Google Cloud, includes possible representations of stacktraces in various languages. The table is not meant to be a recommendation for any particular language, although SIGs are free to adopt them if they see fit.

Language Format
C# the return value of Exception.ToString()
Elixir the return value of Exception.format/3
Erlang the return value of erl_error:format
Go the return value of runtime.Stack
Java the contents of Throwable.printStackTrace()
Javascript the return value of error.stack as returned by V8
Python the return value of traceback.format_exc()
Ruby the return value of Exception.full_message

Backends can use the language specified methodology for generating a stacktrace combined with platform information from the telemetry sdk resource in order to extract more fine grained information from a stacktrace, if necessary.
⚡