Supports 128-bit trace IDs, generating them on traceId128Bit(true) #258
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| @@ -181,39 +181,19 @@ public void testStartNewSpanSampleNullNotPartOfExistingSpan() { | |||
| } | |||
|
|
|||
| @Test | |||
| public void testStartNewSpanSampleTrueNotPartOfExistingSpan() { | |||
There was a problem hiding this comment.
invalid use case as the method tested was never public or used
codefromthecrypt
force-pushed
the
128-bit
branch
from
7caad3b to
42a242f
Compare
|
cc @openzipkin/core @openzipkin/instrumentation-owners fyi this is the second library to support 128-bit trace ids, after zipkin-go-opentracing |
codefromthecrypt
force-pushed
the
128-bit
branch
from
42a242f to
da825d4
Compare
Traditionally, Zipkin trace IDs were 64-bit. Starting with Zipkin 1.14, 128-bit trace identifiers are supported. This can be useful in sites that have very large traffic volume, persist traces forever, or are re-using externally generated 128-bit IDs. If you want Brave to generate 128-bit trace identifiers when starting new root spans, set `Brave.Builder.traceId128Bit(true)` When 128-bit trace ids are propagated, they will be twice as long as before. For example, the `X-B3-TraceId` header will hold a 32-character value like `163ac35c9f6413ad48485a3953bb6124`. Before doing this, ensure your Zipkin setup is up-to-date, and downstream instrumented services can read the longer 128-bit trace IDs. Note: this only affects the trace ID, not span IDs. For example, span ids within a trace are always 64-bit.
codefromthecrypt
force-pushed
the
128-bit
branch
from
da825d4 to
a62af4f
Compare
|
Cool, I like having a reference implementation 👍 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Traditionally, Zipkin trace IDs were 64-bit. Starting with Zipkin 1.14,
128-bit trace identifiers are supported. This can be useful in sites that
have very large traffic volume, persist traces forever, or are re-using
externally generated 128-bit IDs.
If you want Brave to generate 128-bit trace identifiers when starting new
root spans, set
Brave.Builder.traceId128Bit(true)When 128-bit trace ids are propagated, they will be twice as long as
before. For example, the
X-B3-TraceIdheader will hold a 32-charactervalue like
163ac35c9f6413ad48485a3953bb6124.Before doing this, ensure your Zipkin setup is up-to-date, and downstream
instrumented services can read the longer 128-bit trace IDs.
Note: this only affects the trace ID, not span IDs. For example, span ids
within a trace are always 64-bit.
See openzipkin/zipkin#1298
See openzipkin-contrib/zipkin-go-opentracing#31