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.

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

Fix for #2114 Support b3 trace header #2329

Closed
wants to merge 2 commits into from

Conversation

dtacalau
Copy link
Contributor

@dtacalau dtacalau commented Sep 24, 2019

With this fix Linkerd will propagate b3 single header the same way it propagates x-b3- multi headers. If a request contains "b3" single header and "X-B3-" multi headers, the trace context from "b3" is preferred and "x-b3-" will be ignored. "b3" is handled the same way as finagle: extract the traceid from "b3" header, write back "X-B3-*" multi headers, and let the flow continue as if it has received "x-b3-".

No config changes were needed, "b3" is not written on the way out, not sure if it's a good idea since finagle does not write "b3".

Also added support for 128bit traceId has been implemented with this fix because "b3" supports 128bit traceIds.

This has been tested in two ways:

  • unit tests for "b3" single header parsing and handling, also this unit tests are good for testing the handling of "x-b3-" multi headers
  • manual testing by sending a request with various "x-b3-" headers to a l5d router which has tracePropagator configured, and checked the behaviour hasn't changed after implementing "b3" support.

Signed-off-by: dst4096 [email protected]

@codefromthecrypt
Copy link

one thing to spot check in the implementation is if "b3" is consumed or not. I know some proxies pass headers, which could result in a stale "b3" value sent out on the other side. Probably not an issue here, but worth asking

Copy link
Member

@zaharidichev zaharidichev left a comment

Choose a reason for hiding this comment

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

Nice work @dtacalau! Left a few comments, mainly around code style, etc. What I am wondering however is whether this same logic + tests should be implemented for the h2 version of the code.

…ill propagate b3 single header the same way as x-b3- multi headers. If a request contains "b3" single header and "X-B3-" multi headers, the trace context from "b3" is preferred and "x-b3-" will be ignored. Added support for 128bit traceId.

Signed-off-by: dst4096 <[email protected]>
@dtacalau
Copy link
Contributor Author

Nice work @dtacalau! Left a few comments, mainly around code style, etc. What I am wondering however is whether this same logic + tests should be implemented for the h2 version of the code.

Done, added support for b3 in h2 implementation, also I've updated unit test for h2.

@codefromthecrypt
Copy link

PS as timing is interesting sometimes, a user of a gateway project just found what appears to be a propagation bug relating to my earlier comment. Basically verify that this product won't end up passing through either header choice unaffected, and it will save users from lengthy troubleshooting later spring-cloud/spring-cloud-sleuth#1452

Copy link
Member

@zaharidichev zaharidichev left a comment

Choose a reason for hiding this comment

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

@dtacalau Left some suggestions

req.headerMap.add("x-b3-sampled", "0")

val trace = ztp.traceId(req)
trace match {
Copy link
Member

Choose a reason for hiding this comment

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

Again, making use of the combinators would probably make sense here.

convertB3SingleHeaderToMultiHeaders(headers)

// expect to read a 128bit traceid field, b3 single header supports 128bit traceids
val trace128Bit = caseInsensitiveGet(headers, ZipkinTraceHeader) match {
Copy link
Member

Choose a reason for hiding this comment

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

The diff is complicated by the fact that we're adding support for the b3 header AND adding support for 128 bit trace ids at the same time. Can these be split into two separate PRs?

…. Moved implementation of http and h2 ZipkinTracePropagator to a new common place base-http. Fixed setting of sampled/flags, computation of sampled. Updated tests. Support for 128bit trace.

Signed-off-by: dst4096 <[email protected]>
@dtacalau
Copy link
Contributor Author

dtacalau commented Oct 7, 2019

The code from this PR has been rewritten and I've created another PR

@dtacalau dtacalau closed this Oct 7, 2019
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.

4 participants