3

I am trying to use the 128 bit Sleuth generated TraceId as a unique identifier for request hitting my controller. I understand that the default traceId is 64 and to change it, I have to add the following to the application.properties:

spring.sleuth.trace-id128=true

This works on my local but when I deploy it to PCF,the trace ID is 64 bits. I have created a sample project that only has a simple controller to demonstrate this.

@RestController
public class Controller {
    private Logger logger = LoggerFactory.getLogger(Controller.class);
    @Autowired
    private Tracer tracer;
    @GetMapping("/")
    public void test(){
        logger.info("LOGGED +["+tracer.currentSpan().context().traceIdString()+"]");
    }
}

In my local, it will print:

com.example.demo.Controller: LOGGED + [5bfcb33c9d564481479f2c212ec08143]

In PCF, it prints:

om.example.demo.Controller : LOGGED + [97a1168857dc7088]

Is PCF overwriting this configuration?

Updates

Included "X-B3-TraceId" and "X-B3-SpanId" in my request and the traceId is now 128bit but not the same string as what was passed in the request header.

Details from log

Yan Han
  • 31
  • 3

1 Answers1

1

It's possible that PCF, more specifically the Gorouter, is creating the trace id and that is getting propagated onto your app, which instead of creating a new 128-bit trace id is reusing the existing 64-bit trace id.

PCF has support for Zipkin Tracing and this is enabled by default, so it's on in most environments.

https://docs.pivotal.io/pivotalcf/2-3/adminguide/zipkin_tracing.html

According to the docs, the Gorouter will check for the existence of Zipkin headers on incoming requests and if they are not present will create them.

If the X-B3-TraceId and X-B3-SpanId HTTP headers are not present in the request, the Gorouter generates values for these and inserts the headers into the request forwarded to an application.

and

If the X-B3-TraceId and X-B3-SpanId HTTP headers are present in the request, the Gorouter forwards them unmodified.

https://docs.pivotal.io/pivotalcf/2-3/concepts/http-routing.html#zipkin-headers

You can see here that it's creating a 64-bit trace id.

https://github.com/cloudfoundry/gorouter/blob/master/handlers/zipkin.go#L49-L57

You could confirm by sending a request with the headers X-B3-TraceId and X-B3-SpanId set. In this case Gorouter should forward them along unmodified.

Ex: curl -v -H 'X-B3-TraceId: 5bfcb33c9d564481479f2c212ec08143' -H X-B3-SpanId: 5bfcb33c9d564481479f2c212ec08143' https://your-cool-app.com/test.

Daniel Mikusa
  • 13,716
  • 1
  • 22
  • 28
  • Thanks for your reply. I tried what you mentioned and it seems that when i include a 128 bit trace and span id in my request header, the trace and span Id in my application does indeed become 128 bit, but it is different from what i specified in my request. In fact, regardless of the value I indicated, the propagated traceId and spanId is always "5c05f313f7d726cd1509f63585df7a7c" – Yan Han Dec 04 '18 at 03:24
  • I'm not certain why that would be the case. How are you monitoring this? If you're setting those headers they are just being passed through by Gorouter so it's not going to modify them. If you look at `cf logs` there should be an `[RTR]` log entry which is generated by the Gorouter. It will have the header value, can you try running that to confirm that it is at least getting the header value you specified? From there, maybe try logging the headers that are coming into the request in your app. You can try to break down where the value is being changed. – Daniel Mikusa Dec 04 '18 at 04:55
  • Hi @Daniel, thank you for your reply once again. I have monitored the logs from the PCF Application Manager and included a link in the updated question for a screenshot of the log. My mistake on the comment that the traceId always take on a particular value, that is not true. However, what I observe is that in the 128bit traceId, the first 3 hex does not change. It is always 5c0. It seems like it is related to timestamps? – Yan Han Dec 05 '18 at 07:06
  • I'm not sure. The trace id you're logging in `LOGGED +[..]` is produced by Sleuth. I don't know off hand the exact method it's using to create the trace/span ids. You'd need to look at the code or maybe post a different question if that's something you want to know more about. – Daniel Mikusa Dec 05 '18 at 14:43
  • It should be the same traceId that is passed into the TraceContext if I am not wrong. Alright sure! Thank you for your help Daniel! – Yan Han Dec 06 '18 at 08:32
  • @YanHan have you found any solution for this issue as I am also getting similar issue when I have deployed my code in one of the GCP environment. – rishabh keshari 1992 Oct 13 '22 at 11:53