When input headers have b3 or b3_multi tracing headers without the sampling flag, the OTEL trace propagators sets it to '0' (off) by default. The sampling flag is optional as per the b3 specs.
I have created a simple project to demonstrate the behavior here: https://github.com/dipsk2/tracing-sampling-flag. Please look at this test.
In general, the proxies do not set the sampling flag and lets the microservice decide if it wants to sample it. When sampling flag is absent and even when the probability is set to 100%, the trace ends up being suppressed from the export.
This is impacting cloud foundry go router (at least) which is not sending the sampling flag and this ends up in broken traces across the company. The first microservice decides to set it to 0 and then all the others follow.
When we set the management.tracing.propagation.type=w3c, it works fine. But this would need every one to produce/consume w3c only and creates compatibility issues across even spring-boot versions.
This is my first issue report. Please let me know if I need to provide more info.
Thanks, Dipesh
Comment From: mhalbritter
Hello,
first, thanks for the reproducer!
All of this happens inside OTels B3PropagatorExtractorSingleHeader, there's nothing we can do on Boot side to fix this. Please open an issue on the OpenTelemetry issue tracker. Feel free to link back here.
Thanks!