Sentry links OpenTelemetry spans to SDK-captured errors

Sentry announced on August 5 that its OtlpIntegration can connect OpenTelemetry spans with errors captured by Sentry SDKs. The engineering post says the integration is available for Python, Ruby, Node.js, Go, PHP, .NET, and Java, with different long-term paths for some SDKs.

Trace context is the missing join key

Sending spans to Sentry’s OTLP endpoint produces a trace waterfall, but a separate Sentry SDK does not automatically know which OpenTelemetry span was active when it captured an error. The integration reads the active trace context and adds trace and span identifiers to Sentry events. That enables navigation from an error to its trace and from a span to related errors.

It also configures an OTLP exporter when needed, while detecting an existing tracer provider to avoid replacing it. The design reduces tight coupling between Sentry SDKs and OpenTelemetry release cycles.

The boundaries prevent false expectations

OTLP does not send exceptions into Sentry error tracking; an SDK is still required. Teams also must choose one tracing system per service to avoid duplicate spans. Logs without shared trace context will not gain error links merely because they use OTLP.

A useful test triggers one known exception inside a traced request and verifies both navigation directions. Then repeat across a service boundary and inspect propagation headers. The failure case is enabling Sentry-native tracing and OpenTelemetry tracing together, producing duplicates and confusing sampling.

The integration offers a practical bridge for teams already standardized on OpenTelemetry. Its value comes from correlation, while correct adoption depends on preserving a single trace owner and keeping the Sentry SDK for error capture.