why googclient_traceparent, why not just traceparent

[naseemkullah]

nodejs-pubsub/src/telemetry-tracing.ts

Line 243 in c1bed9e

export const modernAttributeName = 'googclient_traceparent';

I noticed that the client sets + extracts trace context using googclient_traceparent instead of the standard traceparent. This makes it incompatible with vanilla OpenTelemetry context propagation, requiring manual extraction and re-injection.

• Is there a specific reason for this customization?
• Would it be possible to use the standard traceparent key, or at least provide an option to enable it?

This would improve interoperability with OpenTelemetry out of the box.

Thanks!

[hongalex]

Our current policy is that any attributes created by the client library must be preprended with goog to differentiate them from user provided attributes. These attributes are also reserved such that user-defined attributes starting with googclient are not allowed.

A lesser reason is that we want to avoid taking up attribute keys in the user space as that is technically a breaking change. For example, if some people were setting traceparent before. Of course, we could get around this by checking to make sure traceparent is empty before having the library inject this value, and/or to look into an option to enable traceparent.

Could you describe your desired use case a bit more? I'm guessing you have some process downstream from receiving a message that would be able to extract the Pub/Sub message if you're using pull? But in that case, you will still need to manually read from Pub/Sub attributes. Alternatively, is it that you're using push subscriptions?

[naseemkullah]

Hey, thanks for explaining!

Re: current process
The team may want to revisit this if they consider OpenTelemetry an industry standard and want to align with a more interoperable approach.

Agree with your solution to the lesser reason.

My use case is a real-world potpourri languages and instrumentation libraries, where the thing stitching spans together is the W3C Trace Context (traceparent/tracestate, without the googclient_ prefix.

The goal is to create a span anytime a subscriber attempts to handle and ack/nack a message - but I admit this isn't strictly tied to what key names are used for trace propagation. The key issue however, is referencing the publisher's span, which does follow W3C standards(traceparent/tracestate) —either by keeping it under the same trace or, preferably, using a span link (to avoid bloated traces in fan-out scenarios).

Anyway, I have a workaround—manual context extraction and span creation with span links—but this could be built into the client.

Proposal:

1. Add support for injecting/extracting traceparent/tracestate without the googclient_ prefix
2. Allow users to configure whether the extracted context is used to:
   a. create a new span in the same trace or
   b. to (extract span context from and) be added as a link to the automatically created subscriber span

[feywind]

Thanks for the suggestions! Our context propagation stuff is still up for improvement, for sure. The general idea for the support we've got now is that it's a mechanism to plumb trace IDs through Pub/Sub, between the client libraries. Interoperating with other pieces of the ecosystem seems like a good goal in general. For example, last I heard, there is a desire to be able to pass on the trace IDs through headers in push subscriptions, so it would just connect transparently.

Is the basic desire to be able to have more control over the tree of produced spans? Like being able to parent them under another span that's user-controlled?

[naseemkullah]

The basic desire is twofold:

1. Use standard W3C trace context: Have the client inject/extract the widely adopted W3C key names (traceparent/tracestate) instead of Google-specific ones (i.e., without the googclient_ prefix).

2. Gain more control over context extraction behaviour:
   a. Parent-child hierarchy: Continue the current approach where the message handling span is a child of the received message’s span context.
   b. Span links: Optionally, add the received message’s context as a span link to the message handling span. This is useful in high-fanout scenarios to prevent massive traces and, from what I gather, is the recommended approach for correlating producer and consumer spans.

[bizob2828]

I work at New Relic and we are finding we cannot properly propagate context from an upstream service(gcp pub/sub) because it's setting the traceparent as googclient_traceparent.

[jsumners-nr]

A lesser reason is that we want to avoid taking up attribute keys in the user space as that is technically a breaking change. For example, if some people were setting traceparent before. Of course, we could get around this by checking to make sure traceparent is empty before having the library inject this value, and/or to look into an option to enable traceparent.

If I am understanding this correctly, that's not how traceparent works. traceparent only describes the identifiers being used in the trace. It is tracestate that propagates system state/attributes between systems.

See https://www.w3.org/TR/trace-context

[feywind]

Is the trouble here that there are things that expect to be able to directly translate Pub/Sub messages into another form (e.g. push receipt to an https endpoint)? Or is the difficulty that you'd like for it to be easier to get at the context to work with the spans in your own code? Or something else?

What I'm getting at is that I'm not sure why it matters what the Pub/Sub attribute is called, as long as Pub/Sub libraries can find the attribute. Presumably, these attributes would need to be pulled out by Pub/Sub-specific code (ours, or the user's) rather than needing to conform to the W3C standards for https names.

(Sorry, not trying to argue the point, just sharing what our perspective was and trying to figure out if we can improve it while meeting all the goals.)