-
Notifications
You must be signed in to change notification settings - Fork 893
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
[trace-sdk-sampler] Differentiate between root and child span creation in trace sampling spec #3888
[trace-sdk-sampler] Differentiate between root and child span creation in trace sampling spec #3888
Conversation
specification/trace/sdk.md
Outdated
3. Generate a new span ID for the `Span`, independently of the sampling decision. | ||
This is done so other components (such as logs or exception handling) can rely on | ||
a unique span ID, even if the `Span` is a non-recording instance. | ||
3. If there isn't currently a span (the span being created will become the root |
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.
@Oberon00 to share early comments. (the PR is still draft)
Co-authored-by: Cijo Thomas <[email protected]>
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
@cijothomas Are you able to reopen this? Doesn't seem like I can do it. |
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
While the change seems sensible (without thinking very deep about it), it is also a breaking change to a stable specification part. |
I think the proposed wording in this PR is written is such a way so as to be back-compatible, very similar to the OTLP Exporter defaulting to http wording from diff. section of spec.
|
@jack-berg Had the same feedback for me when I first shared this idea with him. We are in no way recommending SDKs change their behavior. What we want to do is retroactively bless the direction .NET has already taken. I just pushed an update which makes this explicit. Feels very unnecessary to me, but if it helps makes this clear doesn't seem like a problem to have it. |
It's OK, you don't need to add this wording just for me, as long as we have something like that also in the general versioning/stability spec it should be fine (and I think we have, now that you brought it up) |
This PR was marked stale due to lack of activity. It will be closed in 7 days. |
Closed as inactive. Feel free to reopen if this PR is still being worked on. |
Changes
Reasoning
The .NET SDK works like this today: If the sampler returns
DROP
we always create a span for the root. For children, we don't create a span. This takes .NET out of compliance with the spec (as-is) but we have been resistant to change this behavior because it is expensive to create these spans (memory, cpu, gc pressure, etc.) for benefits which seem unclear. If the purpose is just to give a valid non-empty SpanId to logs (and friends) then the root creation behavior seems to accomplish the goal more cheaply.Also, .NET also already has a mechanism which is more or less #3867 where users can drop a source/instrumentation scope. Really everything is no-op by default users have to explicitly enable the sources/instrumentation scopes they care about. Even if .NET was spec-compliant w.r.t. the span creation traces could still have gaps for things users haven't switched on. This isn't something .NET SDK can change either, as it comes from the underlying .NET platform.
What this PR is seeking to do is officially bless what .NET has done in order to bring it into spec-compliance so we may resolve things like open-telemetry/opentelemetry-dotnet#3290.
TODOs
CHANGELOG.md
file updated for non-trivial changes