Skip to content

Conversation

@jorgheymans
Copy link

@jorgheymans jorgheymans commented Oct 24, 2020

Copy link
Member

@codefromthecrypt codefromthecrypt left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Looks good except that it is picking the wrong 16 chars and it is an error to not propagate down a span ID. X-B3-SpanId should be set with the truncated ID. I'm glad this got to point of sharing.. very nice!

A b3 single header variant would be good extra credit.


```
RequestHeader setifempty X-B3-TraceId "expr=%{md5:%{reqenv:UNIQUE_ID}}"
RequestHeader edit X-B3-TraceId "^(.{0,16}).*$" "$1"
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

this is incorrect, it should be the last 16 chars, not the first. Also X-B3-SpanId should be set to the last 16 chars.

Doing this without setting the sampling flag will result in the first hop sampling, which is probably ok as it could be tricky to put sampling logic here :D.

OTOH an example of b3: 0 for /health path would be nice as it shows how to stop things from tracing that.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

@adriancole Can you please explain a bit on why "this is incorrect, it should be the last 16 chars, not the first"? The way I was thinking (but I wasn't thinking too much of it) is that MD5 generates a "uniformly random" hex string of 32 chars, so it doesn't matter if we take the first, middle or last 16 chars - as a matter of fact this trick was simply a way to generate a pseudorandom 16 char hex string.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

sure it is here. https://github.com/openzipkin/b3-propagation/blob/master/STATUS.md and also explained here https://github.com/openzipkin/zipkin/blob/master/zipkin/src/main/java/zipkin2/storage/StorageComponent.java#L106-L144

Seems yeah this should be in the top-level readme :D Offers welcome to fix that!

The main thing is that even if at your site, you feel truncating to 64bit is a constant, we shouldn't hint here picking the left hand side as that will conflict with other practice. I think many would use this with 128-bit IDs as almost all libraries at least truncate back on unsupported for the last several years. It isn't necessary to do that here, but it is interesting to show the option. When showing the option, we should be specific on how.

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Fair points, thanks for the explanation.

Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

no prob!

@codefromthecrypt
Copy link
Member

cc @adammichalik

@jcchavezs
Copy link
Contributor

jcchavezs commented Oct 25, 2020 via email

Co-authored-by: Adrian Cole <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Possibility to start tracing from apache http reverse proxy.

5 participants