Description
Is your feature request related to a problem? Please describe.
Currently, transport, configuration (options and environment variables) as well as serialization code are all mixed together in the OTLP exporters, making it increasingly hard to modify and test them. Further, a significant amount of logic and tests are duplicated across multiple OTLP exporters.
Describe the solution you'd like
This issue tracks refactoring the OTLP exporters so that the transport code is a pluggable component that takes a subset of the configuration passed to the exporter. This way we
- can test the behavior of the transport layer individually of the rest of the exporter
- in the future - may also allow users to pass their hand-rolled transport to the exporter
- This is useful if the transport implementations provided by this repo are insufficient. One example would be providing polyfills for features that are not supported on browsers that have reached their EOL.
This transport component should not directly access any environment variables mixed in with other code as is currently done in the exporter. Determining its configuration should happen before instantiation; a finished configuration object should be passed to it.
Out of scope for this issue:
- Refactoring configuration code beyond what is necessary for the pluggable transport layer
- Refactoring serialization code beyond what is necessary for the pluggable transport layer
- Refactoring non-OTLP exporters to use this pluggable transport layer
Additional context
- The original proposal Create the transport layer and refactor exporters so that they can be used both in node and web #422 was written with Jaeger and Zipkin exporters in mind, but the Jaeger exporter has been deprecated and won't receive any feature updates. We may introduce the same pluggable transport to the Zipkin exporter in a follow-up.
- feat: introduce internal exporter http client #3577 attempted to introduce an internal http client for exporters but was closed before reaching the review state