Truncation of tracestate and/or baggage

[anuraaga]

Hi all. I'm looking into how AWS managed services can support propagation of headers like tracestate and baggage. One concern is that these can get pretty big, especially baggage which is controlled by the user. Are there any best practices for dealing with these? In one case, we are being given a quota of around ~50 additional propagated bytes for both of these - naturally this is well below the limits of these headers. What is a reasonable number of bytes to get good bang for buck for these headers? Can AWS be considered to officially support these headers if we have to truncate to such a small size? Is tracestate or baggage more important to propagate if we have to choose due to size constraints?

Appreciate any thoughts on these headers, I haven't used them much myself so not sure what the practical sizes are.

[yurishkuro]

I think these questions are better raised in W3C Trace Context repo.

Can AWS be considered to officially support these headers if we have to truncate to such a small size?

WIth 50 bytes I would say no, based on my experience with using baggage. If you go to 100-200, that's still below W3C spec, so I'd say "supports (*)" and explain the limits.

[anuraaga]

I think I'm more interested in this as a user of the tracecontext, via OpenTelemetry, rather than the actual definition so feel this is a good repo. We must have some users of these headers here :) @Oberon00 Do you know how this truncation would affect Dynatrace? I guess they use tracestate.

Any tracing backends use baggage natively?

WIth 50 bytes I would say no, based on my experience with using baggage. If you go to 100-200, that's still below W3C spec, so I'd say "supports (*)" and explain the limits.

Can I interpret this as 50 is too low to even be useful, 100 could be (but needs to be properly documented)?

[Oberon00]

The Dynatrace entry in the tracestate will use at least about 60-70 characters, but can be even more. Among other things we need to store a tenant-id (as part of the key) and the span ID corresponding to that tenant, so that a tracecontext participant that does not report to the same Dynatrace tenant does not break the trace (see #366 (comment)).

[yurishkuro]

Can I interpret this as 50 is too low to even be useful, 100 could be

Yes, but it's not really possible to provide lower bound on usefulness. You could get value from propagating just a client id, which could fit in 50.