Server-timing names

[SergeyKanzhelev]

Following up on #560

The possible alternative for naming would be:

instead of:

server-timing: trace;tid=0af7651916cd43dd8448eb211c80319c,cid=b7ad6b7169203331

use

server-timing: span;id=b7ad6b7169203331,tid=0af7651916cd43dd8448eb211c80319c

Benefits:

1. It is already clear that the information about "server" - meaning we should not even introduce the term "child".
2. Opens a door to add span name and duration to the same list and make it into a metric
3. Does not require introducing naming distributed-trace or similar to clarify what trace means
4. Makes it more natural to understand which one is "ID" without understanding what the difference between "c" and "t"
5. Shortens 2 characters

[SergeyKanzhelev]

@dyladan

[kalyanaj]

@SergeyKanzhelev : I like your proposal because it reframes it from the point of view of the server operation: its id, which trace it is part of, (optional) its sampling info, and its name/duration (in the future). So overall, I feel this fits better with having this info in server-timing.

CC: @dyladan @basti1302 @jcopi what do you think?

[kalyanaj]

Also, in the context of this discussion, should we think about its implications for trace state response as well? For example, is that a separate metric or can that information be folded into the above, etc.?

[SergeyKanzhelev]

Also, in the context of this discussion, should we think about its implications for trace state response as well? For example, is that a separate metric or can that information be folded into the above, etc.?

good question. I would think trace may be a better name for tracestate if we will introduce it

[basti1302]

I feel there is a tradeoff between:
(a) choosing metric names that makes the most sense for what the metric represents and
(b) names that make it easy to mentally connect the response Server-Time metrics with the corresponding request headers (and thus might make the spec as a whole easier to understand intuitively).

I agree that the metric name span makes a lot of sense, if you just look at the new Server-Timing metric in isolation. On the other hand, calling that metric any one of traceparent, tracechild or traceresponse would make it very obvious that this is basically the same thing as the request header traceparent, just going into the other direction.

Same goes for the equivalent of the request header tracestate. Choosing a completely new name (like trace) might make sense in isolation, but I feel there is also value in reusing the name tracestate for a Server-Time metric, just for the sake of making it obvious that this is the same concept as the request header of the same name.

For some reason I cannot put my finger on, I feel a bit more strongly about this for tracestate than for traceparent.

How do you folks feel about introducing the new name span for the traceparent-equivalent metric while keeping tracestate as the name for tracestate-equivalent metric?

[yurishkuro]

+1 to reuse the names