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
What would you think about creating a web browser plugin that instruments XHRs?
Here are a couple things we did in OpenCensus Web related to that:
The XHR tracing was related to the user interaction tracing in the sense that XHR spans would be children of automatic user-interaction traces. This was nice because there would be a root span that would be something like Save.click and there would be child spans of the HTTP requests it triggered. We could handle this in OpenTelemetry by just making the XHR spans be children of the current span or otherwise root spans (maybe that's just the default thing we do anyway!).
We actually combined data from both monkey-patching XMLHttpRequest, and from using the Resource Timing API, see this doc, and code links (perf-resource-timing-selector.ts and xhr-interceptor.ts). This enabled richer spans that included network-related time events similar to the initial page load resource spans, but also allowed information about the eventual HTTP status code.
It's important to propagate trace headers to the server, but we need a way for the user to configure this on a per-domain basis, because it may have implicates around CORS to send the extra header (hopefully that will eventually change once traceparent is in the browser spec, but that's a way off). In OpenCensus Web, we had a regex of origins that should be matched to end trace headers.
What would you think about creating a web browser plugin that instruments XHRs?
Here are a couple things we did in OpenCensus Web related to that:
Save.click
and there would be child spans of the HTTP requests it triggered. We could handle this in OpenTelemetry by just making the XHR spans be children of the current span or otherwise root spans (maybe that's just the default thing we do anyway!).XMLHttpRequest
, and from using the Resource Timing API, see this doc, and code links (perf-resource-timing-selector.ts and xhr-interceptor.ts). This enabled richer spans that included network-related time events similar to the initial page load resource spans, but also allowed information about the eventual HTTP status code.traceparent
is in the browser spec, but that's a way off). In OpenCensus Web, we had a regex of origins that should be matched to end trace headers.@obecny WDYT?
The text was updated successfully, but these errors were encountered: