Closed hu6360567 closed 1 year ago
The following test passes in both java 8 and java 17 environments, indicating that in both cases, the scheme is required:
System.out.println(System.getProperty("java.version"));
assertThatThrownBy(() -> OtlpGrpcSpanExporter.builder()
.setEndpoint("127.0.0.1:4317"))
.isInstanceOf(IllegalArgumentException.class);
This is aligned with the specification, which for gRPC endpoints says:
Target to which the exporter is going to send spans or metrics. The endpoint SHOULD accept any form allowed by the underlying gRPC client implementation. Additionally, the endpoint MUST accept a URL with a scheme of either http or https. A scheme of https indicates a secure connection and takes precedence over the insecure configuration setting. A scheme of http indicates an insecure connection and takes precedence over the insecure configuration setting. If the gRPC client implementation does not support an endpoint with a scheme of http or https then the endpoint SHOULD be transformed to the most sensible format for that implementation. Default: http://localhost:4317 [1]
We have our own gRPC client implementation which requires scheme to be included, so we're aligned with the spec.
The following test passes in both java 8 and java 17 environments, indicating that in both cases, the scheme is required:
System.out.println(System.getProperty("java.version")); assertThatThrownBy(() -> OtlpGrpcSpanExporter.builder() .setEndpoint("127.0.0.1:4317")) .isInstanceOf(IllegalArgumentException.class);
This is aligned with the specification, which for gRPC endpoints says:
Target to which the exporter is going to send spans or metrics. The endpoint SHOULD accept any form allowed by the underlying gRPC client implementation. Additionally, the endpoint MUST accept a URL with a scheme of either http or https. A scheme of https indicates a secure connection and takes precedence over the insecure configuration setting. A scheme of http indicates an insecure connection and takes precedence over the insecure configuration setting. If the gRPC client implementation does not support an endpoint with a scheme of http or https then the endpoint SHOULD be transformed to the most sensible format for that implementation. Default: http://localhost:4317 [1]
We have our own gRPC client implementation which requires scheme to be included, so we're aligned with the spec.
According to the specification, if use the environment variable to set a grpc protocol endpoint, scheme should not be included.
- gRPC:
export OTEL_EXPORTER_OTLP_LOGS_ENDPOINT="my-api-endpoint:443"
- HTTP:
export OTEL_EXPORTER_OTLP_LOGS_ENDPOINT="http://my-api-endpoint/v1/metrics"
What makes it a trouble is, setting this environment variable with scheme whould fail in python auto-instrument, which makes mess configuration in our system with python/java applications.
According to the specification, if use the environment variable to set a grpc protocol endpoint, scheme should not be included.
That's not correct. SDKs are required to accept endpoints with a scheme included (and infer whether TLS is enabled / disabled based on the scheme), but may also accept endpoints without a scheme. See this PR for more context: https://github.com/open-telemetry/opentelemetry-specification/pull/1729
So java could change its behavior to accept endpoints with no scheme. But doing so would open questions about whether TLS is enabled / disabled. We could support the OTEL_EXPORTER_OTLP_INSECURE
variable, but what if OTEL_EXPORTER_OTLP_INSECURE
is included and the endpoint includes a conflicting scheme?
If python fails when scheme is included in the endpoint, then its not spec compliant and should be fixed:
the endpoint MUST accept a URL with a scheme of either http or https.
For SDK/API level, scheme should be included for sure, as the specificiation defines.
But for auto-instument configuration, as you point out the OTEL_EXPORTER_OTLP_INSECURE
is used to indicate whether TLS should be enabled.
So the workflow should be:
If OTEL_EXPORTER_OTLP_TRACES_ENDPOINT
includes the scheme, OTEL_EXPORTER_OTLP_INSECURE
should be ignored with a warning, otherwise, full url with scheme should be filled according to the OTEL_EXPORTER_OTLP_INSECURE
value.
If the endpoint vairable always comes with the scheme, then what's the use of OTEL_EXPORTER_OTLP_INSECURE
for?
Anyway, I'm fine with endpoint format, as long as the value can be accepted consistently accross the ecosystem. As https://github.com/open-telemetry/opentelemetry.io/pull/2863 has been made, I'll keep on the progress.
Seems the python auto-instrument has conflict with our application. It can accept the endpoint with scheme. I'll inspect the problem later.
Describe the bug set OTEL_EXPORTER_OTLP_TRACES_ENDPOINT envrionment varaiable without http causes java agent fail to start on java8
Steps to reproduce Use java8 to launch with agent as below
The output as below
What did you expect to see? The "OTEL_EXPORTER_OTLP_TRACES_ENDPOINT" environment variable needs to be set with "http://127.0.0.1:4317" to work as expect on Java 8. Following https://opentelemetry.io/docs/concepts/sdk-configuration/otlp-exporter-configuration/#otel_exporter_otlp_traces_endpoint, it should not start with http if the protocol is grpc, which works fine in Java 17.
What did you see instead? A clear and concise description of what you saw instead.
What version and what artifacts are you using? Artifacts: (e.g.,
opentelemetry-api
,opentelemetry-sdk
, which exporters, etc) Version: (e.g.,v0.4.0
,1eb551b
, etc) How did you reference these artifacts? (excerpt from yourbuild.gradle
,pom.xml
, etc)Environment Compiler: OpenJDK 1.8.0_372 OS: MacOS 12.6.6
Additional context Add any other context about the problem here.