-
Notifications
You must be signed in to change notification settings - Fork 231
Add W3C TraceContext codec/propagation #694
Add W3C TraceContext codec/propagation #694
Conversation
Codecov Report
@@ Coverage Diff @@
## master #694 +/- ##
============================================
- Coverage 90.08% 89.98% -0.11%
- Complexity 571 590 +19
============================================
Files 69 70 +1
Lines 2088 2157 +69
Branches 266 281 +15
============================================
+ Hits 1881 1941 +60
- Misses 126 130 +4
- Partials 81 86 +5
Continue to review full report at Codecov.
|
The question also is whether we want to support baggage - |
|
||
package io.jaegertracing.internal.propagation; | ||
|
||
import static io.jaegertracing.internal.propagation.B3TextMapCodec.SAMPLED_FLAG; |
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.
you sure you want this here?
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.
This certainly no ;)
assertNotNull(traceContextHeader); | ||
assertTrue(traceContextHeader.contains("0000000000000001")); | ||
//For 64 bit traces, we need to pad the left side with a random number to conform with the specification. | ||
//It should not contain all zeros. |
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.
This comment doesn't seem to match the assertion below?
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.
Based on the code commet seems wrong. I haven't found this in the spec. @yurishkuro do you know something about this?
/** | ||
* The W3C TraceContext propagation format. | ||
*/ | ||
TRACE_CONTEXT |
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.
As mentioned in the doc PR, just wondering whether this should be W3C
rather than trace_context which is very generic. But not sure if there is a convention being used across jaeger (or wider).
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.
I don't have any preference. I don't think there will be any other variant of trace context that will collide with this name.
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.
In which case, I would prefer W3C
as it clearly identifies the standards body - in the same way as B3
above identifies the defacto-standard.
@yurishkuro Any preference?
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.
W3C sgtm, or W3C_TRACE_CONTEXT (but if we also support it in the Config class as a string, then I would just go with "w3x"
string)
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.
In which case, I would prefer W3C as it clearly identifies the standards body - in the same way as B3 above identifies the defacto-standard.
I don't have much preference but. B3
identifies the protocol, the same as trace_context
. Whereas W3C
is the standard body like or organization which for B3
is Zipkin
. So if we follow the same naming conventions the B3
should be rather named zipkin
.
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.
Agree the analogy was wrong. However the problem I have with trace_context
is that it is a generic term so could cause confusion.
|
||
boolean sampled = false; | ||
long traceContextFlags = HexCodec.hexToUnsignedLong(traceparent, TRACE_OPTION_OFFSET, TRACE_OPTION_OFFSET + 2); | ||
if ((traceContextFlags & SAMPLED_FLAG) == SAMPLED_FLAG) { |
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.
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.
- is there any way we can use OTel implementation instead of creating our own?
- only doing traceparent is not compliant with W3C spec, is it?
/** | ||
* The W3C TraceContext propagation format. | ||
*/ | ||
TRACE_CONTEXT |
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.
W3C sgtm, or W3C_TRACE_CONTEXT (but if we also support it in the Config class as a string, then I would just go with "w3x"
string)
@@ -0,0 +1,142 @@ | |||
/* | |||
* Copyright 2019, OpenTelemetry Authors |
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.
2020
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.
we should consider removing dates altogether
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.
This is what the license plugin gave me
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.
I will have a look at this in a separate PR.
Signed-off-by: Jonah Back <jonah@jonahback.com>
Signed-off-by: Jonah Back <jonah@jonahback.com>
Signed-off-by: Jonah Back <jonah@jonahback.com>
Signed-off-by: Jonah Back <jonah@jonahback.com>
Signed-off-by: Jonah Back <jonah@jonahback.com>
…had 64 bits of data Signed-off-by: Jonah Back <jonah@jonahback.com>
Signed-off-by: Pavol Loffay <ploffay@redhat.com>
Signed-off-by: Pavol Loffay <ploffay@redhat.com>
Signed-off-by: Pavol Loffay <ploffay@redhat.com>
Signed-off-by: Pavol Loffay <ploffay@redhat.com>
b6a145f
to
748b9bd
Compare
Signed-off-by: Pavol Loffay <ploffay@redhat.com>
It does not seem right to put on the classpath OTEL API only just for this class.
Based on the OTEL impl it seems to be compliant. The header is not added if there is no baggage and not parsed if it is missing. |
@yurishkuro I have added support for There are two limitations associated with it: https://github.com/w3c/trace-context/blob/master/spec/20-http_header_format.md
The OTEL and this impl does not extract baggage if there are more than 32 items.
The OTEL and this impl allows inject/extract of |
@pavolloffay I don't believe tracestate is meant for baggage. Since Jaeger only needs traceparent, my understanding was that tracestate simply needs to be propagated intact (we don't even need to parse it). |
Signed-off-by: Pavol Loffay <ploffay@redhat.com>
My bad I mixed it with correlation context. I have removed the baggage and just add propagation of the |
return new JaegerSpanContext(traceIdHigh, traceIdLow, spanId, parentId, flags, traceState, baggage, debugId, this); | ||
} | ||
|
||
public JaegerSpanContext createSpanContext( |
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.
Please keep the factory interface minimal.
Can we instead have a setTracestate() method on the context and not change the factory? I realize that we can't make the field final in that case, but it's better for backwards compatibility than breaking this interface.
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.
JaegerObjectFactory
is not an interface hence this is not a breaking change.
jaeger-core/src/main/java/io/jaegertracing/internal/propagation/TraceContextCodec.java
Outdated
Show resolved
Hide resolved
@@ -0,0 +1,136 @@ | |||
/* | |||
* Copyright (c) 2016, Uber Technologies, Inc |
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.
2020
Signed-off-by: Pavol Loffay <ploffay@redhat.com>
Signed-off-by: Pavol Loffay <ploffay@redhat.com>
@yurishkuro PR updated |
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 for restoring SpanContextFactory. It should've been an interface, and can't really work with overloaded methods because they would silently bypass the subclasses.
@pavolloffay Can this be used together with the Uber format, i.e. extract the context from either format and inject both? |
I am not sure, there is a composite You can try to play with tracer builder/configuration and see whether it is possible. Please open an issue with your findings. |
HexCodec.writeHexLong(chars, SPAN_ID_OFFSET, spanContext.getSpanId()); | ||
chars[TRACE_OPTION_OFFSET - 1] = TRACEPARENT_DELIMITER; | ||
chars[TRACE_OPTION_OFFSET] = '0'; | ||
chars[TRACE_OPTION_OFFSET + 1] = spanContext.isSampled() ? '1' : '0'; |
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.
we should be carrying all Jaeger flags, not just sampled bit: #702
Supersedes #649
Related to jaegertracing/jaeger#855
I have made slight changes to #649 (the spanId was incorrect set, improved inject perfomance) and aligned the implementation with https://github.com/open-telemetry/opentelemetry-java/blob/master/api/src/main/java/io/opentelemetry/trace/propagation/HttpTraceContext.java#L40