search

spring-cloud / spring-cloud-sleuth

Distributed tracing for spring cloud
https://spring.io/projects/spring-cloud-sleuth
Apache License 2.0
1.77k stars 782 forks source link

make baggage more convenient. #921

Closed bloodstars closed 6 years ago

bloodstars commented 6 years ago

using version 2.0.0.M9, i dont want to put "spring.sleuth.baggageKeys: foo" everywhere. the previous way "span.setBaggageItem(baggageKey, baggageValue);" is good enough, why change? when can it use baggage as convenient as used to be.

thanks every one.

codefromthecrypt commented 6 years ago

In moving to the new infrastructure, we are taking different tradeoffs which involve a lot of new functionality, but also a few constraints. You've hit an intentional one: wildcard keys will not be in sleuth 2.0

The good news is coordinating properties is nothing new to spring. Many sites have different things they need coherent for their environments. Setting this property is no different than any other. You can use https://spring.io/guides/gs/centralized-configuration/ for example.

If you'd like to elaborate anyway, what are you setting in baggage? do you have no other properties in your environment that you have to set? or are you just not happy with having to be explicit about which headers are permitted to flow through your apps.

codefromthecrypt commented 6 years ago

by the way.. in a later version of brave (and sleuth) we will have a different implementation of propagated values which doesn't require individual header per entry (similar to how amazon xray works). This would allow you to map arbitrary properties that you can read and write, but doesn't imply wildcard headers which is the problem here.

codefromthecrypt commented 6 years ago

so the TL;DR:

Instead of having "baggage" implemented by separate headers like:

baggage-user: robbie
baggage-device: android

you'll have a choice to use a single header, which then won't require a whitelist

correlationcontext: user=robbie,device=android

In other words, the capacity to do variable propagated data will be reworked so that it doesn't require a variable amount of headers, or specifying them. You can follow the below for this feature, but it isn't likely to land before 2.0 final. When it does land, it will be an opt-in feature https://github.com/openzipkin/brave/pull/577

bloodstars commented 6 years ago

i see , thanks for your answer.