W3C Trace Context propagation over Varlink

[utezduyar]

I would like to discuss whether it makes sense to extend the Varlink specification with a standard mechanism for propagating distributed tracing context.

The W3C Trace Context specification defines traceparent and tracestate for propagating tracing information across process, service, and machine boundaries. Having equivalent metadata on Varlink calls would allow them to participate in distributed traces without tying Varlink specifically to OpenTelemetry or any other tracing implementation.

Conceptually, a call could look something like:

{
    "method": "org.example.Service.Hello",
    "traceparent": "00-abf92f3577c34da6b3ce929d0e0e4736-00f067aa0ba902b7-01",
    "tracestate": "...",
    "parameters": {
        "par1": "val1"
    }
}

The exact representation would of course need discussion. Varlink’s existing vendor-extension mechanism could perhaps be used for experimentation, but if this is generally useful, it may make sense to define a standard protocol extension.

A client could attach its current trace context to a call. A server would extract it and, if it makes another Varlink call while handling the request, propagate the updated context. This would allow tracing a chain such as A -> Varlink B -> Varlink C, including across machines. Besides debugging call chains, this could be useful for monitoring RPC latency and errors.

One question is how this should interact with Varlink over HTTP. W3C already defines traceparent and tracestate HTTP headers. Should Varlink-over-HTTP use those headers exclusively, or should the context remain part of the Varlink message regardless of transport? The latter keeps Varlink tracing transport-independent, but could result in duplicate context at the HTTP and Varlink layers.

Would there be interest in defining a standard W3C Trace Context extension/binding for Varlink?