Move fetch instrumentation from JS core to this repo

[martinkuba]

Sub-issue of #209

Move the @opentelemetry/instrumentation-fetch instrumentation from opentelemetry-js.

Related to open-telemetry/opentelemetry-js#6591 and open-telemetry/opentelemetry-js#6630

Decisions needed

• should it be part of the consolidated instrumentation package or separate? (the current package is widely used)
• where should it import utils from (can be separate issue)
• should we keep the span events for resource timing or make it work with the new resource timing instrumentation (can be separate issue)

[david-luna]

Here is my 2cts,

There are more than one topic in this issue and addressing them one at a time could be cumbersome IMO. Probably I'm being blunt here but I think we could have in this repository a new instrumentation that aligns to the conventions we have in this repo. We could keep the original instrumentation in the core repo for users not ready to migrate. It becomes their decision to use the former instrumentation or the one from the consolidated package.

should it be part of the consolidated instrumentation package or separate? (the current package is widely used)

my preference would be to have a new instrumentation here. Will give details about the implementation below)

where should it import utils from (can be separate issue)

the consolidated package already has a place for utils so it's natural to place them there.

should we keep the span events for resource timing or make it work with the new resource timing instrumentation (can be separate issue)

The current implementation is complex (ending spans after a timeout, maps of resources visited, etc.) just for the sake of having event in the Span. IMO events should be correlated logs.

Proposal XHR and fetch instrumentations in consolidated package

The proposal is not to move the instrumentations but to create a new one that aligns better with the principles we are following in this repository, specially the preference to model the telemetry with events. We will leverage log correlation to link the resource timings to the corresponding Span. With this approach we allow the users to decide which data model is better for them (Span with span events or Span + correlated logs)

The new fetch (and XHR) instrumentation will have a different approach which can be summarised:

• a single Span for the request will be created
• the Span will end as soon as the request finishes
• resource timings, which are reported after the end of the Span, will be collected as correlated logs

There are some questions to be resolved though:

• should instrumentation report a log per timing name (fetchStart, domainLookupStart, ...)?
• or a single event like the resource timing instrumentation? In that case we could think on a util to stash and lookup the right context for a given resource timing.
• should the logs have the timestamp of the collection or the time it happened according to the timing values?

I'll prepare a PR with a draft of this idea and link it here.

[martinkuba]

@david-luna I am in favor of this proposal.

should instrumentation report a log per timing name ... or a single event like the resource timing instrumentation?

If possible, I think the ideal implementation would be to make it work together with the resource timing instrumentation.

should the logs have the timestamp of the collection or the time it happened according to the timing values?

If each measurement was an individual record, then the timestamp would have to be the time the event occurred (time from origin converted to unix epoch). If we use the resource timing instrumentation, then each measurement is an attribute.

There is one caveat - In the current form of the instrumentation, timestamp and observedTimestamp are the same. If we switch to the unified HTTP conventions, then the event timestamp would have to be exactly when the event occurred.