[enhancement] Extract baggage entries from HTTP headers and manage baggage entries as SLF4J MDC entries
See original GitHub issueScenario
Suppose we have a legacy service-x
(out of our jurisdiction) which need to call a service-a
(in our jurisdiction) which, in turn, will need to call other downstream services (also in our jurisdiction). Every request that service-x
sends to service-a
contains a custom HTTP header (e.g. X-Tenant-Id
).
We would like such header to be:
- extracted and propagated from
service-a
to the downstream services; - included in the log traces, together with the default distributed tracing info (e.g. trace id, span id, etc).
Current Approach
For the goal 1
, I’ve implemented a custom GenericFilterBean in the service-a
to extract the header and add its value to the span context as a baggage key-value pair. This is sufficient to propagate the tenant identifier to the downstream services because the span context travels together with the trace and is attached to every span.
For the goal 2
, I’ve implemented a custom SpanLogger which adds to and removes from the MDC the tenant identifier (as it’s currently done for trace id, span id, etc). And I’ve also updated the logging pattern accordingly.
First things first, is this the correct approach (in the context of the 1.3.3.RELEASE
version)?
Enhancement Requests
- Add a property to automatically extract HTTP headers and put them in the baggage, e.g.
spring.sleuth.http.baggage.fromHeaders:
- X-Tenant-Id
With the above configuration, if the application receives the HTTP header X-Tenant-Id
, it will add the same to the baggage of the span context.
- Add a property to automatically manage key-value pairs in the baggage as MDC key-value pairs, e.g.
spring.sleuth.log.slf4j.mdc.fromBaggage:
- X-Tenant-Id
With the above configuration, MDC will be updated properly by adding and removing the key-value pair related to the X-Tenant-Id
when necessary (as it’s currently done for trace id, span id, etc).
Sample Code
Notes
- I’d be happy to contribute the enhancements if you feel like they are general enough and they make sense in the context of Sleuth.
Issue Analytics
- State:
- Created 5 years ago
- Comments:25 (9 by maintainers)
You mean copying the whole Slf4jCurrentTraceContext, adding a couple
MDC.put(...)
andMDC.remove(...)
and registering the bean so that the default implementation doesn’t kick in?Yes, that is totally doable but maybe the configuration option would be a bit nicer? 😅
Thanks for adding this to the backlog and, again, I’d be happy to contribute with a PR.
It’s done and will be available with
2.1.0.M1
- https://github.com/spring-cloud/spring-cloud-sleuth/issues/1071