Investigate how to best combine `sentry-opentelemetry-*` with OTLP

[adinauer]

Description

Some customers prefer to use OTLP over having Sentry hook into OpenTelemetry inside the SDK.

While it should be possible to use OpenTelemetry SDK (not sentry-opentelemetry-*) and combine it with Sentry SDK (again not sentry-opentelemetry-*), customers would miss out on benefits we get from OpenTelemetry (especially their Java Agent and Spring Boot integration).

These benefits are:

• Sentry Scopes propagation, i.e. making Sentry work properly with certain libraries (e.g. RxJava, Reactor)
• Picking up incoming tracing info and attaching outgoing tracing info for more libraries to have better distributed tracing

Off the top of my head, we'd require some changes to the SDK:

• probably a flag (OTLP mode), telling the Sentry SDK to not register certain hooks, only relevant for Performance / Spans (but keep hooks we need to gain the benefits mentioned above)
• SentrySampler could just not be registered if the flag is enabled, not quite sure about consequences of this without deeper investigation since it might break some things
• Propagator might need to work differently but maybe it's also OK to just have it do some unnecessary work; but also could break things if kept as is in OTLP mode
• OtelSentrySpanProcessor likely also needs to be adapted, e.g. to perform isolation scope forking (if we don't want Sentry integrations to take over this part which would likely be incomplete due to lower library coverage compared to OTel)
  • Other SDKs do not fork isolation scope in span processor but rely on integrations to fork

[linear]

JAVA-303

[maxkosty]

This is what currently works in Python:

then

[adinauer]

Here's some options on what we could implement:

A POTel light / OTLP_ENHANCED mode

• Skips registering certain hooks in OTel but still relies on OTel for Scopes propagation via Context
• Uses OTLP in OTel instead of our SentryExporter

B. A separate JAR for combining Sentry and OTel

• No new mode in Sentry SDK, it'll behave as if OTel isn't there (may have to set otel mode to OFF)
• A new module / JAR that contains a propagator for use with OTel and an EventProcessor to register in Sentry (similar to OpenTelemetryLinkErrorEventProcessor)
• Customer is expected to run pure OpenTelemetry SDK and register our propagator if they also want to use Sentry SDK for errors, logs, metrics etc.

C OTLP mode

• Sets up our propagator in OTel
• Does not rely on OpenTelemetry Context for storing Scopes so no span processor or storage hooks needed
• Sentry API would not forward its Performance API to OTel
• This is similar to B just adds an explicit OTel mode to the SDK, e.g. to still use sentry-opentelemetry-agent and have it take care of setting up the propagator and event processor

---

Our current plan is to start off by implementing B. Our answer to the OTLP ask then becomes:

If you want Sentry to benefit from OTels improved lib coverage for Scopes propagation, use POTel (or POTel light if we ever implement A).
If you don't need that, just install sentry-otlp-extras (B, actual name tbd) in addition to pure OTel SDK and set it up.