You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Since this change in Quarkus 3.9, which was supposed to resolve this issue, we're facing problems with the connectivity to our OpenTelemetry collectors. In our case, the Quarkus application that exports OpenTelemetry traces is running in the same cluster / same corporate network as our OpenTelemetry collectors. Therefore, a proxy should never be set.
Prior to the referenced change, it wasn't possible to specify a proxy for the OpenTelemetry exporters in Quarkus, so the proxy was never set.
After the referenced change, if a proxy is not explicitly specified for an exporter, the proxy is copied from the JDK system properties. We set the HTTP_PROXY, HTTPS_PROXY and NO_PROXY as JDK system properties, so that our components can properly communicate with components inside and outside of our corporate network. When setting the proxy for the OpenTelemetry exporters, Quarkus considers only the HTTP_PROXY and HTTPS_PROXY.
Expected behavior
The expected behavior is any of the two:
No proxy hosts can also be set for OpenTelemetry exporters in Quarkus. At the moment, only an HTTP/HTTPS proxy can be set.
An HTTP/HTTPS proxy for a given exporter can only be set explicitly. It should not default to the proxies from the JDK system props.
Actual behavior
If an HTTP/HTTPS proxy is set in the JDK system properties, it's automatically applied to the OpenTelemetry export endpoints, although the OpenTelemetry collector is reachable without proxy. A no_proxy system property is ignored.
How to Reproduce?
Steps to reproduce behavior:
Set "quarkus.otel.exporter.otlp.traces.endpoint" to an OpenTelemetry collector hosted in the same network as the Quarkus application. The Quarkus application should therefore reach the collector without a proxy.
Set the HTTP/HTTPS proxy JDK system properties (because the application uses proxies to communicate to components other than the OpenTelemetry receiver).
The connection to the OpenTelemetry collector fails because it goes through a proxy.
Output of uname -a or ver
Linux 5.15.0-1056-aws #61~20.04.1-Ubuntu SMP x86_64 GNU/Linux
Output of java -version
openjdk version "17.0.9.0.101" 2024-01-16 LTS
Quarkus version or git rev
3.9.0
Build tool (ie. output of mvnw --version or gradlew --version)
No response
Additional information
No response
The text was updated successfully, but these errors were encountered:
Describe the bug
Since this change in Quarkus 3.9, which was supposed to resolve this issue, we're facing problems with the connectivity to our OpenTelemetry collectors. In our case, the Quarkus application that exports OpenTelemetry traces is running in the same cluster / same corporate network as our OpenTelemetry collectors. Therefore, a proxy should never be set.
Prior to the referenced change, it wasn't possible to specify a proxy for the OpenTelemetry exporters in Quarkus, so the proxy was never set.
After the referenced change, if a proxy is not explicitly specified for an exporter, the proxy is copied from the JDK system properties. We set the HTTP_PROXY, HTTPS_PROXY and NO_PROXY as JDK system properties, so that our components can properly communicate with components inside and outside of our corporate network. When setting the proxy for the OpenTelemetry exporters, Quarkus considers only the HTTP_PROXY and HTTPS_PROXY.
Expected behavior
The expected behavior is any of the two:
Actual behavior
If an HTTP/HTTPS proxy is set in the JDK system properties, it's automatically applied to the OpenTelemetry export endpoints, although the OpenTelemetry collector is reachable without proxy. A no_proxy system property is ignored.
How to Reproduce?
Steps to reproduce behavior:
Output of
uname -a
orver
Linux 5.15.0-1056-aws #61~20.04.1-Ubuntu SMP x86_64 GNU/Linux
Output of
java -version
openjdk version "17.0.9.0.101" 2024-01-16 LTS
Quarkus version or git rev
3.9.0
Build tool (ie. output of
mvnw --version
orgradlew --version
)No response
Additional information
No response
The text was updated successfully, but these errors were encountered: