-
Notifications
You must be signed in to change notification settings - Fork 62
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
Track support of 128 bit X-B3-TraceId #6
Comments
The first step of transitioning to 128bit `X-B3-TraceId` is tolerantly reading 32 character long ids by throwing away the high bits (any characters left of 16 characters). This allows the tracing system to more flexibly introduce 128bit trace id support in the future. Ex. when `X-B3-TraceId: 463ac35c9f6413ad48485a3953bb6124` is received, parse the lower 64 bits (right most 16 characters ex48485a3953bb6124) as the trace id. See openzipkin/b3-propagation#6
The first step of transitioning to 128bit `X-B3-TraceId` is tolerantly reading 32 character long ids by throwing away the high bits (any characters left of 16 characters). This allows the tracing system to more flexibly introduce 128bit trace id support in the future. Ex. when `X-B3-TraceId: 463ac35c9f6413ad48485a3953bb6124` is received, parse the lower 64 bits (right most 16 characters ex48485a3953bb6124) as the trace id. See openzipkin/b3-propagation#6
The first step of transitioning to 128bit `X-B3-TraceId` is tolerantly reading 32 character long ids by throwing away the high bits (any characters left of 16 characters). This allows the tracing system to more flexibly introduce 128bit trace id support in the future. Ex. when `X-B3-TraceId: 463ac35c9f6413ad48485a3953bb6124` is received, parse the lower 64 bits (right most 16 characters ex48485a3953bb6124) as the trace id. See openzipkin/b3-propagation#6
The first step of transitioning to 128bit `X-B3-TraceId` is tolerantly reading 32 character long ids by throwing away the high bits (any characters left of 16 characters). This allows the tracing system to more flexibly introduce 128bit trace id support in the future. Ex. when `X-B3-TraceId: 463ac35c9f6413ad48485a3953bb6124` is received, parse the lower 64 bits (right most 16 characters ex48485a3953bb6124) as the trace id. See openzipkin/b3-propagation#6
The first step of transitioning to 128bit `X-B3-TraceId` is tolerantly reading 32 character long ids by throwing away the high bits (any characters left of 16 characters). This allows the tracing system to more flexibly introduce 128bit trace id support in the future. Ex. when `X-B3-TraceId: 463ac35c9f6413ad48485a3953bb6124` is received, parse the lower 64 bits (right most 16 characters ex48485a3953bb6124) as the trace id. See openzipkin/b3-propagation#6
The first step of transitioning to 128bit `X-B3-TraceId` is tolerantly reading 32 character long ids by throwing away the high bits (any characters left of 16 characters). This allows the tracing system to more flexibly introduce 128bit trace id support in the future. Ex. when `X-B3-TraceId: 463ac35c9f6413ad48485a3953bb6124` is received, parse the lower 64 bits (right most 16 characters ex48485a3953bb6124) as the trace id. See openzipkin/b3-propagation#6
ps I'm clicking "check" when a pull request is raised, and noting the version, once released. |
@adriancole I've updated zipkin-go-opentracing to tolerate 128bit traceID's and have sent a PR to monkit-zipkin. The other listed Go tracer go-zipkin does not have B3 propagation and uses a custom Avro encoding over Kafka so we don't have to deal with them on this issue. |
thanks for the help @basvanbeek |
Ok, this phase is nearly complete. Almost all libraries have merged code, except akka and .net (cc @levkhomich @jcarres-mdsol) I think this is close enough to start doing other work, such as supporting server-side effort |
side-note cloud foundry gorouter doesn't seem to interpret the X-B3-TraceId header, so doesn't seem to need any work here https://github.com/cloudfoundry/gorouter/blob/4d9497354baaf103310cc7c78a3fb5ccf69e6016/common/http/headers_test.go |
* Support for MySQL 5.7 with SQL_MODE=ONLY_FULL_GROUP_BY * Includes support to store 128-bit trace ID (not yet implemented here) See openzipkin/b3-propagation#6
* Support for MySQL 5.7 with SQL_MODE=ONLY_FULL_GROUP_BY * Includes support to store 128-bit trace ID (not yet implemented here) See openzipkin/b3-propagation#6
* Support for MySQL 5.7 with SQL_MODE=ONLY_FULL_GROUP_BY * Includes support to store 128-bit trace ID (not yet implemented here) See openzipkin/b3-propagation#6
* Support for MySQL 5.7 with SQL_MODE=ONLY_FULL_GROUP_BY * Includes support to store 128-bit trace ID (not yet implemented here) See openzipkin/b3-propagation#6
This supports 128-bit traces via a new field traceIdHigh, which matches other zipkin implementations. In encoded form, the trace ID is simply twice as long (32 hex characters). With this change in, a 128-bit trace propagated will not be downgraded to 64-bits when sending downstream, reporting to Zipkin or adding to the logging context. This will be followed by a change to support initiating 128-bit traces. See openzipkin/b3-propagation#6
added this to support 128-bit traces in zipkin-js openzipkin/zipkin-js#57 |
This adds `XRayUDPReporter` which defaults to localhost:2000 or AWS_XRAY_DAEMON_ADDRESS. This can be used in applications directly or integrated with a zipkin-server where `STORAGE_TYPE=xray` Note: this is experimental and makes assumptions about trace ID format: See openzipkin/b3-propagation#6
This adds `XRayUDPReporter` which defaults to localhost:2000 or AWS_XRAY_DAEMON_ADDRESS. This can be used in applications directly or integrated with a zipkin-server where `STORAGE_TYPE=xray` Note: this is experimental and makes assumptions about trace ID format: See openzipkin/b3-propagation#6
This adds `XRayUDPReporter` which defaults to localhost:2000 or AWS_XRAY_DAEMON_ADDRESS. This can be used in applications directly or integrated with a zipkin-server where `STORAGE_TYPE=xray` Note: this is experimental and makes assumptions about trace ID format: See openzipkin/b3-propagation#6
Tracking moved here https://cwiki.apache.org/confluence/display/ZIPKIN/128-bit+Trace+ID |
The first step of transitioning to 128bit `X-B3-TraceId` is tolerantly reading 32 character long ids by throwing away the high bits (any characters left of 16 characters). This allows the tracing system to more flexibly introduce 128bit trace id support in the future. Ex. when `X-B3-TraceId: 463ac35c9f6413ad48485a3953bb6124` is received, parse the lower 64 bits (right most 16 characters ex48485a3953bb6124) as the trace id. See openzipkin/b3-propagation#6
A 128-bit trace ID is when
X-B3-TraceId
has 32 hex characters as opposed to 16. For example,X-B3-TraceId: 463ac35c9f6413ad48485a3953bb6124
.Here are the status options for 128bit
X-B3-TraceId
:X-B3-TraceId
through the system without interpreting it.This is a list of zipkin libraries and their status in supporting 128-bit trace IDs
new Tracer({..., traceId128Bit: true})
spring.sleuth.traceId128=true
Create128BitTraceId(true)
epoch128
When a trace ID is 128-bits and the first 32 bits are epoch seconds, the ID can be translated into
an Amazon Web Services ID. Tracers who do this can tunnel through ELBs, for example.
Here's an example implementation
See openzipkin/zipkin#1754
The text was updated successfully, but these errors were encountered: