-
Notifications
You must be signed in to change notification settings - Fork 182
Inject tracid and spanid #137
Comments
It's not a question of OpenTracing, but of the specific tracing library implementation you bind your code to. For example, in Jaeger you can force the use of the external trace ID (but not span IDs) provided it is representable as a 8-bytes or 16-bytes array. |
Do you know any library allowing me to inject those IDs? |
I don't know if any tracer is able to accept completely arbitrary IDs. These IDs are usually captured in the span and stored in the tracing backend, so the backend data model puts additional limitations on what can be used as an ID. I would say reusing IDs not generated by the tracing infrastructure is not where the industry is going to (e.g. https://github.com/w3c/trace-context), but some tracing platforms might support them for legacy services. E.g. in Jaeger, as long as your legacy/external IDs fit in 16-bytes array, it can still capture/represent them in the storage. There is still going to be an issue with using message-id as span-id, because APIs like OpenTracing/OpenCensus don't allow you to provide a custom id when creating a new span (you'd need to hack the tracer implementation a bit), and you do need to create a span for the producer generating a message in order to capture proper causality between spans in the trace. |
Hello, ok I understand better a little bit. How do you track a workflow which is fragmented in time and space? A digital contract is suspended and continued after a few weeks of delay? How should I connect the new spans to the old ones? Or in a stock market platform where some part of the process is cultivated in a different system / counrty? Should I persist the context and inject it manually? Thanks... |
Yes, you can persist the trace context with the data/message and use it to resume the trace later. But many tracing systems wouldn't work very well with workflows that takes days/weeks to complete. |
Hello,
I have a highly scaled microservice app and my messages passed through a nats.io already process IDs, correlationIDs and parentIDs. Everything actually to reconstruct the complete directed call graph.
Is there a way to inject these IDs to an opentracing solution? I would not use new IDs but using the already existing ones allowing me to adopt the flow implicitely from the message bus.
The text was updated successfully, but these errors were encountered: