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

WIP TraceContext propagation handler #693

Closed
wants to merge 13 commits into from
Closed

Conversation

codefromthecrypt
Copy link
Member

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

@codefromthecrypt
Copy link
Member Author

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.

@codefromthecrypt
Copy link
Member Author

https://github.com/w3c/distributed-tracing is a decent place to consider

@codefromthecrypt codefromthecrypt force-pushed the trace-context branch 3 times, most recently from e7647d7 to 0566e90 Compare August 14, 2018 02:49
@codefromthecrypt
Copy link
Member Author

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.

w3c/trace-context#167

@codefromthecrypt
Copy link
Member Author

@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?

@codefromthecrypt
Copy link
Member Author

rebased

@codefromthecrypt
Copy link
Member Author

codefromthecrypt commented Feb 10, 2020

some things that changed since this was done:

  • tracestate encoding is more complex as characters such as @ are now allowed. I've noticed some using a more expensive regex approach to split on account of this.
  • oddly 00 is the final version in the delimited header
  • there are a lot of MUST in the spec for things that were opposite before. For example, you have to handle mixed case, which will be silly in messaging for the reasons we already know about.
  • odd things like traceparent field for span id renamed to parent id, which conflicts conceptually with B3 with no mention about B3 of course. super strange behavior as using simply "id" could have been done if the word span was problematic. anyway like all the above regressions, this is water under the bridge.

@codefromthecrypt
Copy link
Member Author

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

@codefromthecrypt
Copy link
Member Author

codefromthecrypt commented Mar 11, 2020

looks like people settled on version double-zero.

@codefromthecrypt
Copy link
Member Author

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.

@codefromthecrypt
Copy link
Member Author

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.

@codefromthecrypt
Copy link
Member Author

I will redo the traceparent stuff following this as it is faster and has better logging #1114

@codefromthecrypt
Copy link
Member Author

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.

@codefromthecrypt
Copy link
Member Author

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

@codefromthecrypt
Copy link
Member Author

tracestate key parsing numbers from latest commit:

Benchmark                                                     Mode  Cnt  Score   Error   Units
TracestateFormatBenchmarks.validateKey_brave_longest_basic   thrpt   15  5.168 ± 0.061  ops/us
TracestateFormatBenchmarks.validateKey_brave_longest_tenant  thrpt   15  4.056 ± 0.018  ops/us
TracestateFormatBenchmarks.validateKey_regex_longest_basic   thrpt   15  0.401 ± 0.013  ops/us
TracestateFormatBenchmarks.validateKey_regex_longest_tenant  thrpt   15  0.414 ± 0.011  ops/us

@codefromthecrypt
Copy link
Member Author

ok tracestatekey algo done.. need to go back and cite the sections of the spec and add logging for the various failure cases.

Benchmark                                                     Mode  Cnt  Score   Error   Units
TracestateFormatBenchmarks.validateKey_brave_longest_basic   thrpt   15  5.265 ± 0.035  ops/us
TracestateFormatBenchmarks.validateKey_brave_longest_tenant  thrpt   15  5.127 ± 0.021  ops/us
TracestateFormatBenchmarks.validateKey_regex_longest_basic   thrpt   15  0.375 ± 0.033  ops/us
TracestateFormatBenchmarks.validateKey_regex_longest_tenant  thrpt   15  0.425 ± 0.009  ops/us

@codefromthecrypt
Copy link
Member Author

started reworking this over latest master. next step: take out the unnecessary @ logic

Comment on lines 81 to 90
@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 + "]"
+ "}");
}
Copy link
Member Author

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.

codefromthecrypt pushed a commit that referenced this pull request May 7, 2020
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
@codefromthecrypt
Copy link
Member Author

codefromthecrypt commented May 7, 2020

Annoyingly, trace-context defines some strange whitespace rules. Ex

"tracestate: key=          value"

"          value" is actually the value per the spec. 

w3c/trace-context#409

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

codefromthecrypt pushed a commit that referenced this pull request May 8, 2020
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
@codefromthecrypt
Copy link
Member Author

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

@codefromthecrypt
Copy link
Member Author

@anuraaga @samukce as people are often confused by HTTP encoding rules, I summarized the relationship with our APIs here #1205

@codefromthecrypt
Copy link
Member Author

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.

2 participants