Open ewolz3 opened 2 years ago
Reading https://github.com/openzipkin/b3-propagation further, it doesn't seem like the b3 header should be necessary for B3MultiFormat at all
. I would expect this to only be used for B3SingleFormat
.
Hi @ewolz3 any luck with this?
There isn't much (any) documentation but I tried to do the same and encountered issues. GCP has recommended OpenTelemetry as the tracing approach but we need b3 header propagation to merge custom traces with Istio/Anthos service mesh traces. I am curious if anybody has done this yet or if this is new territory, examples are very hard to come by.
@ColeSiegelTR - It's not been a major blocking issue in my environment (all 3 headers are getting set by Cloud Foundry), but it was unexpected behavior I encountered in unit testing that I wanted to raise on behalf of the community.
Describe your environment Python 3.8 Flask 2.0.3 opentelemetry-propagator-b3 = 1.10.0 opentelemetry-instrumentation-flask = =0.29b0
Steps to reproduce Following https://opentelemetry.io/docs/instrumentation/python/getting-started/#configure-your-http-propagator-b3-baggage, set_global_textmap using the B3MultiFormat() rather than the deprecated B3Format.
set_global_textmap(B3MultiFormat())
Make an API request from Postman (or other client tool of your choice), and set the following headers:
See that it works
Make the same request, but this time do not set the b3 header (still set the x-b3-traceid and x-b3-spanid headers)
See that it crashes
Make the same request without any of the headers,
See that it works
What is the expected behavior? Clients providing incomplete set of propagation headers should not result in an unhandled exception being raised to the web app.
What is the actual behavior?
Additional context Add any other context about the problem here.