Best Practice for Propagating Upstream Call Info to Access Logs in Spring Cloud Gateway

[oemergenc]

Background

I'm implementing a Spring Cloud Gateway application that captures upstream call information (HTTP method, path, duration, status code) and includes it in access logs. This information is valuable for monitoring and debugging. I have build a demo project showcasing how I have currently implemented it. There is a integration test showing that the info is available in the logs, see here:

https://github.com/oemergenc/spring-cloud-gateway-demo/blob/main/src/test/java/com/gateway/ItTest.java#L43-L59

I am unsure whether I need to asked it here or at reactor-netty, so I am first trying here.

Current Implementation

I've implemented this using three main components:

1. UpstreamCallInfoHttpClientCustomizer: Captures information about upstream calls and takes the ServerWebExchange from the current context to manually add the upstream info in a custom header to the response.

2. UpstreamCallInfoOutboundHandler: Retrieves this custom header from the context, extracts the upstream call info, stores it in the Netty channel attributes to be consumed by the access log handler, and then manually removes the header.

3. MyAccessLogHandler: Retrieves the upstream call info from the channel attributes and includes it in access logs.

My Concern

The current approach works, but I'm concerned about manually modifying HTTP response headers to pass this information between components. This feels like I might be missing a more idiomatic approach in Spring Cloud Gateway or Reactor Netty or both.

From the test logs, I can see it correctly captures:

{
  "@timestamp": "...",
  "method": "GET",
  "protocol": "HTTP/1.1",
  "upstreamCallInfo": {
    "httpStatus": 200,
    "methodAndPath": "GET http://.../question",
    "duration": "..."
  }
}

Question

Is there a recommended best practice for propagating context information from Spring Cloud Gateway's HTTP client to the server response handling pipeline? Specifically:

1. Is there a built-in mechanism to share metadata between the client and server contexts without modifying headers?
2. Would using Micrometer's Observation be more appropriate for this use case?
3. Are there any existing components in Spring Cloud Gateway that already solve this problem?

Manually adding and removing custom headers to pass information between components doesn't feel like the right approach. I'd appreciate any insights on implementing this pattern in a way that aligns with Spring Cloud Gateway's design principles.