Your OTel spans, our errors: A Sentry love story in one trace

Summary

Pointing a standalone OpenTelemetry SDK directly at Sentry ingests spans over standard OTLP, but the spans remain disconnected from Sentry error data. Because the separate SDKs share a process without sharing context, Sentry errors lack active OpenTelemetry trace and span IDs. Sentry introduced OtlpIntegration across backend SDKs including Python, Ruby, Node.js, Go, PHP, .NET, and Java to bridge this gap. The integration reads the active OpenTelemetry context, attaches trace and span identifiers to Sentry events, and configures ingestion. This decoupled model replaces the deeply integrated POTel strategy across most languages, except Java, removing mandatory OpenTelemetry dependencies while maintaining unified trace waterfalls.

Context

Using standalone OpenTelemetry SDKs with Sentry's OTLP endpoint left performance spans disconnected from Sentry error data because the separate systems shared a process but not trace context.

Approach / What changed

Sentry introduced OtlpIntegration across backend SDKs to read active OpenTelemetry trace contexts, stamp trace_id and span_id onto Sentry events, and configure standard OTLP span export to Sentry.

Takeaways

• OtlpIntegration configures an OTLP exporter to Sentry and stamps active OpenTelemetry trace and span IDs onto Sentry events.
• Sentry's new strategy decouples backend SDKs from mandatory OpenTelemetry dependencies and release cycles, sacrificing in-process span interleaving for broader portability.
• Automatic SentryPropagator setup is being removed across SDKs to prevent conflicts with custom propagators, making composite propagation an explicit opt-in.

Related reading

• Sentry · May 27, 2026

  You don’t need to pick one: how Sentry and OpenTelemetry work together

  Integrating Sentry into systems already instrumented with OpenTelemetry does not require replacing existing backend SDKs or rewriting service instrumentation. A hybrid architecture pairs the Sentry SDK on the frontend for browser tracing, Session Replay, and logs with existing OpenTelemetry configurations across backend services. Frontend requests propagate W3C traceparent headers to backend endpoints, which then export traces and logs over OTLP directly to Sentry endpoints or through an intermediate OpenTelemetry Collector. Ingested telemetry attaches backend spans and standard Python logs to the initial frontend user actions, establishing a unified distributed trace across the entire request path. Although Sentry's OTLP ingest currently supports logs and traces rather than metrics, dedicated backend Sentry SDKs remain an optional addition later for backend exception tracking and profiling.

  Lazar Nikolov

• Sentry · Jul 9, 2026