-
Notifications
You must be signed in to change notification settings - Fork 76
Child Span doesn't inherit Parent's sampling decision? #294
Comments
The child inherits the parent's trace options here:
The sampler is called later (L83) if the parent wasn't sampled. Does this help? |
Right, but the next line (
One of 2 things needs to happen:
I think the right spot to do this in would be span.cc instead of having every sampler have to remember to handle this case |
IIUC: if the parent is sampled then the child is sampled. |
But if the parent is not sampled, the intended child may become a new root span. Should the sampling not be on by-trace instead of a by-span basis? |
To summarize the discussion above, I think the question is what should be the correct behavior when a user pass in conflicting signals when constructing a child span? (since in the current API, sampling can be passed in by-span basis) i.e. a child span is created with an always sampler, but it already has configs implicitly inherited from a parent span set with a never sampler. Should the child span obey the parent config then and not be sampled? |
I was also confused by this, I assumed the default behavior was to disable traces if the parent had the sample option set to false. However the default Sampler that gets created as part of the failed Generate creates a ProbabilitySampler as part of MakeDefaultTraceParams. The ProbabilitySampler::ShouldSample currently does not use parent_context or has_remote_parent param at all. I was expecting that if the parent_context.trace_options().IsSampled() was set to false the inherited span would not sample either. |
If you want to avoid "inflationary" sampling of child spans, set the sampling probability to zero. Children of sampled parents will still get sampled. |
The documentation says "A sampling decision from a ParentSpan is ALWAYS inherited by all its regardless of the trace configuration. This ensures continuity of traces – for example, if a parent were sampled but one of its children were not, we’d then lose parts of the trace, and vice versa if the parent weren’t sampled yet one of its children were, we wouldn’t know where the span began" https://opencensus.io/tracing/sampling/
However, looking at the code, the sampler doesn't take into consideration of parent span context.
https://github.com/census-instrumentation/opencensus-cpp/blob/master/opencensus/trace/internal/sampler.cc#L57
So I don't think the rule is enforced.
The text was updated successfully, but these errors were encountered: