-
Notifications
You must be signed in to change notification settings - Fork 714
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
WIP TraceContext propagation handler #693
Conversation
I will move this to openzipkin-contrib repo at some point. It is too early to put this into brave and I also have less confidence the spec until there are others implementing it. |
https://github.com/w3c/distributed-tracing is a decent place to consider |
4180431
to
706e068
Compare
e7647d7
to
0566e90
Compare
fyi this is on pause still as there's a discussion that significantly affects portability pending. We don't have the resources to thrash the impl so waiting on a decision to finalize with ideally a quorum of diverse input. |
@SergeyKanzhelev do you mind a quick mention of the status of the w3c tracecontext. I see it is working draft on the github repo, but then also see some pull requests for review. How stable are things? are there any public endpoints available to interop with? |
0580d73
to
8616978
Compare
rebased |
some things that changed since this was done:
|
here's the published version, several days ago. we should watch out to see which errata are accepted (eg if version 00 is errata or intentional) https://www.w3.org/TR/trace-context-1/ iotw recommend if someone wants to pick this up, to wait a few days for errata |
looks like people settled on version double-zero. |
8616978
to
94aca21
Compare
I rebased this and renamed the thing to "w3c" as I can't imagine us wanting to add another module for correlation-context later. Also, I wrote in the README the implementation rationale, which is made to survive multiple systems. later, I'll scan for spec drift and rally for merge. |
backfilled traceparent tests as that format didn't change much. next is to manage the drift on tracestate which is a lot more permissive than last time. |
b7ea224
to
d77b9ae
Compare
I will redo the traceparent stuff following this as it is faster and has better logging #1114 |
09b995c
to
c45f5f3
Compare
rewrote the traceparent parser based on recent work committed for b3 single (thanks to @anuraaga for the epic review on that). This fully supports the traceparent spec now, including edge cases like forward versions. next step is to redo the tracestate parser. |
propagation/w3c/src/main/java/brave/propagation/w3c/TraceparentFormat.java
Outdated
Show resolved
Hide resolved
started on tracestate key generation. it took a bit to understand the validation rules. hats off to @anuraaga for the tip to parse with a boolean array as it is faster than the usual approach netty/netty#9896 |
tracestate key parsing numbers from latest commit:
|
ok tracestatekey algo done.. need to go back and cite the sections of the spec and add logging for the various failure cases.
|
started reworking this over latest master. next step: take out the unnecessary |
@Test public void extracted_toString() { | ||
request.put("traceparent", validTraceparent); | ||
request.put("tracestate", "b3=" + validB3Single + "," + otherState); | ||
|
||
assertThat(extractor.extract(request)).hasToString( | ||
"Extracted{" | ||
+ "traceContext=" + sampledContext + ", " | ||
+ "samplingFlags=SAMPLED_REMOTE, " | ||
+ "extra=[tracestate: " + otherState + "]" | ||
+ "}"); | ||
} |
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 to @anuraaga for all the advice, this is much more intuitive now, and especially useful for partially deconstructed formats like this.
This adds `EntrySplitter` to help handle complex formats such as W3C trace-context efficiently. For example, this has flexible whitespace rules to comply with standards like 'tracestate' which require retaining leading whitespace. See #693
Annoyingly, trace-context defines some strange whitespace rules. Ex
I don't expect them to fix this so I wrote a parser that can deal with it. once this is in I can finish up #1193 |
This adds `EntrySplitter` to help handle complex formats such as W3C trace-context efficiently. For example, this has flexible whitespace rules to comply with standards like 'tracestate' which require retaining leading whitespace. See #693
dd20f10
to
733a586
Compare
@anuraaga @samukce I think Brave now has what's needed to do this with the least cruft. As such, once 5.12 is out I'll cut a new openzipkin-contrib repository named brave-w3c with this as "initial commit" referencing this issue in order to retain history. After that, I'll close this PR. In that repo, we can carry forward the rest of it decoupled from Brave releases, allow people to experiment while details in w3c are still fluid. |
733a586
to
beb3451
Compare
https://github.com/openzipkin-contrib/brave-propagation-w3c will carry this on |
I paired with @tylerbenson so thanks for the help.
Very early so don't read too much into how the code is shaped until comments suggest otherwise
See also openzipkin/zipkin4net#200 cc @bgrainger