Feature: Open Telemetry Support

[jamescrosswell]

Summary

Implementation for OpenTelemetry Support #2066.

Enables people to use OpenTelemetry .NET with Sentry. Essentially they can use the OpenTelemetry .NET SDK to instrument their application for tracing and have all of the information collected (plus error logs and all of Sentry's other goodness) available in their Sentry Dashboard!

Testing

I've tested a distributed application consisting of 3 x nodes:

1. A python script instrumented using Sentry, which makes a call to...
2. A minor variant of our Sentry.Samples.OpenTelemetry.AspNetCore application running on http://localhost:5092/, instrumented with OpenTelemetry .NET and Sentry, which makes a call to...
3. A Flask server running on http://[localhost:5000] instrumented with Sentry

This tests that:

• We capture the sentry-trace and baggage headers from inbound requests (from the python script)
• Appropriate transactions/spans get created by the .NET SDK (tests SpanProcessor)
• Trace information gets propagated correctly downstream to the Flask server (Tests SentryPropagator.Inject)

All of that shows up in Sentry like this:

Outstanding issues

• GenerateSentryErrorsFromOtelSpan is Blocked by Record Exception.Data when calling RecordException open-telemetry/opentelemetry-dotnet#2439 (comment).

This is something only our Javascript SDK has. None of the other Sentry SDKs support it.

It's not critical as we already capture errors through the normal exception handlers. It would only be an issue if a particular Otel instrumentation decided to not let exceptions bubble up, and only to report them as Otel events.

[bruno-garcia]

I'm fine with merging this and figuring out the init code on a follow up PR

[bruno-garcia]

This looks good as init code. But do we override someone's propagator if they set something?

[jamescrosswell]

We would yes... that happens in the AddSentry() call. See the comments on that extension:

The default TextMapPropagator to be used by OpenTelemetry.

If this parameter is not supplied, the will be used, which propagates the baggage header as well as Sentry trace headers.

The is required for Sentry's OpenTelemetry integration to work but you could wrap this in a CompositeTextMapPropagator if you needed other propagators as well.

Under the hood the OpenTelemetry SDK just stores this as a static property, so I think the composite propagator is the only way around it. We could try to do something fancy like, if this was set to something other than Noop, we read that out and stuff it in a composite property along with our SentryPropagator and then write it back... essentially emulating a List<TextMapPropagator>.