-
Notifications
You must be signed in to change notification settings - Fork 435
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
ddtrace/tracer: Always count dropped p0 traces and spans #1461
Conversation
ddtrace/tracer/tracer.go
Outdated
@@ -335,6 +335,8 @@ func (t *tracer) sampleFinishedTrace(info *finishedTrace) { | |||
return | |||
} | |||
if !t.rulesSampling.HasSpanRules() { |
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 played around with this a bit just to understand the logic better. What do you think about something like this? Do you find it more readable / less error-prone?
func (t *tracer) sampleFinishedTrace(info *finishedTrace) {
if info.decision == decisionKeep {
return
}
var kept []*span
if t.rulesSampling.HasSpanRules() {
// Apply sampling rules to individual spans in the trace.
for _, span := range info.spans {
if t.rulesSampling.SampleSpan(span) {
kept = append(kept, span)
}
}
if len(kept) > 0 && len(kept) < len(info.spans) {
// Some spans in the trace were kept, so a partial trace will be sent.
atomic.AddUint64(&t.partialTraces, 1)
}
}
if len(kept) == 0 {
atomic.AddUint64(&t.droppedP0Traces, 1)
}
atomic.AddUint64(&t.droppedP0Spans, uint64(len(info.spans)-len(kept)))
info.spans = kept
}
I also think there might be a bug. atomic.AddUint64(&t.partialTraces, 1)
will be called today if len(kept) == 0
, but isn't it possible that every span is kept, s.t. we keep the entire trace, even when applying the single span sampling rules? In that case, we aren't sending a partial trace, but a whole trace.
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.
Hmm that's a good point. I'm not sure if all the spans arriving to the backend but as "single span ingested" affects the way they're displayed or how hit
metrics are calculated such that even though all the spans arrived it's not really a trace since they're marked specially as "single span ingested"?
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 not sure either. If you want to just remove that && len(kept) < len(info.spans)
for now and re-introduce it later after we've looked at it we can. But I assume for this patch it doesn't make a difference since no one is using single span rules today anyway.
@@ -351,6 +351,11 @@ func TestSamplingDecision(t *testing.T) { | |||
|
|||
t.Run("client_dropped", func(t *testing.T) { | |||
tracer, _, _, stop := startTestTracer(t) | |||
defer func() { |
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 should do these same checks for the single spans code too. Since no one is using it, it's fine if we do that in a follow-up PR though.
Fixes an issue where if using client side stats not all dropped p0 traces and spans would be counted.
Note this PR is against the release-v1.41.x branch so it can be released as a hotfix for v1.41