The behavior of other flags, such as ( 00000100 ) is not defined and reserved for future use. Implementation MUST set those to zero.
I'm pretty sad about this. I have other trace flags that I'd like to have available to me, like controlling the level of trace detail, or the recording other diagnostic information.
Does anyone else feel like this is a missed opportunity?
What are the chances that some of those bits could be allocated to vendor- or application-specific purposes?
If that's a pipe dream, what are the chances that Elastic APM Agents could add a second channel (e.g. HTTP header or GRPC metadata) for use by applications? Elastic APM Agents already do much of the ground-work for instrumentation and distributed tracing, it would seem a shame to not give users the ability to leverage that facility to a fuller extent.
I'm pretty sad about this. I have other trace flags that I'd like to have available to me, like controlling the level of trace detail, or the recording other diagnostic information.
Does anyone else feel like this is a missed opportunity?
There's two parts to trace-context: traceparent and tracestate. I think it's fine for traceparent to be strictly defined, as it's meant to be interpreted in a specific way by every vendor. Adding vendor-specifics to it muddies the waters a bit.
For application-specific flags, might it make sense to just define your own "vendor" tracestate key? The agents could provide helper functions for adding/updating/reading tracestate, and (as required by the trace-context spec) would ensure they are propagated. What do you think?
Apache, Apache Lucene, Apache Hadoop, Hadoop, HDFS and the yellow elephant
logo are trademarks of the
Apache Software Foundation
in the United States and/or other countries.
