Reputation: 199
I understand that with the advent of Spring Cloud Sleuth 3.x.x, you need to specify the name of baggage headers to be propagated to remote components like this:
# in application.yaml
spring:
sleuth:
baggage:
remote-fields: <name of the header>
For custom headers I think this is fine. I was wondering what this looks like for B3 / Zipkin if baggage should be transferred.
I remember a discussion about B3 not specifying baggage but that there was also a kind of "convention" that fields prefixed with baggage-
were forwarded.
Question 1: Is this correct, and is it still the case, or was that removed in Sleuth 3.x.x?
Question 2: If it was removed, does that mean that for B3 / Zipkin the baggage headers an application forwards will always have to be explicitly specified using the remote-fields
property?
Question 3: How are standardized baggage headers treated by Sleuth, e.g. W3C Trace Context Baggage. Are they forwarded automatically, or do they need to be explicitly specified using remote-fields
?
Thanks!
Upvotes: 0
Views: 992
Reputation: 11179
Question 1: Is this correct, and is it still the case, or was that removed in Sleuth 3.x.x?
We don't prefix the baggage with baggage-
or baggage_
anymore. Whatever you set as baggage (e.g. foo
) will be set as is in the headers.
Question 2: If it was removed, does that mean that for B3 / Zipkin the baggage headers an application forwards will always have to be explicitly specified using the remote-fields property?
Yes.
Question 3: How are standardized baggage headers treated by Sleuth, e.g. W3C Trace Context Baggage. Are they forwarded automatically, or do they need to be explicitly specified using remote-fields?
They are forwarded automatically. Check this part of the docs for more information https://docs.spring.io/spring-cloud-sleuth/docs/current/reference/html/howto.html#how-to-change-context-propagation
Upvotes: 1