Marking browser instrumentation packages stable

[scheler]

• This only affects the JavaScript OpenTelemetry library
• This may affect other libraries, but I would like to get opinions here first

What work is needed to consider these instrumentations stable?

1. opentelemetry-instrumentation
2. opentelemetry-instrumentation-fetch
3. opentelemetry-instrumentation-http
4. opentelemetry-instrumentation-document-load (from contrib repo)

Few things I can think of -

1. Agree on the structure of performance timing info. This is being discussed in [Discussion] Deprecating the addNetworkSpanEvents as this is not the correct approach for "events" #3174
2. Deprecate/remove component attribute from the spans as scope.name should be used instead
3. Do we need the span attribute http.user_agent given it will now be in the resource. See this.

[vmarchaud]

What work is needed to consider these instrumentations stable?

The main problem for me would be to consider opentelemetry-instrumentation stable which would means this API is stable for people to build their own instrumentations with, which for me is far from the case for the following reasons:

• instrumentation for node doesn't work with esm yet
• instrumentations depend on the not-GA metrics api
• no instrumentation yet use the metrics signal (even though its possible we might need tuning for it later on)
• there was an otep about standardizing the instrumentation api that went stale (Instrumentation API oteps#165) but that still define how we should do them (which is different than what we implemented AFAIK)
• there is still bugs with instrumentation (ex: Instrumentations are enabled twice on bootstrap #2410, InstrumentationBase calls init on partly initialized Instrumentations #1989 or InstrumentationAbstract#getConfig should return the type of the concrete instrumentation #2258)
• types export are still a problem for most of them (see standerize the types.ts file for instrumentations opentelemetry-js-contrib#1120 or @opentelemetry/instrumentation-graphql Version 0.27.1 Missing @types/graphql dependency opentelemetry-js-contrib#802)

And those are only the one i could come up from memory, i think there might be more

opentelemetry-instrumentation-http

Http instrumentation is for node and not the browser though

[vmarchaud]

Something i forgot but there also the meaning of an instrumentation stability, does that means the telemetry generated is stable and will not change ? Which sound complex to support right now imo

[scheler]

The ask is to mark the instrumentations stable only from a telemetry perspective, as defined here. Can you provide some info on why this sounds complex?

Do any of the items you listed above affect telemetry stability? I wonder if there is a way to mark/indicate the status of an instrumentation to be stable only from the perspective of telemetry.

[vmarchaud]

Can you provide some info on why this sounds complex?

I explained why opentelemetry-instrumentation can't become stable IMO, i don't have anything against document-load/xhr/fetch in themselves apart from the fact that it may be better to wait for the RUM SIG to finish its specification because i believe those instrumentations fall under their scope

[scheler]

Yes, I will take up the spec for document-load/xhr/fetch in RUM SIG. Thanks for the other info.

[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.