-
Notifications
You must be signed in to change notification settings - Fork 64
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
Details attributes and http header encoding #8
Conversation
Since I'm working on a change in Brave, I figured I'd go ahead and elaborate the common attributes here. Further clarifications can either be made in this PR, or be saved for later ones.
* Debug trace: When setting Flags to 1, sampling is implicit | ||
* Externally provisioned IDs: When you want to control IDs, but not sampling policy | ||
|
||
Unless it is a debug trace, leaving sampled unset is typically for ID correlation. For example, someone re-uses a global identifier from another system, or correlating in logs. In these cases, the caller knows the ID they want, but allows the next hop to decide if it will be traced or not. The caller should not report a span to the tracing system using this ID unless they propagate Sampled=1. |
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.
cc @jcarres-mdsol @dangets This particularly relates to functionality in Finagle, which is missing in Brave openzipkin/brave#277
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.
This is easy to understand and should be a good guide for those using B3. 👍 I only left a few nit pick polish comments.
|
||
## Sampled | ||
|
||
When the Sampled is 1, report this span to the tracing system. When it is 0, do do not. When B3 attributes are sent without the Sampled attribute, the receiver should make the decision. Once Sampled is set to 0 or 1, the value should be consistently sent downstream. |
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.
"When it is 0, do do not." → "When it is 0, do not."
|
||
## Sampled | ||
|
||
When the Sampled is 1, report this span to the tracing system. When it is 0, do do not. When B3 attributes are sent without the Sampled attribute, the receiver should make the decision. Once Sampled is set to 0 or 1, the value should be consistently sent downstream. |
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.
"When the Sampled is 1" sounds strange to me. Maybe "When Sampled is 1" or "When the Sampled attribute is 1"
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.
Thanks.. I think I meant When the Sampled flag is 1
There are some who want to control trace identifiers, but leave the sampling decision to the next hop. In this case, they propagate the required headers (X-B3-TraceId, X-B3-ParentId) and not X-B3-Sampled. When this happens, the receiver of the headers (the server), should sample the trace ID before using it. Before, we weren't implementing this (eventhough Finagle does). The change here addresses it and also backfills tests accordingly. See https://github.com/twitter/finagle/blob/develop/finagle-http/src/main/scala/com/twitter/finagle/http/Codec.scala#L341 See https://github.com/twitter/finagle/blob/develop/finagle-core/src/main/scala/com/twitter/finagle/tracing/Tracer.scala#L119 See openzipkin/b3-propagation#8 Fixes #277
I'm going to merge this in the spirit of getting something far better than the template README out there. Will take any more comments after commit, so please voice if you have them! |
Since I'm working on a change in Brave, I figured I'd go ahead and elaborate the common attributes here. Further clarifications can either be made in this PR, or be saved for later ones.