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.

Takeaways

1. 1

   OtlpIntegration configures an OTLP exporter to Sentry and stamps active OpenTelemetry trace and span IDs onto Sentry events.

2. 2

   Sentry's new strategy decouples backend SDKs from mandatory OpenTelemetry dependencies and release cycles, sacrificing in-process span interleaving for broader portability.

3. 3

   Automatic SentryPropagator setup is being removed across SDKs to prevent conflicts with custom propagators, making composite propagation an explicit opt-in.