Add OTEL_SEMCONV_EXCEPTION_SIGNAL_OPT_IN support to record_exception#5323
Open
RKest wants to merge 1 commit into
Open
Add OTEL_SEMCONV_EXCEPTION_SIGNAL_OPT_IN support to record_exception#5323RKest wants to merge 1 commit into
RKest wants to merge 1 commit into
Conversation
Contributor
There was a problem hiding this comment.
Pull request overview
Adds opt-in support for recording exceptions as logs (and optionally duplicating to span events) in the SDK’s Span.record_exception, enabling migration away from span events per the exception-as-logs semantic conventions and the span-event deprecation plan.
Changes:
- Update
Span.record_exceptionto honorOTEL_SEMCONV_EXCEPTION_SIGNAL_OPT_INand emit an exceptionLogRecordcorrelated with the span when configured. - Add end-to-end unit tests covering unset/unrecognized/logs/logs-dup behaviors, correlation, scope usage, and attribute mapping.
- Add a changelog entry documenting the new opt-in behavior.
Reviewed changes
Copilot reviewed 3 out of 3 changed files in this pull request and generated 2 comments.
| File | Description |
|---|---|
| opentelemetry-sdk/src/opentelemetry/sdk/trace/init.py | Adds env-var gated branching in record_exception and a helper to emit correlated exception logs. |
| opentelemetry-sdk/tests/trace/test_record_exception_logs.py | New tests validating exception-as-logs behavior across all opt-in modes. |
| .changelog/5318.added | Notes the new env-var controlled behavior for Span.record_exception. |
💡 Add Copilot custom instructions for smarter, more guided reviews. Learn how to get started.
`Span.record_exception` now honors the `OTEL_SEMCONV_EXCEPTION_SIGNAL_OPT_IN` environment variable, per the semantic conventions for exceptions in logs (https://opentelemetry.io/docs/specs/semconv/exceptions/exceptions-logs/): - unset: record exceptions as span events only (unchanged default) - `logs`: record exceptions as logs only - `logs/dup`: record exceptions as both logs and span events Exception logs are emitted at ERROR severity, correlated with the originating span's context, and use the span's instrumentation scope.
828822d to
e039edd
Compare
| # representation. | ||
| exception_logger.emit( | ||
| LogRecord( | ||
| timestamp=timestamp, |
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Description
Span.record_exceptioncurrently always records exceptions as spanevents. The semantic conventions for
exceptions in logs
and the span-event API deprecation plan
(OTEP 4430,
see also the
Deprecating Span Events
blog post) introduce the
OTEL_SEMCONV_EXCEPTION_SIGNAL_OPT_INenvironmentvariable so instrumentations can migrate exceptions from span events to logs.
This PR makes the SDK's
Span.record_exception(and therefore the__exit__/use_spanpaths that call it) honorOTEL_SEMCONV_EXCEPTION_SIGNAL_OPT_IN:logslogs/dupAny unrecognized value is treated as unset, preserving today's behavior.
Implementation notes:
LoggerProvider, correlatedwith the originating span's context (
trace_id/span_id), atERRORseverity, with
event_name="exception".exception.type,exception.messageandexception.stacktrace. The deprecatedexception.escapedattribute isintentionally omitted from the log representation; it is still set on the
span event when one is recorded (
logs/dupor default).OTEL_SEMCONV_EXCEPTION_SIGNAL_OPT_INis an experimental, transitionalopt-in, so it is kept private to
opentelemetry.sdk.tracerather thanexported from
opentelemetry.sdk.environment_variables.The default behavior is unchanged, so this is fully backwards compatible and
opt-in.
Type of change
How Has This Been Tested?
A new test module
opentelemetry-sdk/tests/trace/test_record_exception_logs.pycovers all modes end to end using an in-memory span exporter and a captured
logger:
logsrecords a log only (no span event)logs/duprecords both a log and a span event(
trace_id/span_id)exception.type/exception.message/exception.stacktracearepopulated and extra
attributesare forwardedexception.escapedattribute is not set on the logThe existing
record_exceptiontests inopentelemetry-sdk/tests/trace/test_trace.pycontinue to pass unchanged.Does This PR Require a Contrib Repo Change?
record_exceptionsignature is unchanged; the new behavior isgated behind an environment variable and defaults to today's behavior.
Checklist:
ruff check/ruff format).changelog/5318.added— rename to matchthe assigned PR number when opening the PR)
record_exceptiondocstring)