Skip to content
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.

Sign up for GitHub

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

adding note about propagation from apache reverse proxy #44

Open
wants to merge 3 commits into
base: master
Choose a base branch
from
Open

adding note about propagation from apache reverse proxy #44

Changes from 2 commits
Commits
Show all changes
3 commits
Select commit Hold shift + click to select a range
8ab4d4e
adding note about propagation from apache reverse proxy
jorgheymans Oct 24, 2020
d0f7e9a
wording
jorgheymans Oct 24, 2020
760aed9
Update README.md
jorgheymans Oct 26, 2020
File filter

Filter by extension

Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
14 changes: 14 additions & 0 deletions README.md
View file
Open in desktop
Original file line number Diff line number Diff line change
Expand Up @@ -347,3 +347,17 @@ recent and largely contained to Envoy, which already supports B3 single format.
Sending a larger second header would increase the pain to others who don't have
this problem anyway. Put another way, the few proxies missing B3 single header
support should update instead of burdening more people from lack thereof.

# Showcase: propagation from an Apache reverse proxy

Zipkin users were <a href="https://github.com/openzipkin/zipkin/issues/1479">wondering</a>
if it is possible to start B3 propagation from an Apache reverse proxy. @adammichalik
jorgheymans marked this conversation as resolved.
Show resolved Hide resolved
came up with a <a href="https://github.com/openzipkin/zipkin/issues/1479#issuecomment-682639979">clever</a>
way to accomplish this, using Apache modules only:

```
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.

Copy link

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.

Copy link

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!

```

>%{reqenv:UNIQUE_ID} is a unique string generated by mod_unique_id. Then, it gets MD5-hashed and assigned to the X-B3-TraceId header. This gives a 32-character hex string = 128 bit traceId. Since my downstream libraries require the traceIds to be 64-bit, the RequestHeader edit extracts the first 16 characters (64 bit) from the value and reassigns it back to the X-B3-TraceId header which is sent downstream.