-
Notifications
You must be signed in to change notification settings - Fork 2.7k
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
Provide OpenTelemetry OTLP/HTTP exporter #21535
Comments
/cc @radcortez |
Sounds good. Ideally we should align as much as possible with the OTel SDK and libraries. |
We will look into submitting a PR with our Quarkus extension and adapting the documentation. |
Thanks :) |
Adds an extension to provide on OTLP/HTTP exporter as described here https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/otlp.md#otlphttp and as implemented by the OpenTelemetry SDK. This as an alternative to the standard OTLP/gRPC exporter. Fixes quarkusio#21535
Adds an extension to provide on OTLP/HTTP exporter as described here https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/otlp.md#otlphttp and as implemented by the OpenTelemetry SDK. This as an alternative to the standard OTLP/gRPC exporter. Fixes quarkusio#21535
Adds an extension to provide on OTLP/HTTP exporter as described here https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/otlp.md#otlphttp and as implemented by the OpenTelemetry SDK. This as an alternative to the standard OTLP/gRPC exporter. Fixes quarkusio#21535
Adds an extension to provide on OTLP/HTTP exporter as described here https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/otlp.md#otlphttp and as implemented by the OpenTelemetry SDK. This as an alternative to the standard OTLP/gRPC exporter. Fixes quarkusio#21535
any update on this one? I am very interested to see this |
We want to implement #26444 first, which is underway. This will allow us to support the expected configuration for the OTLP http exporter. |
Guys, any updates on this? Are you still working on it? I've got realized that is such important to the library. |
The OTel Auto Config works took a bit longer than expected. It is mainly done, and it should be easier to support OTLP/HTTP with that, so yes, we are still working on this. Sorry for the delay. |
I think we have to. Until now, we always relied on the exporters provided by OTel, and we started the support with gRPC. We never added support for the HTTP one (hence the issue). The idea was to add it at some point. I haven't looked into the OTel HTTP exported, but most likely, the implementation also relies on OKHttp. |
Currently, yes. But the next release will also have a JDK HTTP Client implementation. |
Hum, in that case, we should use their implementation to save us some work. |
Yeah, that's certainly the easiest thing to do, but it probably does result in a loading a bunch of extra classes that otherwise would not be. But I do agree we should start with it - although it will require waiting for the next OTel release (which I doubt is a problem). |
Ok, my recommendation is to wait for the OTel implementation, but I won't stop you to provide our own implementation if you are bored :P |
😂. I'll have a look |
I see that we are on So my plan is that when the rest of my PRs get merged, I will first open a PR updating to the latest version (with any changes necessary) and then start working on this. |
Sure. |
I want to get #34545 in before working on this because is can cause more conflicts |
@brunobat it seems like the bump to |
Sure, don't worry. |
I'll look into this once #34851 is in |
I assume this ticket is about providing |
I am also a little confused by this. Isn't our exporter a gRPC exporter? |
There is not yet JSON serialisation for OTel's OTLP. PR still pending. |
Gotcha, however my confusion remains, as it seems to me that what we currently provide in our code is |
Yes, we only support gRPC, but OTel also supports HTTP (in OTLP format): |
Thanks. So just to be sure we are all on the same page:
Correct? |
Yes @geoand. It seems correct to me. |
Yes, not sure why the name is incorrect. I think we may want to keep the HTTP protobuf implementation with https://github.com/open-telemetry/oteps/blob/main/text/0099-otlp-http.md |
Thanks for the clarification folks |
I have an implementation that seems to work, but now I need to add an integration test module. |
I opened #35156 |
Description
The current
quarkus-opentelemetry-exporter-otlp
extension exports OpenTelemetry traces using the OTLP/gRPC protocol (using theOtlpGrpcSpanExporter
from theio.opentelemetry:opentelemetry-exporter-otlp-trace
module). The OpenTelemetry SDK however also includes aOtlpHttpSpanExporter
(in moduleio.opentelemetry:opentelemetry-exporter-otlp-http-trace
).We would like to be able to export our OpenTelemetry traces using the OTLP/HTTP transport (see also https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/otlp.md#otlphttp).
Implementation ideas
I think the most straight-forward solution would be to provide a new extension with a config namespace of
quarkus.opentelemetry.tracer.exporter.otlp-http
(in contrast to the currentquarkus.opentelemetry.tracer.exporter.otlp
which would pertain to the OTLP/gRPC exporter only). The config keys would basically be exactly the same, as the OTLP/HTTP exporter builder exposes the same configuration options.The user would then have choice of either adding the
quarkus-opentelemetry-exporter-otlp
or thequarkus-opentelemetry-exporter-otlp-http
extension.The text was updated successfully, but these errors were encountered: