Join GitHub today
Support for configurable header names #19
The zipkin headers are here: http://zipkin.io/Instrumenting.html#instrumenting-other-libraries
There is an obvious immediate problem: Sleuth uses UUID for the ids (64 bits is really too small and Zipkin admits it).
We could also support Zipkin headers as an enhancement (include both sets). Seems like a waste of headers (we only need 3, but we end up with 7 or 8).
The bit size is aligned at this point. I'd recommend preferring B3 headers as the majority of instrumentation use these.
For example, there's no ruby-sleuth, and we'd needlessly re-start traces as a side-effect of passing through sleuth. The only architecture where the current choice doesn't hurt is when then entire architecture is made of sleuthed boot apps.
Here's the effect of being incompatible in polyglot or otherwise zipkin architecture:
Trace starts in zipkin instrumented entrypoint. This calls out to sleuth which ignores the headers and starts a new trace. Sleuth calls out downstream with an incompatible header. The receiver ignores that header and can't see the original headers so thinks its a new trace again. So 3 traces for the same trace in the same zipkin span store.
I'll put some of @adriancole 's notes from Gitter
referenced this issue
Mar 14, 2016
So actually this issue composes of two:
The first one is already possible with Joiners and Injectors
With finishing the second one I'll update the docs and show how one can make the headers configurable
@drpotato - check out the docs - http://cloud.spring.io/spring-cloud-sleuth/spring-cloud-sleuth.html#_customizations