This is a list of zipkin libraries and their status in supporting b3 features
language | library | 128-bit trace ID | b3 single format | notes |
---|---|---|---|---|
javascript | zipkin-js | v0.5+ supported | unsupported | |
python | py_zipkin | 0.8+ supported | unsupported | |
java | brave | 3.15+/4.9+ supported/epoch128 | 5.3+ supported | |
scala | finagle | 0.40+ downgrade | in progress | |
ruby | zipkin-ruby | 0.28+ supported | unsupported | |
go | zipkin-go | 0.1+ supported | 0.1+ supported | |
go | zipkin-go-opentracing | 0.2+ supported | unsupported | |
php | zipkin-php | 1+ supported | unsupported | |
java | wingtips | 0.11.2+ transparent | unsupported | |
java | jaeger | 0.10+ downgrade | unsupported | |
csharp | zipkin4net | 0.4+ supported | supported |
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
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);
}