Vendor information in the response from traced service

[wjch-krl]

Have you considered providing vendor information in a response from traced service in addition to traceresponse header (which provides information, that the call was traced, but without vendor information)?

This can be achieved by vendors adding proprietary headers, in addition to the traceresponse header.
However, having it standardized has a few benefits - the main being, having a standard way of detecting what kind of agent/vendor is generating trace events.

I believe this might be standardized similarly, to how this is done with the tracestate header for the traced Request.

Use-cases:

• determining if the outbound call was traced by the same agent/vendor
• for observability products - lit might be useful when linking other data to Trace (to ensure Trace is performed by the same vendor then log ingestion, or other check that might have generated HTTP call that triggered trace)
• more insight into the reason for the restarted trace (e.g., suggest that it was restarted by another vendor's agent seeing foreign trace)

Rough proposal:

• Re-use vendor codes defined in https://github.com/w3c/tracestate-ids-registry/blob/main/content/registry.md
• Add traceresponsestate header, with a format similar to tracestate header. However, the value might only relate to the last call (it doesn't need to be passed all the way back from the last service to the first caller) - simplification compared to tracestate which is preserved for every down-stream call - up for a discussion

[kalyanaj]

Thanks for the feedback and the above comment. We are looking to understand better the use cases you describe above: will you be able to share a use case of what a caller might do with the above information?

[wjch-krl]

Hi, @kalyanaj

Let me elaborate on the use-cases a bit:

• we are working on a product/feature that combines synthetic browser checks with trace data. To be more precise, when we probe the website, a special header is included to ignore sampling logic in our APM instrumentation libs and ensure that trace is not sampled. As a result, we are returning a trace ID, and additional information that this trigger-trace was successful. This is how it works currently: https://documentation.solarwinds.com/en/success_center/appoptics/content/kb/apm_tracing/trigger-trace.htm, but we want to move to W3C trace context from our proprietary TraceId. However, with the current proposal for traceresponse we can only obtain the TraceId, and sampling information. This means, that we don't know if an agent that understands this trigger-trace request was used. Additionally having that information makes data processing easier on the backed, as we can assume that if triger-trace request wasn't understood, we will not have this data in our backend in context of trace as well.
  We can keep our additional response header with those details as an addition to traceresponse header, but IMHO this might be a common theme across observability/monitoring platforms that combine synthetic website monitoring and distributed tracing
• From the context of instrumentation component, it is beneficial to know if an outbound call was traced by the same vendor's agent. This might be useful to differently categorize a outbound span, or to hint to the customer that a service is instrumented, but now with our product, and this causes data gaps.
  Let me know if this is insightful enough

[yurishkuro]

Seems like this use case would be addressed if you simply send tracestate header in the response, in addition to traceresponse header. We haven't explicitly considered tracestate for response use cases, but neither is it forbidden. It does not require changes to the formats of either headers.

[basti1302]

How would sending tracestate as a response header be different from using any arbitrary proprietary response header? I think the request is to add explicit spec support for the described use case.

The qestion is, do the described use cases warrant adding something like this as a new specification feature.

I am tentatively leaning toward a "no". The first use case in particular does not involve a scenario that needs to work across vendors, but is always vendor specific by nature (assuming I am understanding it correctly).

[yurishkuro]

How would sending tracestate as a response header be different from using any arbitrary proprietary response header?

I tend to agree with that. The overall use case has a tight coupling in functionality between the client and the server. Nothing is blocking this use case today, and the benefits of standardization are not very unclear, because all the benefits listed by the OP can only materialize iff there is the same vendor on both sides of the call.