-
-
Notifications
You must be signed in to change notification settings - Fork 206
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Feature: Open Telemetry Support #2453
Conversation
…ntry-dotnet into feat/open-telemetry
…ntry-dotnet into feat/open-telemetry
…ntry-dotnet into feat/open-telemetry
…nderstand how tracing relates to quotas better
Co-authored-by: Bruno Garcia <bruno@brunogarcia.com>
Co-authored-by: Bruno Garcia <bruno@brunogarcia.com>
…ntry-dotnet into feat/open-telemetry
Co-authored-by: Stefan Jandl <reg@bitfox.at>
…ntry-dotnet into feat/open-telemetry
…equests don't get included in transactions
…ntry-dotnet into feat/open-telemetry
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm fine with merging this and figuring out the init code on a follow up PR
.AddSentry() | ||
); | ||
|
||
builder.WebHost.UseSentry(options => | ||
{ | ||
options.TracesSampleRate = 1.0; | ||
options.UseOpenTelemetry(); |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This looks good as init code. But do we override someone's propagator if they set something?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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>
.
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:
Sentry.Samples.OpenTelemetry.AspNetCore
application running onhttp://localhost:5092/
, instrumented with OpenTelemetry .NET and Sentry, which makes a call to...http://[localhost:5000]
instrumented with SentryThis tests that:
sentry-trace
andbaggage
headers from inbound requests (from the python script)All of that shows up in Sentry like this:
Outstanding issues
Exception.Data
when callingRecordException
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.