Link user interaction spans to most recent navigation

[bradfrosty]

Is your feature request related to a problem? Please describe

I would find it useful if user interaction spans were linked via the span options to the previous navigation span (including the document load). When a user interacts with the page, this would allow user interactions to be connected to the specific navigation on which the user interaction occurred. This added context would allow a better understanding of the user flow that we wish to observe.

Describe the solution you'd like to see

The previous navigation span (as created by the user interaction plugin) or the document load span (as created by the document load plugin) are linked into a user interaction span using the link SpanOption.

Describe alternatives you've considered

I've considered creating a span that runs the duration between navigations to capture this context. However, this has clear downsides since the page could be open for a long time.

Additional context

There is an open issue that this feature could partially address: #668.
However, it would only address resources loaded during user interactions. Any resources fetched outside the context of a click handler would not be linked. It also requires usage of the user interaction plugin.

I believe that it might also partially address open-telemetry/opentelemetry-js#610

[dyladan]

This would require changes in a couple of the instrumentations. First, you have to change the document load plugin to save the most recent navigation somewhere (probably context), then you would have to modify the user interaction plugin to read that context property and make use of it.

I think this is a good idea that is worth exploring. Do you think you have time to prototype something so we can discuss it further? This might be also something worth adding to the specification as it affects instrumentation for other types of UIs like android/ios apps.

[bradfrosty]

First, you have to change the document load plugin to save the most recent navigation somewhere (probably context)

Makes sense. I imagine this could be store in the root context? If we assume that navigation always occurs as a root span, I believe this would be possible. Even though the Document Load won't actually be the root span if the traceparent meta tag is set, we can still store the most recent client navigation in the root span.

Do you think you have time to prototype something so we can discuss it further?

Yup, I can try to put together a prototype 🔧
Happy to help with adding to the spec too after we discuss the initial prototype.

[github-actions]

This issue is stale because it has been open 60 days with no activity. Remove stale label or comment or this will be closed in 14 days.

[github-actions]

This issue was closed because it has been stale for 14 days with no activity.

[bradfrosty]

@dyladan can we keep this issue open?

[dyladan]

Yes of course

[Ancient-Dragon]

Hey it appears as though this has been implemented. Is there any way to turn this off? We poll our api on a single page (don't ask :D) and this has lead to building up some massive traces which isn't great

[Ancient-Dragon]

@dyladan, don't suppose you can help with the above?

[dyladan]

I don't think this has been implemented?

[Ancient-Dragon]

Hmm, we're getting traces like this:

which really slow down honeycomb

[dyladan]

what instrumentations are you using?

[Ancient-Dragon]

We're currently using the following instrumentation's:

    "@opentelemetry/instrumentation-fetch": "0.27.0",
    "@opentelemetry/instrumentation-user-interaction": "0.28.1",
    "@opentelemetry/instrumentation-xml-http-request": "0.27.0",

[bradfrosty]

@Ancient-Dragon this has not been implemented. This issue is suggesting to connect the DocumentLoad spans (from the document load instrumentation) with the Navigation spans (from the user interaction instrumentation) via OpenTelemetry Links.

This specification is for linking causally related spans that contain entirely different root spans. This is only applicable for SPAs, as MPAs will always generate a new document load span. I think page loads and subsequent client side navigations would be useful context for finding client side errors in SPAs that contain state.

It looks like you want to disable the network spans being generated after the page load. Your example is showing a Navigation span with nested XHR/Fetch spans. If you don't want those network spans recording your app's network waterfall within client side navigations, I would recommend programmatically disabling the XHR/Fetch instrumentation after the page load.

[Ancient-Dragon]

Ok thanks, I was unaware the the user interaction instrumentation was adding these navigations spans.

I was able to filter them out using the shouldPreventSpanCreation to filter them out based on the user clicking the link to that page, as I still want the spans / traces being generated for the http requests.

Sorry about the confusion.

[bradfrosty]

I think that's good feedback for the User Interaction Instrumentation. I agree, I think it would make sense to be able to disable client-side navigation spans via configuration.

I don't know the history of why those spans exist in that instrumentation in the first place, but I remember being surprised when I saw it generated by User Interaction since it's an undocumented feature. I feel like a more natural place is actually within DocumentLoad Instrumentation, but instead of calling it that it would be something like "Navigation Instrumentation".