AutoConfigure SDK doesn't behave in the same way as the java agent regarding OTLP protocol

[gaeljw]

Describe the bug

For an application using the java agent, we can publish metrics using OTLP exporter with the following configurations:

OTEL_SERVICE_NAME="some-service-name"
OTEL_METRICS_EXPORTER=otlp
OTEL_EXPORTER_OTLP_ENDPOINT="https://prometheus.mycompany.net/api/v1/otlp" # OTLP Receiver in Prometheus
OTEL_TRACES_EXPORTER=none
OTEL_LOGS_EXPORTER=none

For another application, using the AutoConfigure SDK, we face the following error:

io.opentelemetry.sdk.autoconfigure.spi.ConfigurationException: OTLP endpoint must not have a path: /api/v1/otlp
    at io.opentelemetry.exporter.otlp.internal.OtlpConfigUtil.validateEndpoint(OtlpConfigUtil.java:375) ~[opentelemetry-exporter-otlp-1.42.1.jar:1.42.1]

It seems to assume gRPC by default, which doesn't allow a path. We have had to explicitly set OTEL_EXPORTER_OTLP_PROTOCOL=http/protobuf for it to work fine.

What did you expect to see?

I expected the same configuration to be needed if using the java agent or not.

What version and what artifacts are you using?
Artifacts: opentelemetry-api, opentelemetry-sdk-extension-autoconfigure, opentelemetry-exporter-otlp
Version: v1.42.1
How did you reference these artifacts? pom.xml with the Maven BOM

Environment
Compiler: 11
OS: CentOS Stream 8

[trask]

hi @gaeljw!

we agree it is inconvenient

TL;DR behind the situation:

we want to align with the recommended OpenTelemetry default protocol which is http/protobuf

we aligned to http/protobuf when we bumped the Java agent major version from 1.x to 2.x

we plan to align to http/protobuf in the Java SDK autoconfigure module when it adopts declarative (yaml-based) configuration

unfortunately we can't change the Java SDK autoconfigure module's default when it comes to env vars without bumping major version (which we aren't currently planning)

[gaeljw]

Thanks for the feedback @trask , that's helpful. 👍

(Feel free to close as it's not really an issue then. Or keep it open if you want to keep a trace for v2.x of the SDK.)