t2t2
commented
2 years ago Clarify of what you mean by scope, I assume InstrumentationScope since it's the only currently existing scope with attributes? (ignoring context-scoped attributes proposal as it's a proposal as frozen as ephemeral resource attributes)
I think you should expand the scope of the issue from just xhr & fetch instrumentations, having current page URL is also relevant for user interactions (which page was the clicked on thing on), instrumenting data query libraries (graphql/apollo, prisma, feathers, socket.io-client (websocket), any in-house api client), instrumenting components on the page (ChartWidget on X page), but also errors & logs could use what url the error happened on
so now duplication for each instrumentation, as they all have individual InstrumentationScope
Then there's more implementation question of how to make sure it's included - would it have to be implemented on base instrumentation so it's available for all instrumentations (what if they don't want it, what if none want it - dead code), or is it a concern of every instrumentation to include logic for it (duplicated code, a contrib/third party/in-house instrumentation just forgets when skimming through specs or documentation, any concerns about each instrumentation having it's own monitoring causing an issue like #3029)
As current browser page URL can be changed via history API or location.hash I did a few searches in both oteps and spec but couldn't find if InstrumentationScope also has similar "mutability" limitations as Resource?
If that is once again something that shouldn't be mutated (and js implementation-wise, direct mutations of attributes object could cause issues where data with old url + url changes on scope before exporting means that all old data would get new url, thing to consider for actual implementation), then I believe every time a span is wanted TracerProvider should be asked for a Tracer with currently valid attributes? That's some awful DX
So I think simplicity wise way better to actually push ephemeral resource attributes to reality as it'd be a common attribute for browser data. So imagine:
import {useSessionId, useDocumentLocation, ...} from '@otel/a-good-web-experience';
const resProvider = new ResourceProvider(); // But probably an implementation that provides an easy update API
useSessionId(resProvider); // sets current session id, new resource when new session
useDocumentLocation(resProvider); // sets current url, new resource when current URL has changed
useUserAgent(resProvider); // well, doesn't have to update but hey, possibility if you don't want to do this ingest side
useCurrentUser(resProvider); // currently logged in user, could change with logoutas they're all standalone functions they could be way more easily treeshaken (= removed from bundle) when the user doesn't want it. compared to config option or a class method which can't be
- What should we call this attribute?
I do feel like http.referrer should be reserved for HTTP server usage, especially when scope is extended to non-http instrumentations (currently user interaction instr uses http.url, and I'm just gonna ignore that).
Maybe better as general rum/- sig topic but this might be valid for each language/environment to use what's more standard for them, eg. browsers have window.location and document.location to provide current URL, so one of those would be an obvious oh that's what it means, and mobile apps I believe have concept of screens? so they could have an attribute with "screen" in it
scheler
dyladan
github-actions[bot]
olee
For the xml-http-request and fetch spans, we need an attribute to indicate the URL of the webpage initiating those calls. Since there can be many of such calls from a single webpage it makes sense to include this URL only once. In the absence of Ephemeral Resource Attributes, I suggest we add this as an attribute at the scope level. This means, the initiating page's URL is sent once for each batch of xhr and fetch spans exported.
What should we call this attribute? We could use
http.referreras the browsers send this URL in Referer header for these calls, however, it's conditionally present based on the referrer policy. We could still usehttp.referreras the semantic convention for this attribute but there's a possibility that this could be considered as the http request header even when it was not sent in the xhr/fetch call. If it's nothttp.referrer, what other semantic convention could we use for this attribute?