opentelemetry-exporter-otlp-proto-http-light: propose new exporter

[codeboten]

Description

I'm submitting this code as a proposal for an experimental new OTLP HTTP exporter in this repository. This is to address some concerns around memory footprint of the existing OTLP HTTP exporter. It was proposed in #4171 that an alternative implementation may be the way to go. I'm hoping the code in this PR is a step in that direction.

A few questions to reviewers:

1. is this approach something the community would like to support
2. please feel free to comment on the name chosen, i'm not in any way tied to it
3. should the version for this component be different than other beta components?
4. would it be preferred to have this component move to contrib?

I'm open to any changes the contributors would like to see here. I considered putting the implementation in the otlp exporter and making the version be configurable via env variables or feature gates, but it seemed that dropping the dependency on requests was preferable. Again, open to suggestions here.

Here's the performance comparison with the existing otlp exporter:

	No Exporter	OTLP HTTP	OTLP HTTP Light
Setup — heap (absolute)	6.91 MB	16.68 MB	10.34 MB
Setup — heap overhead	—	+9.77 MB	+3.42 MB
Setup — RSS overhead	—	+21.17 MB	+9.00 MB
Setup — load time	109.1 ms	292.7 ms	151.8 ms
Setup — modules loaded	126	456	216
Load — heap (absolute)	6.91 MB	19.41 MB	13.08 MB
Load — heap overhead	—	+12.50 MB	+6.17 MB
Load — RSS overhead	—	+29.60 MB	+14.16 MB
Load — time (1000 spans)	133.4 ms	322.0 ms	195.5 ms
Load — modules loaded	126	456	216

Please read the package's README.rst file for details about how this package differs from requests, mainly the support for custom sessions is not present. This is probably a solvable problem, but I didn't need it at this time.

Related to #4171

Note: I'll address the CI failures if the community is ok with this approach and moving it forward

Type of change

Please delete options that are not relevant.

• New feature (non-breaking change which adds functionality)

How Has This Been Tested?

Please describe the tests that you ran to verify your changes. Provide instructions so we can reproduce. Please also list any relevant details for your test configuration

• Added tests based on the existing otlp http package's tests

Does This PR Require a Contrib Repo Change?

• No.

Checklist:

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

[herin049]

Hi @codeboten, I'm actually currently working on generalizing the OTLP HTTP exporter already to allow users to pass in a pluggable HTTP transport (see #5164) This will allow us to implement transports for urllib, urllib3, requests, httpx, etc. I figure that this would be a more general solution, and would eliminate redundant packages, do you think it is still necessary to have a separate "light" exporter even once these changes are implemented?

[codeboten]

@herin049 that's really exciting! if the proposal in your PR is fully backwards compatible, then i would suspect my work here would not be necessary. my main concern around providing an alternative package here was to avoid backwards incompatible changes

[herin049]

@herin049 that's really exciting! if the proposal in your PR is fully backwards compatible, then i would suspect my work here would not be necessary. my main concern around providing an alternative package here was to avoid backwards incompatible changes

Yes, the changes in the latest draft PR I've created are intended to be fully backwards compatible. Please feel free to review/comment if you have any suggestions. Also, I think it would be useful to add your urllib implementation as another transport implementor in a follow-up PR if you are interested.

The only downside I can think of with following the generic transport implementation is that because we want to start using urllib3 as the default transport implementation, urllib3 will need to be marked as a required dependency, even if you only require urllib. This scenario can be avoided by doing a dependency-less installation or explicitly removing urllib3, but it isn't great.

Also, I'm curious which environments you are working in that require lower cold-start times? I'm assuming you are working with AWS Lambda, or some other server-less environment. Fortunately, if you're using AWS Lambda, urllib3 is already available with the Python runtime, so having it as a required dependency isn't an issue.