SpringBoot Provide Trace ID in Response Header via configuration

When using Spring Boot in larger teams, it's really desirable to expose the Trace ID in the response headers. This way, debugging problems becomes easier as the person experiencing the problem (using a client such as curl) can include the Trace ID easily and tell the responsible developer exactly how to find relevant logs.

Currently, this can be achieved by defining the following @Configuration for WebMVC:

@Configuration
public class TracingConfiguration implements WebMvcConfigurer {

    private final SpanContextSupplier spanContextSupplier;

    public TracingConfiguration(SpanContextSupplier spanContextSupplier) {
        this.spanContextSupplier = spanContextSupplier;
    }

    @Override
    public void addInterceptors(InterceptorRegistry registry) {
        registry.addInterceptor(new HandlerInterceptor() {
            @Override
            public void postHandle(HttpServletRequest request, HttpServletResponse response, Object handler, ModelAndView modelAndView) {
                response.addHeader("X-TraceId", spanContextSupplier.getTraceId());
            }
        });
    }
}

IMHO, it would be nice feature if this could be enabled easily by setting the X-TraceId header name value via configuration, such as

spring:
  # configuration path completely made up!
  observability:
    trace-id-response-header-name: X-TraceId

Which would expose the Trace Id if the header name is non-empty. And of course, this should work independent of the Web Framework in use (WebMVC/WebFlux/...).

Comment From: jonatan-ivanov

I had been doing something similar for years in production and I'm still doing something else but similar in demo apps. I find/found such a feature useful.

On the other hand, I'm not sure this should be implemented in Boot only, I think both Micrometer Tracing and Spring Framework (where the instrumentation itself lives) can add some support for this and Boot can auto-configure it.

@marcingrzejszczak @bclozel What do you think?

Comment From: bclozel

The filter only depends on the observation API. Can we get the traceId with that API only?

Comment From: marcingrzejszczak

The filter only depends on the observation API. Can we get the traceId with that API only?

No, we can't. TraceId is a Micrometer Tracing thing. There would have to be a boot based config that given tracing is on the classpath would add some logic that would add the fields that are defined by the Tracing's Propagator interface to the response.

Comment From: neiser

@jonatan-ivanov @marcingrzejszczak I don't quite see why using SpanContextSupplier is not an option here? Anyhow, I think we need issues in upstream projects, right? Will you open them?

Comment From: bclozel

@marcingrzejszczak how can we get the Propagator instance? Is this some infrastructure bean? Can we get access to it if from the current observation somehow? We could consider an optional behavior in the Spring Framework ServerRequestObservationFilter if we can detect that the Tracing API is there and use it defensively.

Comment From: marcingrzejszczak

Micrometer Tracing's Propagator is a bean (example https://github.com/spring-projects/spring-boot/blob/main/spring-boot-project/spring-boot-actuator-autoconfigure/src/main/java/org/springframework/boot/actuate/autoconfigure/tracing/BraveAutoConfiguration.java#L165-L169). From the point of view of the Observation we know nothing about tracing nor propagation mechanisms

Comment From: bclozel

Closing as a duplicate of spring-projects/spring-framework#30632