Clarification on OTEL_TRACES_EXPORTER for JS

[vmarchaud]

What are you trying to achieve?

I've started to implement the OTEL_TRACES_EXPORTER (spec) environment variable inside the JS SDK (original issue and my draft PR). Actually one of few last issue we need before making our SDK 1.0 RC.

From our understanding from the spec, the SDK should use the exported defined in OTEL_TRACES_EXPORTER but currently the SDK doesn't have each exported in its dependency so this can't work "out of the box", it requires users to install the exporter they want to use before hand.

We discussed this at the SIG and were septical to add exporters as SDK dependency, mostly because we try to keep our packages as light as possible and adding those exporters by default is quite heavy (within node, but even more relevant for browsers).
I checked in other SDK, for exemple Ruby, which just tries to use the exporter if its there but don't actually bring them as dependency (if i understood the code correctly, i've no experience with Ruby :/).

I tend to agree with this solution but i would have liked having a clarification at the spec level before implementing this.

Furthermore, in the browser context it's a bit harder to do this (using if installed) because we can't find dependency at runtime, so we would need to export them on the global scope window so the SDK is able to find them. Since dynamic configuration in browser make less sense than server-side, do we really need this ?

Thanks in advance !

[carlosalberto]

Hey @vmarchaud

OT_TRACES_EXPORTER is expected to be implemented bu auto-instrumentation engines, as they are the ones bundling many components (instrumentation, propagators, exporters, etc). We definitely need a clarification for this, so SDKs do not even try to implement this at the core level.

We discussed this at the SIG and were septical to add exporters as SDK dependency, mostly because we try to keep our packages as light as possible

This is the correct approach, i.e. we don't want to make the SDK a heavy piece.

[vmarchaud]

Thanks for the clarification @carlosalberto, i think the approach of the Ruby SDK is more user-friendly and possible in node so we'll implement it like this too.