Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Add support for custom HTTP Transports for the otlphttp driver #1858

Open
arnogeurts-sqills opened this issue Apr 28, 2021 · 1 comment
Open
Labels
enhancement New feature or request

Comments

@arnogeurts-sqills
Copy link

arnogeurts-sqills commented Apr 28, 2021

Problem Statement

Currently the HTTP transport for the otlphttp driver is hard coded and cannot be customised. It would be nice if a custom transport could be passed to the driver via an Option.

I'm looking into building/PoCing a sidecar proxy for my applications to forward the OTLP data to the central collector. For performance considerations I want to use a unix socket for communication between my application and sidecar proxy. A custom HTTP Transport will allow me to do this. Moreover, it will allow optimisation of other parameters like MaxIdleConns, IdleConnTimeout, KeepAlive, etc. when needed.

Proposed Solution

Add an Option "WithHTTPTransport" which allows specifying a custom HTTP transport for the otlphttp driver.

@arnogeurts-sqills arnogeurts-sqills added the enhancement New feature or request label Apr 28, 2021
arnogeurts-sqills added a commit to sqills/opentelemetry-go that referenced this issue Apr 28, 2021
arnogeurts-sqills added a commit to sqills/opentelemetry-go that referenced this issue May 5, 2021
arnogeurts-sqills added a commit to sqills/opentelemetry-go that referenced this issue May 6, 2021
…or the otlphttp driver

+ added changelog entry
arnogeurts-sqills added a commit to sqills/opentelemetry-go that referenced this issue May 7, 2021
…or the otlphttp driver

+ fix markdown lint
@MadVikingGod
Copy link
Contributor

Could this be solved in a different manner?

One downside to this approach is that someone could use an already instrumented Transport creating a loop. That is currently not possible with our current configuration.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment