Support for configurable header names about spring-cloud-sleuth HOT 10 CLOSED

Zipkin also offers instrumentation for Thrift services. If we are going for interop we should do the same, ultimately.

from spring-cloud-sleuth.

@adriancole thoughts? Have those headers changed?

from spring-cloud-sleuth.

X-B3-Flags: a Long was a mistake imho. I'll see if finagle folks want to remove this. The others are stable. PS there's a nuance hex strings are lowercase fixed-width.

from spring-cloud-sleuth.

What do we do about this? We can close it I guess?

from spring-cloud-sleuth.

I think we still need it. But maybe not urgent for 1.0.

from spring-cloud-sleuth.

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.

from spring-cloud-sleuth.

@marcingrzejszczak thanks for picking this up, looking forward to seeing it done!

from spring-cloud-sleuth.

I'll put some of @adriancole 's notes from Gitter

I think the core issue here is externalizing how to deal with out-of-process propagation
similarly to how reporting is configurable, yet doesn't change the structure of the span
ex in opentracing, hydrating a span from headers is "joining" and pushing a span into headers is "injecting" ( a term that sadly clashes with DI ) https://github.com/opentracing/opentracing-java/blob/master/opentracing/src/main/java/opentracing/Tracer.java#L51
Given this, you could make a component that, for example uses B3 defaults so that it interoperates with the most existing instrumentation
and that might include additional headers that help sleuth, for example the "process id" thing
if someone wanted to override that, they'd add a different component, as encoding is likely much more than just changing naming prefix.
#19 << for those wondering what we're discussing
in the javadoc for the propagator component, I'd mention what it is compatible with
for example, this can join traces originated by the following (currenlty only sleuth)
and this can propagate traces to instrumentation compatible with (currently only sleuth)
as mentioned in the issue, we'd get interop with several languages and frameworks on both sides simply by using B3 headers by default

and:

yeah basically you could extract a component which joins and injects
and make that default to B3
join (taking headers and making a span in consideration of them)
inject (take a span and make headers out of it)

from spring-cloud-sleuth.

So actually this issue composes of two:

• make headers configurable
• make headers zipkin compatible

The first one is already possible with Joiners and Injectors
The second one is in progress.

With finishing the second one I'll update the docs and show how one can make the headers configurable

from spring-cloud-sleuth.

@drpotato - check out the docs - http://cloud.spring.io/spring-cloud-sleuth/spring-cloud-sleuth.html#_customizations

from spring-cloud-sleuth.