this version used a way for "scoping" which was not try/finally in nature
and so had a higher chance of leaks vs the 2.x line which use brave's CurrentTraceContext api
there are still some leak problems in sleuth mostly in reactor
but for webmvc normal should be none
there's always chance for leak
main thing is less chance, the try/finally api makes it easy to see when people make leaky stuff
ex ever see something should be used in try/finally and carelessly doesn't close
if api isn't meant to be try/finally it is very hard to see where leak occurs
this is the technical reason why 2.x should be less leaks and generally is
thx!!!
Hi All,
I am relatively new to sleuth framework.. I have an usecase where traceId needs to be sent back in the response header. I was hoping to achieve the same using annotations or configuration. When I had searched they were achieved by adding filters (also found few old threads where they had mentioned that sending traceId in the response header has been removed due to potential security concern). In the latest implementation are there any configuration/annotations for the same or I would have to write a trace filter? Any help on this is appreciated
I am relatively new to sleuth framework.. I have an usecase where traceId needs to be sent back in the response header. I was hoping to achieve the same using annotations or configuration. When I had searched they were achieved by adding filters (also found few old threads where they had mentioned that sending traceId in the response header has been removed due to potential security concern). In the latest implementation are there any configuration/annotations for the same or I would have to write a trace filter? Any help on this is appreciated
the tracing system does not mutate the response at the moment, so it can't write response headers
Hi
What's the difference between
In the sleuth properties appendix its given with
https://cloud.spring.io/spring-cloud-sleuth/reference/html/appendix.html
What's the difference between
spring.sleuth.remote-fields vs spring.sleuth.baggage.remote-fieldsIn the sleuth properties appendix its given with
baggage. whereas in the documentation withouthttps://cloud.spring.io/spring-cloud-sleuth/reference/html/appendix.html
Which of these is correct
@saisuryakat if using sleuth v3 the latter https://github.com/spring-cloud/spring-cloud-sleuth/wiki/Spring-Cloud-Sleuth-3.0-Migration-Guide#property-names-1
the link you are pointing to is the version 3 docs
ah I see what you are saying
thanks. can you do a pull request to fix this?
but I'm having trouble making baggage fields work
Is there any sample repo present for reference
I'm confused esp whether to just define the headers in application.yml and set the values in controller or to config brave(as shown in brave docs)
brave is used for other things even spring 2.5
sleuth has things built-in so easier to use properties than javaconfig for the same result
I'm changing example project for you hold a sec
Are there any working examples of integrating a spring boot project with AWS X-Ray? A quick googling say no. Do I just import the deps (spring-cloud-starter-zipkin/io.zipkin.aws:zipkin-reporter-xray-udp) and override the
ZipkinAutoConfiguration.REPORTER_BEAN_NAME with my own XRayUDPReporter bean? There doesn't seem to be any auto-config for the Zipkin X-Ray but I'm happy to be wrong.