Read Activity data into event (OTEL)
See original GitHub issueASP.NET Core 3.0+ have support to W3C context propagation out of the box. The current SDK already has an options to control whether to read Activity data and some data is already read.
The goal is to read the new values and enhance the SDK and possibly the protocol to read them.
Research
I did a bit of digging into this. From the W3C Spec:
Design Overview Trace context is split into two individual propagation fields supporting interoperability and vendor-specific extensibility:
traceparent
describes the position of the incoming request in its trace graph <…snip…>tracestate
extends traceparent with vendor-specific data represented by a set of name/value pairs. <…snip…>
Given that the data in tracestate
is vendor specific, we’re mainly interested in the traceparent
then.
Traceparent Header The traceparent HTTP header field identifies the incoming request in a tracing system. It has four fields:
- version - specifies the version of the traceparent header.
- trace-id - used to uniquely identify a distributed trace through a system
- parent-id - the ID of this request as known by the caller
- trace-flags - an 8-bit field that controls tracing flags such as sampling, trace level, etc.
Nothing in the W3C Traceparent Header itself is relevant beyond Sentry’s Open Telemetry Integration then.
It looks like what we’re more interested in is anything that could be gleaned from System.Diagnostics.Activity.Current
. In the context of an ASP.NET [Core] application, everything that Microsoft currently store in there is to facilitate distributed tracing. I think the only time it might contain anything else is if one of our SDK users or some third party library was explicitly storing stuff in Activity.Tags
. If they’re doing that, then setting SentryOptions.IncludeActivityData
will already ensure we capture this.
Issue Analytics
- State:
- Created 4 years ago
- Reactions:3
- Comments:9 (5 by maintainers)
Top GitHub Comments
Any update on this? Not having this greatly reduces the usefulness of the SDK.
In particular, third-party libraries that are already instrumented using
Activity
won’t include span information. So instead, we would have to wrap all calls with our own calls toStartChild
. Additionally, the code in our project was already instrumented withActivity
, so to get value out of this, we have to start calling theSentrySDK.*
methods directly.Just an update for everyone. This is still on our radar, and we’re planning out how it would work exactly. We’d like to have support for Open Telemetry in the base .NET SDK, and integrate with ASP.NET Core’s support where appropriate. I’m very open to feedback and suggestions of exactly how this would work and what the APIs would look like.
David Fowler recently posted this thread on Twitter: https://twitter.com/davidfowl/status/1588942067157594112
We could take a similar approach. Or we could try to do more automagically. Thoughts?