E2E tracing From a non-spring application to a spring/sleuth one: Need some validation

[dom-42]

Hi

I have a non spring application (an ESB indeed) which has its own trace mechanism (w/traceid and spanid ;) ).
This application writes to a kafka topic consumed by a regular spring stream/sleuth microservice. I added simili sleuth headers to this topic (spanTraceId=myTraceId, spanId=myTopicId, aso ...) in order to get E2E tracing mechanism and leverage sleuth implementation where it's available.

This seems to work, sleuth recognize my headers and create new spans attached to my own trace.
Question is, do you think this approach is a good one or should I use another mechanism ?

Thank you for your help.

[marcingrzejszczak]

Yeah it seems like a good idea. If you create on this topic messages that Sleuth Stream understands then it's perfectly fine. That's the idea of the interop. If your app sends Sleuth compatible headers - that's perfectly fine.

[dom-42]

Hi Marcin

Great. Thank you. No specific format to respect anyway ?

[marcingrzejszczak]

These are the headers we expect in terms of passing of tracing information in messages - https://github.com/spring-cloud/spring-cloud-sleuth/blob/master/spring-cloud-sleuth-core/src/main/java/org/springframework/cloud/sleuth/instrument/messaging/TraceMessageHeaders.java#L29-L35 .

This is how a Span message should look like if you want to send it to a Sleuth Stream Collector - https://github.com/spring-cloud/spring-cloud-sleuth/blob/master/spring-cloud-sleuth-stream/src/main/java/org/springframework/cloud/sleuth/stream/Spans.java

[dom-42]

Perfect, will keep same formats then.
Thx

[ashwgupt]

If one is using a language that has http://opentracing.io supported libraries, should not one use that instead?

[marcingrzejszczak]

You can check out this issue #253 for more info about this. We've initially decided to pick a different transport format for sending spans via messaging and currently the plan to change it is low in terms of priority. You can always run our collector and store spans to the same DB as other collectors.

[dom-42]

Hi

@ashwgupt: not in our use case: we already use Sleuth tracing mechanism within our Spring Cloud applications but upstream and downstream we use components that don't rely on Spring (WSO2 ESB e.g.).
In order to get E2E tracing, we had to find a bi-directional solution which propagates Sleuth headers from and to these components.

[marcingrzejszczak]

BTW let's differentiate 2 things here - one is tracing headers in messages and the other format of spans. Tracing headers in messaging can't be zipkin compatible since they are invalid for JMS (you can't have hyphens in header names).