-
Notifications
You must be signed in to change notification settings - Fork 62
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
Clarify whether X-B3-Flags should be propagated #24
Comments
0 payload for Flags does not exist, it is also not a bit flag. If |
I still feel a bit confused. Are you talking about the requester initiating a debug trace should not send e.g. debug not set |
the debug flag once set always set. this indeed can be clarified. in fact
all sampling states are simplest to think of as set and always propagate.
reason on debug to set also on the span data is that it is for collector
tier sampling there is no way to guarantee same node gets all spans in a
trace (not without a custom pipeline that shards on trace id).
|
For context, I'm building B3 header propagation into my services, but I'm not doing any actual sampling, trace context generation, or in-process tracing, I'm leveraging Envoy for that at this point |
got it. Sounds like my propagation should just look at all 5 headers, and copy them forward. In practice only 4 will be set at a time because |
it is easier to reason with in the b3 single format.
flags/debug is a 4th sampling state.. greater than sampled
so if flags=1 and the sampling header is missing, you can assume same
behavior as if sampling header was set to 1.
there is no case for propagating flags=0. we ignore it when it is. flags=1
and sampling=0 is invalid.
|
got it, thanks for the quick responses! |
Could some of this rationale be added to b3 documentation?
Den fre. 31. aug. 2018, 16:01 skrev Michael Puncel <notifications@github.com
:
got it, thanks for the quick responses!
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#24 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AC7sArLSe5m4j-UoN0NMCs-gEaH849FVks5uWUG-gaJpZM4WVO4K>
.
--
*José Carlos*
|
close it isnt mutually exclusive rather that it is slightly redundant to
say sampled=1 flags=1
this is why in b3 single we go for one character to describe sampling as
historically the headers have been confusing. ex the characters are now '0'
'1' and 'd' (for debug)
being unable to rewrite history (still!) we have to forever honor the
admitadly awkward in hindsight prior formatting of the same in the x-b3-
namespace
|
so nice to volunteer :D
…On Fri, 31 Aug 2018, 22:02 José Carlos Chávez, ***@***.***> wrote:
Could some of this rationale be added to b3 documentation?
Den fre. 31. aug. 2018, 16:01 skrev Michael Puncel <
***@***.***
>:
> got it, thanks for the quick responses!
>
> —
> You are receiving this because you are subscribed to this thread.
> Reply to this email directly, view it on GitHub
> <
#24 (comment)
>,
> or mute the thread
> <
https://github.com/notifications/unsubscribe-auth/AC7sArLSe5m4j-UoN0NMCs-gEaH849FVks5uWUG-gaJpZM4WVO4K
>
> .
>
--
*José Carlos*
—
You are receiving this because you commented.
Reply to this email directly, view it on GitHub
<#24 (comment)>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AAD618DGROmVAmiiiNgb2Vt_oLG_O-a2ks5uWUIOgaJpZM4WVO4K>
.
|
ps #26 should have sorted this |
I feel that the README doesn't quite spell out whether X-B3-Flags should be propagated in HTTP headers. Reading between the lines, it seems like the library that receives
X-B3-Flags: 1
should swallow that header and propagateX-B3-Sampled: 1
to the next process. Is that understanding correct?The text was updated successfully, but these errors were encountered: