Semantic conventions for exceptions in logs

Status: Stable, except where otherwise specified

This document defines semantic conventions for recording exceptions on logs emitted through the Logger API.

Recording an exception

OpenTelemetry Semantic Conventions authors SHOULD define exception events according to this document. This guidance is also recommended for application developers and instrumentations not hosted in OpenTelemetry. This document does not apply to logging bridges.

Exceptions SHOULD be recorded as attributes on the LogRecord passed to the Logger emit operations.

Exception events emitted by instrumentations that also record spans for the same operation MUST be associated with the corresponding span context.

When language implementations support passing exception instances to the Emit a LogRecord API, instrumentations SHOULD provide the exception instance rather than manually setting individual exception attributes.

Instrumentations SHOULD record exceptions as events.

When not to record exceptions

Status: Development

Some libraries, frameworks, or runtimes generate artificial exceptions for operations that end with an unsuccessful error code. When possible, instrumentations SHOULD NOT record these artificial exceptions.

For example, FastAPI in Python recommends raising HTTPException instead of returning a response with an unsuccessful status code. Similarly, Spring in Java provides ResponseStatusException.

Event name

Status: Development

It is RECOMMENDED to provide an event name that describes the instrumented operation with a .exception suffix.

For example, http.client.request.exception represents exceptions that occur during an HTTP client request.

Instrumentations that are not specific to a particular operation or domain, such as global unhandled exception handlers, SHOULD use the exception event name.

Severity

Status: Development

The severity reflects the expected impact of the exception, not just its presence.

Severity Number SHOULD be provided on all exception events and SHOULD be set based on the context in which the exception occurs, following the guidance below.

FATAL severity

Exceptions that usually result in application shutdown SHOULD be recorded with severity FATAL (severity number 21).

Examples:

• The application detects an invalid configuration at startup and shuts down.
• The application encounters an out-of-memory condition.

ERROR severity

Exceptions that are unhandled by application code and don’t result in application shutdown SHOULD be recorded with severity ERROR (severity number 17).

Semantic conventions that define SERVER or CONSUMER spans SHOULD also define a corresponding exception event and recommend using ERROR severity.

Examples:

• A messaging consumer terminates message processing with an exception.
• An HTTP server framework error handler catches an exception not handled by the application code.

WARN severity

Exceptions that are expected to be handled by application code SHOULD be reported with severity WARN (severity number 13).

Semantic conventions that define CLIENT or PRODUCER spans SHOULD also define a corresponding exception event and recommend using WARN severity.

Examples:

• A connection attempt to a remote service times out.
• Writing data to a file results in an I/O exception.
• A client library call fails after exhausting retries because the underlying service is unavailable. The client library instrumentation records a single WARN log; logging of individual retry attempts is left to the lower-level instrumentation.

INFO severity

Application developers may use INFO severity (number 9) to record exceptions.

DEBUG severity

Exceptions that don’t indicate an actual issue SHOULD be recorded with severity DEBUG (severity number 5).

For example, an exception indicating that a request was cancelled on the client side is thrown on the server and detected by the server instrumentation.

TRACE severity

Application developers may use TRACE severity (number 1) to record exceptions. Semantic conventions authors SHOULD NOT define exception events with TRACE severity.

Attributes

The table below indicates which attributes should be added to the LogRecord.

Instrumentations MAY provide additional attributes to describe the context in which the exception occurred. Instrumentations that also record spans for the same operation MAY provide a configuration option to populate exception events with attributes captured on the corresponding span.

Attributes:

Key	Stability	Requirement Level	Value Type	Description	Example Values
exception.message		Conditionally Required [1]	string	The exception message. [2]	Division by zero; Can't convert 'int' object to str implicitly
exception.type		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.stacktrace		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:

[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

Same as Trace Semantic Conventions for Exceptions - Stacktrace Representation.