Can i override a TraceId with my custom uniqueId in each service?

[hyginous29]

Can i override a TraceId with my custom uniqueId in each service?

A -> B -> C

Here, all A, B and C has already existing unique id which is same across these 3 , can this uniqueId be injected in to the spans across all services?

[yurishkuro]

We don't officially support it, for reasons similar to https://github.com/opentracing/opentracing-java/issues/272#issuecomment-386032114.

You can hack it, of course, by casting span context to jaeger type and overriding private traceID field.

[hyginous29]

Hi Yuri,

Thanks for your response.

"You can hack it, of course, by casting span context to jaeger type and overriding private traceID field."

Please could you share the sample code on how the above hack can be done.

[yurishkuro]

You will have to use reflection API to get access to the private field and set it. I don't have a code example.

[hyginous29]

ok thanks, is there a plan to support overriding traceId in near future release ?

[yurishkuro]

No current plans. Can you describe your use case in more details? Why do you need to use external trace ID?

[hyginous29]

thanks yurishkuro, i got how to implement.

[rakeshbshukla]

@hyginous29 can u share how you got it implemented?

[KishoreKaushal]

@yurishkuro Since, its been one year, I would like to know the status of this issue. Is it officially supported, if not, then any future plans for this? Thank You.

[yurishkuro]

There are no plans to support it. There are no clear requirements here what it even means, how the API would look like, whether the type of the ID remains int64, etc.

[runlevl4]

Just getting started, but I think a perfect use case would be having an API gateway generate the unique ID. That way you wouldn't have one ID at the gateway and another for the downstream services.

[yurishkuro]

As long as you can convert your external ID into 128bit blob, I think it's fine to support it.

But we would need to support SELF reference as well, because otherwise there's no way to tell the tracer to use external ID and not create a new one. Cf. https://github.com/jaegertracing/jaeger-client-go/blob/0ba3a027993746a337cd174eaac31620589f1867/README.md#selfref

[tsologub]

I see this as a great example for automatic testing. I create a trace with a custom id and then verify that it has reached the destination via /api/traces.

[yurishkuro]

@tsologub you can achieve the same without custom ID, by using baggage.

[Spark2107]

@yurishkuro I have the problem that I want to add some spans to a specific trace. The use case is, that I create a trace in a micro service and give the traceId back to the client. The client then has it's own information which should be added to the given trace. Is there any possibility to do so? Since I can create Jaeger-Spans for the client information, I need some kind of way to set the traceId for those spans before I finish them to send them to the Jaeger server.

[yurishkuro]

@Spark2107 we've been recently recommending SELF reference for that, which is supported in C++ and Go clients (https://github.com/jaegertracing/jaeger-client-go/blob/0ba3a027993746a337cd174eaac31620589f1867/README.md#selfref), but not in Java. Feel free to create a PR for it.

[Suedo]

No current plans. Can you describe your use case in more details? Why do you need to use external trace ID?

@yurishkuro We have around 10 Spring boot microservices, which communicate with each other via kafka. The logs of each microservice are sent to Kibana, and in case of any errors, we have to sift through Kibana logs.

The good thing is: at the start of any flow, a message-id is generated by one of our microservices, and that is propagated to all the others as part of the message transfer (which happens through kafka), so we can search for the message-id in the logs, and we can see the footprint of that flow across all our microservices.

We are now loking to implement distributed tracing, and would want to use the above mentioned custom generated message-id as the trace.

I'm looking at the source code for how a JaegerSpanContext gets created, and a traceIdLow and traceIdHigh are being used. traceIdHigh is set to 0 unless we are specifying that we want to use 128 bit id.

    private JaegerSpanContext createNewContext() {
      String debugId = getDebugId();
      long spanId = Utils.uniqueId();
      long traceIdLow = spanId;
      long traceIdHigh = isUseTraceId128Bit() ? Utils.uniqueId() : 0;

This is probably too naive, but what if:

1. In our application codebase, I extend JaegerTracer, and then
2. pass an argument to createNewContext, which will be our messageId string, somehow turned into a long value ( which is what Utils.uniqueId() gives
3. set this value newly generated value in traceIdLow

Do you think this will work? Do we still need the SELF reference part you mentioned above?

[yurishkuro]

The good thing is: at the start of any flow, a message-id is generated by one of our microservices

if your services are traced, a trace-id would also be generated, probably even before message-id. Why not use that as a message-id?

I don't want to comment on the approach that tries to hack around the existing code, you can do it at your own risk. Given that the creation of new trace id is built-in when starting the first span, I believe SELF-reference is the appropriate way to implement that, consistent with other Jaeger SDKs.

[Suedo]

I believe SELF-reference is the appropriate way to implement that, consistent with other Jaeger SDKs

Does Java client have self reference ? I don't see it mentioned.

if your services are traced, a trace-id would also be generated

I'm not sure what you meant. Our services are traced via a custom message-id that we generate. We don't use any open tracing library yet. We want to use the message-id that we create ourselves as a trace-id.

but I think a perfect use case would be having an API gateway generate the unique ID

this idea that @runlevl4 mentioned is also something we are possibly going to have/need in the future. This is a pretty valid scenario imo