Marking browser instrumentation packages stable

[scheler]

• [x] 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 https://github.com/open-telemetry/opentelemetry-js/issues/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 (https://github.com/open-telemetry/oteps/pull/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: https://github.com/open-telemetry/opentelemetry-js/issues/2410, https://github.com/open-telemetry/opentelemetry-js/issues/1989 or https://github.com/open-telemetry/opentelemetry-js/issues/2258)
• types export are still a problem for most of them (see https://github.com/open-telemetry/opentelemetry-js-contrib/issues/1120 or https://github.com/open-telemetry/opentelemetry-js-contrib/issues/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[bot]]

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[bot]]

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