Future considerations

[cvazac]

At present, we have name, duration, and description. Based on discussion here and here, these are some of the named parameters that should be considered:
start / end
unit
sourceId / sourceName
sourceIndex
a mechanism to identify parallel versus serial operations
arbitrary data

[kbrock]

What is the preferred way to share non-duration based quantities?
The one that comes to mind is the number of queries.

Per [discussion], it sounded like the number would be stored in the description. But that seems like a bit of overloading.

pg=12.3; "101 queries"

or possibly

pg=12.3; "Postgres"; queries;101

Thanks all

[cvazac]

cc @kbrock
Based on the new syntax, I'd recommend either using description or duration. The only downside of using duration when it's not actually a time based value is that devtools (or analytics vendors) might try to visualize those values in the wrong way.

pg; duration=12.3

-or-

pg; description=12.3

[sroussey]

If you have ever tried providing a tracing graph over headers, you will know that it is not possible. There are limits to the number of headers before you will bork chrome, load balancing machines, security rules, proxies, etc.

About decade ago when I worked on Firebug there was a great plugin for it called FirePHP that took log information from a PHP backend and injected it into the browser's console. There were a few others, but they standardized the wire format to run over headers called Wildfire. Unbounded data transfer this way came with real life problems. Something might work locally, but not over the internet. Sometimes things would cause the browser to show an error with no reason (there was one, and the same issue can be seen on Chrome when an extension tries to read too big of batch of headers).

There were other tools I watched come and go, but most of the effective ones abandoned the transfer of data over the header and instead relied on a token for that request (using just one small header). In the background you request the data for that token. That is how Clockwork does it for example, and I think Christian did that with Insight in 2010. If you get really clever with the tokens, you can inject them into comments in SQL queries, and all sorts of fun. I would not be surprised if the APM SDKs did this (for NewRelic, DataDog, LightStep, etc), I just never looked under the hood.

Now I like tracing on the front end browser, and propagating opentracing data back there, but I think it will be a waste of effort to reinvent tracing data across http headers.

And number and size of headers has been builtin to every company firewall I have seen, with most of them dropping the connection.

[itsderek23]

If you have ever tried providing a tracing graph over headers, you will know that it is not possible. There are limits to the number of headers before you will bork chrome, load balancing machines, security rules, proxies, etc.

Agreed. Scout does this with a local development tool, DevTrace, and it's a known issue.

I'd be worried about using a production tool that had the ability to send more than summary data (ex: exploding metrics with unique start / end times for a web request with a massive N+1 database query).

instead relied on a token for that request

👍

Now I like tracing on the front end browser, and propagating opentracing data back there

👍

One thought:

• An optional response header that references a URI w/sever-side tracing data (ie - https://acme.com/trace/TOKEN.json)
• The response renders a JSON array of OpenTracing spans, which are expected to align w/these conventions so db queries, HTTP calls, etc. can receive proper treatment.

Browser dev tools would then "just work" with any tracing system that can represent a transaction trace in OpenTracing format (your tool of choice wouldn't technically have to be built on OpenTracing...just have the ability to map a trace to the OpenTracing standard).

[bripkens]

For tracing headers, there is separate work happening in the working group over here:

https://github.com/w3c/distributed-tracing

They take various requirements such as vendor compatibility, typical trace ID formats etc. into account. I don't think that Server-Timing should be extended to support tracing specific data when there is a more specific working group for tracing.

[MrEcho]

One thing I haven't seen, or maybe have missed is: count
How many cache hits/misses did this request take, or how many sql queries happened?

[igrigorik]

I don't think that Server-Timing should be extended to support tracing specific data when there is a more specific working group for tracing.

Agree, with a caveat.. We obviously do need to define some minimum set of metrics and definitions for how they should be interpreted and exposed through PerformanceTimeline. However, we are not explicitly tackling the distributed tracing case: how to stitch together metrics across different services, definitions of what should live in there, and so on.

What I can see here is what @itsderek23 proposed: assuming the format is defined elsewhere, ST can be the mechanism by which you communicate the high level metrics and a pointer to the "full" trace.

[mohsen1]

I'm implementing Server Timing and I was deeply disappointed that it doesn't allow spans. All it needs is an offset value to be added to durations. Those times are actually a waterfall: