feat(otlp-exporter-base): add custom fetch option to OTLP HTTP exporters

[zakcutner]

Which problem is this PR solving?

I'm using OpenTelemetry JS in Cloudflare Workers and I need to send telemetry to a collector running in a private network via Workers VPC. Workers VPC provides a custom fetch function that can route requests through private networks, but there was no way to easily pass this to the OTLP exporters.

Before this change, the only way to achieve this was to create a custom version FetchTransport, which would require duplicating much of its implementation, or to monkey patch globalThis.fetch.

Specifying a custom fetch function could also be useful for other scenarios like adding request/response interceptors, using fetch polyfills, or testing with mocks.

Short description of the changes

Adds a fetch configuration option to OTLP HTTP exporters, allowing users to provide a custom fetch implementation instead of using globalThis.fetch.

Type of change

• New feature (non-breaking change which adds functionality)
• This change requires a documentation update

How Has This Been Tested?

• Unit tests for configuration merging (mergeOtlpHttpConfigurationWithDefaults)
• Unit tests for FetchTransport using custom fetch
• Unit tests for legacy configuration converters (browser and Node.js)
• Ran npm test (144 passing)
• Ran npm run test:browser (85 passing)

Checklist:

• Followed the style guidelines of this project
• Unit tests have been added
• Documentation has been updated

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: zakcutner / name: Zak Cutner (db5111b)

[zakcutner]

@blumamir @hectorhdzg @JacksonWeber @martinkuba @maryliag @raphael-theriault-swi @svetlanabrennan Would it be possible for a review of these changes, when you get a moment? I'm also happy to open an issue for discussion or change the approach if you would prefer. Sorry for the pings by the way, the contributing guide included that I should @ the approvers on my PR.

[pichlermarc]

@zakcutner - my original idea was to provide an interface for people to pass their own transports to the exporters, because different transport implementations are so widely requested.

My idea was that people would be able to do something like this, but I ran out of time to work on it:

const exporter = createOtlpExporter({
  serializer: ProtobufTraceSerializer,
  transport: createMyCustomFetchTransport() // returns a custom IExporterTransport impl
});

the underlying implementation is already somewhat setup for such a thing, but requires a bit more boilerplate

import { createOtlpNetworkExportDelegate } from '@opentelemetry/otlp-exporter-base';
import { ProtobufTraceSerializer } from `@opentelemetry/otlp-transformer`;

const exporter: SpanExporter = new createOtlpExportDelegate({
  options: { /** provide all required options accoding to type**/ },
  serializer: ProtobufTraceSerializer, // or JsonTraceSerializer
  transport: createMyCustomFetchTransport() /** implement this yourself, a wrapper around your custom fetch, make sure to set the content-type header to what you're sending: `application/x-protobuf` or `application/json` **/
}); /* delegate happens to match the SpanExporter type, this won't work for metrics today though, because some methods are missing */

I suppose this is what you mean by

the only way to achieve this was to create a custom version FetchTransport, which would require duplicating much of its implementation

IMO this is a good enough workaround for now. Once we drop support for older Node.js versions (around July 2026), we can also finally use fetch in Node.js. Then, all HTTP-based exporters (json/protobuf) will use fetch as a transport regardless of runtime. Introducing that feature then will not result in it being a no-op on Node.js (as is the case in the proposal of this PR) and will therefore be a lot easier to justify adding.

[pichlermarc]

So my recommendation for this feature is:

• decline for now
• use workaround for the time being
• drop node:http based exporter transport in July 2026
• add this feature as proposed in this PR to the now streamlined interface where it also works for Node.js
• feature is released alongside SDK 3.0, everybody can use it