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

Track support of 128 bit X-B3-TraceId #6

Closed
codefromthecrypt opened this issue Sep 14, 2016 · 7 comments
Closed

Track support of 128 bit X-B3-TraceId #6

codefromthecrypt opened this issue Sep 14, 2016 · 7 comments

Comments

@codefromthecrypt
Copy link
Member

codefromthecrypt commented Sep 14, 2016

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:

  • unsupported: 32 character trace ids will break the library
  • downgrade: Read 32 character trace ids by throwing away the high bits (any characters left of 16 characters). This effectively downgrades the ID to 64 bits.
  • transparent: Pass X-B3-TraceId through the system without interpreting it.
  • supported: Can start traces with 128-bit trace IDs, propagates and reports them as 128-bits
  • epoch128: Can start traces with 128-bit trace IDs which are prefixed with epoch seconds

This is a list of zipkin libraries and their status in supporting 128-bit trace IDs

library version status notes
zipkin-js 0.5+ supported new Tracer({..., traceId128Bit: true})
pyramid_zipkin 0.16+ downgrade
brave 3.15+/4.9+ supported/epoch128 https://github.com/openzipkin/brave/tree/master/brave-core#128-bit-trace-ids
spring-cloud-sleuth 1.0.11+/1.2.6+ supported/epoch128 set spring.sleuth.traceId128=true
finagle 0.40+ downgrade
zipkin-ruby unsupported depends on twitter/finagle#565
ZipkinTracerModule 3.2+ supported Create128BitTraceId(true)
zipkin-go-opentracing 0.2+ supported https://godoc.org/github.com/openzipkin/zipkin-go-opentracing#TraceID128Bit
akka-tracing 0.5.2+ downgrade
wingtips 0.11.2+ transparent
jaeger 0.10+ downgrade
zipkin4net 0.4+ supported

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

  static long nextTraceIdHigh(Random prng) {
    long epochSeconds = System.currentTimeMillis() / 1000;
    int random = prng.nextInt();
    return (epochSeconds & 0xffffffffL) << 32
        |  (random & 0xffffffffL);
  }

See openzipkin/zipkin#1754

codefromthecrypt pushed a commit to spring-cloud/spring-cloud-sleuth that referenced this issue Sep 15, 2016
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
codefromthecrypt pushed a commit to spring-cloud/spring-cloud-sleuth that referenced this issue Sep 15, 2016
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
codefromthecrypt pushed a commit to openzipkin/brave that referenced this issue Sep 15, 2016
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
yurishkuro pushed a commit to jaegertracing/jaeger-client-java that referenced this issue Sep 15, 2016
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
codefromthecrypt pushed a commit to openzipkin/brave that referenced this issue Sep 16, 2016
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
codefromthecrypt pushed a commit to openzipkin/zipkin-js that referenced this issue Sep 19, 2016
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
@codefromthecrypt
Copy link
Member Author

ps I'm clicking "check" when a pull request is raised, and noting the version, once released.

@basvanbeek
Copy link
Member

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

@codefromthecrypt
Copy link
Member Author

thanks for the help @basvanbeek

@codefromthecrypt
Copy link
Member Author

codefromthecrypt commented Oct 11, 2016

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

@codefromthecrypt
Copy link
Member Author

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

@codefromthecrypt codefromthecrypt changed the title Track tolerant reads of 128 bit X-B3-TraceId Track support of 128 bit X-B3-TraceId Nov 2, 2016
codefromthecrypt pushed a commit to spring-cloud/spring-cloud-sleuth that referenced this issue Nov 5, 2016
* 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
codefromthecrypt pushed a commit to spring-cloud/spring-cloud-sleuth that referenced this issue Nov 6, 2016
* 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
codefromthecrypt pushed a commit to spring-cloud/spring-cloud-sleuth that referenced this issue Nov 6, 2016
* 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
codefromthecrypt pushed a commit to spring-cloud/spring-cloud-sleuth that referenced this issue Nov 6, 2016
* 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
codefromthecrypt pushed a commit to spring-cloud/spring-cloud-sleuth that referenced this issue Nov 17, 2016
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
@codefromthecrypt
Copy link
Member Author

codefromthecrypt commented Nov 21, 2016

added this to support 128-bit traces in zipkin-js openzipkin/zipkin-js#57

codefromthecrypt pushed a commit to openzipkin/zipkin-aws that referenced this issue Oct 17, 2017
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
codefromthecrypt pushed a commit to openzipkin/zipkin-aws that referenced this issue Oct 17, 2017
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
codefromthecrypt pushed a commit to openzipkin-attic/sparkstreaming-stream-kinesis that referenced this issue Apr 4, 2018
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
@codefromthecrypt
Copy link
Member Author

thgoexpt added a commit to thgoexpt/Java-distributed-tracing-implementation that referenced this issue Apr 7, 2022
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
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

No branches or pull requests

2 participants