Reputation: 51
1 - While working on a POC for sleuth, we gathered that if an incoming request to a slueth enabled application has trace/span and parent ids, they are propagated forward and new ids are not generated. However, this seems to work only when ALL 3 are present. We tried with just trace id in request headers and a new trace id was generated by sleuth - Please confirm if all 3 need to be present for successful propagation.
2 - We have multiple micro-services that talk to each other. Some of them are invoked directly from the UI layer and some others from non-sleuth applications. In both these cases, a 128 bit UUID is sent as trace id in the request. If we want to use sleuth, we would need to generate sleuth compatible 64 bit ids from the UI layer and from non sleuth apps so that they can be successfully carried over during request execution through multiple sleuth enabled apps. Can you please advice on how we can implement the 64 bit id generation so they it is compliant with sleuth standards and is propagated successfully. What are the requirements of a valid sleuth id?
Any pointers would be highly appreciated.
Thanks in advance.
Upvotes: 0
Views: 726
Reputation: 61
You don't need to specify neither of them in to work. The span is a set of work that is done and the trace id is the correlation between all small works that are done. For example:
Upvotes: 0
Reputation: 1217
A sleuth enabled app only looks for the value of header named x-b3-trace-id in the http request headers. This value is passed by the requesting app and reused by the called sleuth enabled app for its traceId. Nothing else is needed. Also keep in mind that by default, traceId and spanId are equal for all the log entries.
Answer to this question is also in #1 above. If you have x-b3-trace-id embedded in the request header, that is basically what sleuth would care about for it's trace id.
I hope this helps
Upvotes: 1