You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When an HTML page is loaded, it's nice to be able to see the overall page load as a span with a span for the initial HTML fetch as well. If the HTML fetch is slow, it's nice to see what on the server took a while (e.g. database calls, view render, etc.). This would be a feature request for the DocumentLoad plugin to make this work.
To get the server and client spans joined for the HTML fetch, we need the trace context to be shared between the client and server for an HTML load. Because the client in this case (the browser) does not send a trace header for the initial page load, we need an alternate mechanism.
What we can do is to have the server send back its trace ID, and make its server-side span for the initial page load have a random span ID as its parent. Then it passes back that parent ID to the browser client, which uses it as the span ID for its client-side fetch. That way we link the spans without needing to pass trace context as a header, which is not possible given the current browser spec for an initial navigation fetch.
Similarly, we will want to pass the trace sampling decision from the server to the client so that the trace sampling of both are aligned such that the user gets full end-to-end traces.
Here are two possibilities for how the server can send the trace ID back to the client:
We could encode the trace ID, span ID and sampling decision (basically the trace parent header) as an entry in the Server-Timing header. This could be useful in some contexts, but feels a little hackier than passing the trace header as a global variable.
I recommend we start with option 1, and then get to option 2 at some point in the future.
When an HTML page is loaded, it's nice to be able to see the overall page load as a span with a span for the initial HTML fetch as well. If the HTML fetch is slow, it's nice to see what on the server took a while (e.g. database calls, view render, etc.). This would be a feature request for the
DocumentLoad
plugin to make this work.To get the server and client spans joined for the HTML fetch, we need the trace context to be shared between the client and server for an HTML load. Because the client in this case (the browser) does not send a trace header for the initial page load, we need an alternate mechanism.
What we can do is to have the server send back its trace ID, and make its server-side span for the initial page load have a random span ID as its parent. Then it passes back that parent ID to the browser client, which uses it as the span ID for its client-side fetch. That way we link the spans without needing to pass trace context as a header, which is not possible given the current browser spec for an initial navigation fetch.
Similarly, we will want to pass the trace sampling decision from the server to the client so that the trace sampling of both are aligned such that the user gets full end-to-end traces.
Here are two possibilities for how the server can send the trace ID back to the client:
otTraceparent
or similar. We used this approach in OpenCensus Web, see its Send a trace parent and sampling decision from your server docs, and this code linkI recommend we start with option 1, and then get to option 2 at some point in the future.
cc/ @jahtalab
What do you think @obecny about this feature request?
The text was updated successfully, but these errors were encountered: