LogFilter is not compatible with spring-cloud-sleuth

[sabertiger]

An application with both spring-cloud-sleuth and spring-log-filter generates two trace ids for the same request when no/invalid X-B3-TraceId is passed in an incoming http request. The spring-cloud-sleuth trace id is present the application's RestTemplate requests to external web services and some portions of the application log. The spring-log-filter trace id is passed in the application to client response header and other portions of the application log.

Verified that sleuth filter always runs first, and predix-log-filter runs second. org.springframework.cloud.sleuth.instrument.web.TraceFilter has very high precedence: Ordered.HIGHEST_PRECEDENCE + 5. com.ge.predix.log.filter.LogFilter has no set precedence, and thus run as the default Ordered.LOWEST_PRECEDENCE.

When the incoming http request contains a valid X-B3-TraceId, the outgoing RestTemplate request, logged trace id, and response trace id all correspond to the request value.

client -> application request: X-B3-TraceId: 932bc1133632e066
application log: 2017-06-02 11:38:33 DEBUG [app,932bc1133632e066,932bc1133632e066,false] event1
application -> external web services: X-B3-TraceId: 932bc1133632e066
application log: 2017-06-02 11:38:34 DEBUG [app,932bc1133632e066,932bc1133632e066,false] event2
client -> application response: X-B3-TraceId: 932bc1133632e066

However, when the X-B3-TraceId is missing or invalid, LogFilter generates its own value instead of reusing the value generated by spring-cloud-sleuth resulting in two distint trace ids for the same request:

client -> application request:
application log: 2017-06-02 11:38:33 DEBUG [app,ce0085cc-ea90-41f9-938a-82fdf5394637,932bc1133632e066,false] event 1
application -> external web services: X-B3-TraceId: 932bc1133632e066
application log: 2017-06-02 11:38:34 DEBUG [app,932bc1133632e066,932bc1133632e066,false] event 2
client -> application response: X-B3-TraceId: ce0085cc-ea90-41f9-938a-82fdf5394637

[sanjeevchopra]

thanks @sabertiger.

sleuth had the function to echo trace-id in response headers, and it was removed due to security concerns. see spring-cloud/spring-cloud-sleuth#424

• lets find out what the concerns were. If we agree, we should remove this function
• the feature of initiating the trace, when not present is not required here either - because all projects using this filter are in cloudfoundry where the cf router adds a trace id anyway.

[sanjeevchopra]

If we decide to do this, sleuth documents how to include headers in response:
http://cloud.spring.io/spring-cloud-static/spring-cloud-sleuth/1.2.1.RELEASE/#_example , search for CustomHttpServletResponseSpanInjector

[metacubed]

The functionality to generate trace and span ids has been removed from the latest release.

OpenTracing/Brave now defines three separate standards for tracing headers, so it's best to rely on their standard libraries for detection/generation of these values.

We've also removed the functionality to echo trace ids in response headers for the same reason - X-B3-TraceId is now superseded by the "single header" trace format.