TraceExporter for fetch-only environment

[lacolaco]

NB: Before opening a feature request against this repo, consider whether the feature should/could be implemented in the other OpenTelemetry client libraries. If so, please open an issue on opentelemetry-specification first.

Is your feature request related to a problem? Please describe.

Currently, built-in TraceExporter implementation for browser depends on XMLHttpRequest or sendBeacon. These can't be adopted for fetch-only environments like WebWorker, ServiceWorker, or some edge workers (e.g. Cloudflare workers).

https://github.com/open-telemetry/opentelemetry-js/blob/main/experimental/packages/otlp-exporter-base/src/platform/browser/OTLPExporterBrowserBase.ts#L59

Once we accept fetch as an HTTP request sender, it can also be used in Node.js environments.

Describe the solution you'd like

• Option 1: Add "fetch mode" to OTLPExporterBrowserBase
• Option 2: Add a different class like OTLPExporterFetch

Describe alternatives you've considered

Additional context

• nodejs 18: Support native fetch  #3413 This issue also mentions fetch but only about instrumentation.

[david-luna]

Hi @lacolaco

I would like to understand better your use case. Do you want to instrument a WebWorker/ServiceWorker that runs on the Browser? If so, do you also want to instrument the UI thread and correlation between traces form the UI and the worker?

[lacolaco]

@david-luna I have two use cases; ServiceWorker on the browser and Cloudflare Workers. ServiceWorker needs to be able to propagate traces from UI threads to and from the backend server. This is equivalent to a proxy server from an overall perspective. The Cloudflare Worker is simply instrumentation as a back-end server.

[david-luna]

I'm not familiar with Cloudfare Workers but regarding Service Workers I think sending traces with fetch is not enough to have the proper instrumentation.

At least instrumentation of FetchEvent needs to be implemented so context is properly propagated when creating spans within the SW. Also I think there might be necesary to review core and web-sdk packages to make sure they are not using APIs not available in workers.

[lacolaco]

To clarify in case there is some misunderstanding, I am referring to the implementation of the exporter using the fetch api, not instrumentation for the fetch api.

[david-luna]

okay, so I guess you will do manual instrumentation of the incoming requests to the Service Worker to keep the trace context from the UI. I'll share today with the JavaScript SIG or maybe you can join and discuss this topic.

[lacolaco]

Thank you for the escalating!

[david-luna]

Checking on the agenda notes there is a discussion about this and also a PR. I'm adding the links here to complete the context.
Discussion: #3845
PR: #3542

[david-luna]

@lacolaco

We did discuss adding this feature and definitely is a feature we want in OTEL. PR #3542 it's quite complex but it will get simpler once #4542 lands into the main branch. So the plan would be:

• merge feat!: move serialization to @opentelemetry/otlp-transformer #4542
• update feat(otlp-exporter-base): Add fetch sender for ServiceWorker environment #3542 to use the new exporter API
• review and merge feat(otlp-exporter-base): Add fetch sender for ServiceWorker environment #3542
• wait for the next release

[lacolaco]

@david-luna Sounds nice! Thank you all for the great job!

[pichlermarc]

@lacolaco

We did discuss adding this feature and definitely is a feature we want in OTEL. PR #3542 it's quite complex but it will get simpler once #4542 lands into the main branch. So the plan would be:

* merge [feat!: move serialization to `@opentelemetry/otlp-transformer` #4542](https://github.com/open-telemetry/opentelemetry-js/pull/4542)

* update [feat(otlp-exporter-base): Add fetch sender for ServiceWorker environment #3542](https://github.com/open-telemetry/opentelemetry-js/pull/3542) to use the new exporter API

* review and merge [feat(otlp-exporter-base): Add fetch sender for ServiceWorker environment #3542](https://github.com/open-telemetry/opentelemetry-js/pull/3542)

* wait for the next release

Thank you @david-luna for summarizing this and bringing it up in the SIG.

To expand on what David said, there are a few more steps to be able to merge #3542 - we'll need to re-structure how we handle transports in the OTLP exporters (see #4116 for a more in-depth reasoning on why this is necessary). I have a draft for this at #4415, but applying that'll be a multi-step process as we try to avoid breaking users (the exporters are quite heavily used, so we try to tread lightly with changes there).

• the first of a series of changes was Lazy load grpc in OTEL grpc exporters #4151, introducing the first step to make transports pluggable
• now there's feat!: move serialization to @opentelemetry/otlp-transformer #4542 which moves some of the serialization code out to @opentelemtry/otlp-transformer so that transports become agnostic of what data they're sending.
• after that feat!: use serializers in browser exporters #4581 will do the same for browser exporters
• this then opens the way for more changes from feat(exporter-metrics-otlp-proto)!: rewrite exporter #4415 to be added in the repo, which will likely be 2 PRs again (Node.js HTTP transports then pulling out Browser Transports)

After all these changes adding fetch as a transport should be as easy as implementing one Transport interface and adding it to the existing code, which will also make it a component that we can test individually.