b3 debug flag is not forwarded

[aberres]

b3 has the concept of a debug flag which forces tracing no matter what.

If this flag is set on an incoming trace sampling should be enforced. For outgoing requests the flag should be passed along.

Right now in the multi header case the flag is completely ignored. In the single header case tracing is enabled, but the debug state is not forwarded.

Some discussion can be found in #595 / #595 (comment).

[c24t]

This is a tricky issue since we don't have any way of representing this on the span. Any change we make to support the debug header would have to be made in every client. I opened up census-instrumentation/opencensus-specs#260 to track this in the specs repo.

[c24t]

Based on census-instrumentation/opencensus-specs#260 (comment), our best bet may be to store the b3 single header format in the tracestate to make sure we pass it along in outgoing requests.

cc @LokiW

[aberres]

I am wondering one thing: Should Opencensus allow to forward additional headers?

When looking, e.g., at Istio at least x-request-id is a candidate which needs forwarding as well: https://istio.io/docs/tasks/telemetry/distributed-tracing/overview/
Without support for this in Opencensus as a user I need to duplicate the forwarding logic for the remaining headers.

[c24t]

I don't think it makes sense for OC to handle headers that don't affect tracing (or metrics, logging, etc.), even just to forward them, but I see how it could be a headache to have separate handlers for each set of headers.

@rghetia and @bogdandrutu may have more insight on integration with istio.

[rghetia]

While I understand that it is a headache on application side to instrument their application just for a single header, we have to be careful in propagating additional attributes.

If the purpose of forwarding x-request-id is to correlate client request on server side then it can be done using trace-id.

[aberres]

If the purpose of forwarding x-request-id is to correlate client request on server side then it can be done using trace-id.

For me that would be an option.

Istio and Envoy do not seem to agree though:
https://istio.io/help/faq/distributed-tracing/#how-to-support-tracing
https://www.envoyproxy.io/docs/envoy/latest/configuration/http_conn_man/headers#config-http-conn-man-headers-x-request-id

Istio even mentions using client libraries:

Header propagation may be accomplished through client libraries, such as Zipkin or Jaeger. It may also be accomplished manually, as documented in the Distributed Tracing Task.

I cannot judge what is right or wrong in this context. All I can say is that the current situation when trying to get all the different technologies glued together is a bit unsatisfying.

[rghetia]

I would suggest that we open an issue to support propagating x-request-id in spec repo as it is relevant to all languages.
There we can discuss whether to add the support or work with Istio to re-use trace-id, with an eventual outcome of better experience for the user.

[c24t]

Let's leave this issue open to track storing the b3 single header format in tracestate from the b3 propagator, and track forwarding x-request-id (and other headers) separately.