Open DarkByteZero opened 5 months ago
hey @DarkByteZero - attaching the headers is by intention given distributed tracing does not depend on performance monitoring (generating spans) in Sentry.
When there is no active pageload though the sentry trace should be not attaching a sampled flag. This is indicated by no -1
being attached to d1f4373147294b14ab220450dc8ca2c6-9f0c782faa520627
, like we see in the earlier header acc3a2d245d4404789d4cabe533996d7-bbd6bd5567ae8a87-1
.
The Go SDK should be parsing a sample rate of 0 if this is dropped, @cleptric could you help sanity check this?
I appreciate the intention behind attaching headers for distributed tracing, but what is the reason for sending these trace headers, if there isn't even a parent transaction in the sentry system collected. Another Problem is the frequency at with these traces are changed, like in my image you can see that multiple API requests are aggregated into one trace, but there is a big gap between them, this makes it difficult to debug.
@AbhiPrasad @DarkByteZero We need to change how we do trace propagation without active spans in the frontend. The current implementation has issues and leads to traces like @DarkByteZero outlined. These traces have absolutely no value.
Concretely, we have to do one of two things:
hey @DarkByteZero - attaching the headers is by intention given distributed tracing does not depend on performance monitoring (generating spans) in Sentry.
When there is no active pageload though the sentry trace should be not attaching a sampled flag. This is indicated by no
-1
being attached tod1f4373147294b14ab220450dc8ca2c6-9f0c782faa520627
, like we see in the earlier headeracc3a2d245d4404789d4cabe533996d7-bbd6bd5567ae8a87-1
.The Go SDK should be parsing a sample rate of 0 if this is dropped, @cleptric could you help sanity check this?
The GO SDK does not interpret the absence of the sampled flag as a sampled false. Actually, if it would do, all api transactions would not be sampled, which would be bad.
// updateFromSentryTrace parses a sentry-trace HTTP header (as returned by
// ToSentryTrace) and updates fields of the span. If the header cannot be
// recognized as valid, the span is left unchanged. The returned value indicates
// whether the span was updated.
func (s *Span) updateFromSentryTrace(header []byte) (updated bool) {
m := sentryTracePattern.FindSubmatch(header)
if m == nil {
// no match
return false
}
_, _ = hex.Decode(s.TraceID[:], m[1])
_, _ = hex.Decode(s.ParentSpanID[:], m[2])
if len(m[3]) != 0 {
switch m[3][0] {
case '0':
s.Sampled = SampledFalse
case '1':
s.Sampled = SampledTrue
}
}
return true
}
@AbhiPrasad the absence of the sampling flag delegates the sampling decision to the receiving SDK. There is a defined order of what takes precedence, defined in https://develop.sentry.dev/sdk/performance/#sampling and implemented here https://github.com/getsentry/sentry-go/blob/master/tracing.go#L427-L511.
I think this issue right here is a symptom of the JS SDK having a buggy/confusing trace propagation when no spans are active. We will fix this in the upcoming major (v8). It will lead to slightly less connected-ness within your data but at least unrelated stuff isn't gonna be connected anymore.
Is there an existing issue for this?
How do you use Sentry?
Self-hosted/on-premise
Which SDK are you using?
@sentry/react
SDK Version
7.100.1
Framework Version
React 18.2.0
Link to Sentry event
No response
SDK Setup
Steps to Reproduce
Sentry-Trace: acc3a2d245d4404789d4cabe533996d7-bbd6bd5567ae8a87-1
Baggage: sentry-environment=dev,sentry-release=local_development,sentry-public_key=xxx,sentry-trace_id=d1f4373147294b14ab220450dc8ca2c6,sentry-replay_id=312e9506fc0c4ea883aa4b13d9662a77
Sentry-Trace: d1f4373147294b14ab220450dc8ca2c6-9f0c782faa520627