Skip to content

Create Issues from OpenTelemetry exceptions (OTLP exception log records and span events) #127561

Open

Description

@Prithvirajkumar

Problem Statement

Applications instrumented only with OpenTelemetry can send traces and logs to Sentry's OTLP endpoints, but their exceptions never become Issues:

  • Exception span events (the current default way OTel SDKs record exceptions, via span.recordException) are dropped on OTLP ingest. Sentry's docs say "All span events are dropped during ingestion".
  • Exception log records (where OTel is moving exceptions: OTEP 4430, OTEL_SEMCONV_EXCEPTION_SIGNAL_OPT_IN=logs) are stored as logs only.

So OTel-only services get no Issues, alerts, grouping, suspect commits or Seer for their errors, even though the data contains everything an error event needs: exception.type, exception.message, exception.stacktrace (semconv), plus trace and span ids.

Solution Brainstorm

Build on the generic log → Issue capability in #113802, with an exception-aware path for OTel:

  1. Exception log records → error Issues. Records with event_name exception / *.exception, or with exception.type / exception.message attributes, become error events. Severity sets level and handled state (FATAL/ERROR → Issue, WARN optional). The stack trace is parsed from exception.stacktrace (its format depends on the runtime), with cause chains as linked errors and the trace context kept.
  2. Span events → the same path. Instead of dropping exception span events, convert them into exception log records (same attributes, plus the span's trace/span ids) so they go through step 1. Until OTel SDKs default to log-based exceptions, this covers most OTel exceptions in the wild.
  3. De-duplication. In logs/dup mode, SDKs emit both a span event and a log record for the same exception. These should become one Issue (e.g. keyed on span id + message).

Additional Context

Activity

  1. getsantry commented on Oct 15, 2026

    @getsantry
    Contributor

    Assigning to @getsentry/support for routing ⏲️

  2. linear-code commented on Oct 15, 2026

    @linear-code
  3. moved this to Waiting for: Support in GitHub Issues with 👀 3on Oct 15, 2026
  4. getsantry commented on Oct 16, 2026

    @getsantry
    Contributor

    Routing to @getsentry/product-owners-ingestion-and-filtering for triage ⏲️

  5. moved this from Waiting for: Support to Waiting for: Product Owner in GitHub Issues with 👀 3on Oct 16, 2026
  6. bcoe commented on Oct 19, 2026

    @bcoe
    Member

    @Prithvirajkumar are there some customers asking for this functionality, if so could you share some context with me internally.

    Span events → the same path

    From my perspective, if span events weren't deprecated, this would seem like a reasonable feature to implement, but given that span events are deprecated IMO we should not be building on top of them.

    Exception log records → error Issues.

    A user can setup a monitor today on any log attribute, does this affordance give enough value to be worth having a special case like this?

  7. moved this from Waiting for: Product Owner to No status in GitHub Issues with 👀 3on Oct 19, 2026
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Projects

    Milestone

    No milestone

    Relationships

    None yet

    Development

    No branches or pull requests

    Issue actions