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 otlp http exporters #4068

Merged
merged 2 commits into from
Sep 10, 2021
Merged

Add otlp http exporters #4068

merged 2 commits into from
Sep 10, 2021

Conversation

trask
Copy link
Member

@trask trask commented Sep 8, 2021

So that OTEL_EXPERIMENTAL_EXPORTER_OTLP_PROTOCOL=http/protobuf will work once we pull in Java SDK 1.6.0 which introduces autoconfigure support for this open-telemetry/opentelemetry-java#3522

@anuraaga
Copy link
Contributor

anuraaga commented Sep 9, 2021

Oh btw I think we'll need to force the okhttp dependency to avoid pulling in the kotlin stdlib (assuming we didn't accidentally pull it in elsewhere again :P). Though with it EoL, it's too bad really, I think we may need to reconsider using okhttp @jkwatson @jack-berg . Kotlin stdlib is just too heavyweight for a telemetry exporter I think

@jkwatson
Copy link
Contributor

jkwatson commented Sep 9, 2021

Oh btw I think we'll need to force the okhttp dependency to avoid pulling in the kotlin stdlib (assuming we didn't accidentally pull it in elsewhere again :P). Though with it EoL, it's too bad really, I think we may need to reconsider using okhttp @jkwatson @jack-berg . Kotlin stdlib is just too heavyweight for a telemetry exporter I think

Which EOL are you referring to, exactly here?

@jkwatson
Copy link
Contributor

jkwatson commented Sep 9, 2021

Oh btw I think we'll need to force the okhttp dependency to avoid pulling in the kotlin stdlib (assuming we didn't accidentally pull it in elsewhere again :P). Though with it EoL, it's too bad really, I think we may need to reconsider using okhttp @jkwatson @jack-berg . Kotlin stdlib is just too heavyweight for a telemetry exporter I think

Which EOL are you referring to, exactly here?

oh, I get it. okhttp 3.x didn't depend on the kotlin stdlib, but has been eol'd. 4.x does depend on the kotlin stdlib, which is definitely some significant bloat.

@jkwatson
Copy link
Contributor

jkwatson commented Sep 9, 2021

Oh btw I think we'll need to force the okhttp dependency to avoid pulling in the kotlin stdlib (assuming we didn't accidentally pull it in elsewhere again :P). Though with it EoL, it's too bad really, I think we may need to reconsider using okhttp @jkwatson @jack-berg . Kotlin stdlib is just too heavyweight for a telemetry exporter I think

We should probably build an multi-version jar, and use the java11 httpclient if it's available. Maybe using HttpUrlConnection (ugh!) for java 8.

@jack-berg
Copy link
Member

Geez none of these options sound good 😅

@trask
Copy link
Member Author

trask commented Sep 10, 2021

I think we'll need to force the okhttp dependency to avoid pulling in the kotlin stdlib

thx for this 👍

going to merge this now that open-telemetry/opentelemetry-java#3590 is merged

@trask trask merged commit d5500d0 into open-telemetry:main Sep 10, 2021
@trask trask deleted the otlp-http branch September 10, 2021 17:59
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

5 participants