Experimenting with implicit OpenTelemetry initialization #3229
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Playing around with one idea to implement:
This is a total hack at the moment, just to get an idea of the kinds of challenges involved.
Approach
OpenTelemetry Tracing is configured via a Static API that returns a
TracerProviderBuilderBase
.In the context of a Console application especially (where there's no common
IServiceCollection
for DI), it's relatively difficult to work out whether OpenTelemetry has already been initialized or not. The OpenTelemetry static API doesn't provide anSdk.Current
property or anything similar.However one possible solution might be to leverage our own AddSentry extension method:
sentry-dotnet/src/Sentry.OpenTelemetry/TracerProviderBuilderExtensions.cs
Lines 30 to 35 in 818e404
If we always initialise OpenTelemetry when initializing Sentry, and we do so using the above extension method... we can guarantee it will be called at least once... If this extension method gets called twice, we know the initialization we made internally was unecessary and can either skip our own initialization of the Otel SDK or dispose of any
TracerProvider
we created previously.Broadly speaking, this seems to work... there are a few challenges to making this production ready however.
Challenges
Sdk.CreateTracerProviderBuilder
method. In an ASP.NET Core app we would need to use the OpenTelemetryBuilder extensions instead.