Set trace id via SpanBuilder

[Marfusios]

Hello,

we have a system built on Kubernetes and Linkerd and we need to somehow merge tracing logs inside the Jaeger from an infrastructure layer and from an application layer.

Linkerd already sends trace id in an HTTP header, so it would be great to have the possibility to override trace id while building Span on the application layer.
Is the provided solution convenient?

[yurishkuro]

A few thoughts on this:

• just so we understand the implication - your instrumentation becomes coupled with Jaeger, i.e. it is no longer portable to other OpenTracing tracers
• I am not strongly opposed to the method, but would like a stern warning in the comments not to use it except for very specific cases and provide a concrete example. Also call out the risk that if Jaeger changes how it represents trace IDs internally, the code using this method might break, and no guarantees are given by Jaeger maintainers that it won't happen.

PS each commit must be signed, since you missed one your best option is to do git reset --soft HASH to a HASH before your change and re-commit with -s flag

[Falco20019]

If you can bring Linkerd to use the format that OpenTracing uses for SpanContext, then you can use the normal extraction process. Right now, you can create you own SpanContext with a specific tracing id using SpanContext.ContextFromString(string) and let the new trace from the SpanBuilder reference that one. This would allow you to stay in the regular OpenTracing portability. This would still lock you on to how Jaeger represents trace IDs internally.

So I assume your suggestion is still worth discussing since you would be locked into Jaeger as OpenTracing implementation either way and it would make your use case easier to handle.

[Marfusios]

Thanks for the info, locking to Jaeger is fine for us.
I believe I can use SpanContext.ContextFromString(string), Linkerd sends coordinates (traceId, spanId) in the header.
I think my solution is insufficient because of missing parent spanID.

Btw I found out that you groundbreaking refactored code and I still use version 0.0.9.
So I will wait for the new released version and then come back to this feature.

[Falco20019]

You can subscribe to #62 to be informed once 0.0.10 is released. We plan to release it the next days, since OpenTracing 0.12.0 should also release end of this week.

[Falco20019]

I'm closing this, since your problem was solved in #87. Feel free to reopen it if you still see a use case where this would be benefitial.