The OtlpIntegration bridges the gap between OpenTelemetry traces and Sentry error tracking across Python, Ruby, Node.js, Go, PHP, .NET, and Java. Without it, OTel spans and Sentry errors run in the same process but share no context — errors don't know which trace caused them, and spans don't know which errors fired inside them. The integration solves this by reading the active OTel trace context and stamping trace_id and span_id onto every Sentry event, enabling bidirectional navigation between errors and trace waterfalls. It replaces the previous POTel deep-integration approach (which remains for Java) with a lighter, SDK-independent model. Setup requires just two environment variables and an init call. Key limitations: errors still require a Sentry SDK (not OTLP), and you can't interleave Sentry and OTel spans in the same process. The automatic SentryPropagator registration is also being removed in favor of explicit opt-in.
Table of contents
Trace connectedness: the problem the raw OTLP endpoint can’t solveWhat the OtlpIntegration does under the hoodWhy this replaced our previous approachTwo env vars and an init callWhere POTel still lives (and where it doesn’t)Who is this for?Traces and logs yes, errors and metrics noPropagation is becoming opt-in3.5K Impressions1 Comment