Support schemes other than http and https (specifically unix://) in OTEL_EXPORTER_OTLP_ENDPOINT or add another variable that allows this scheme.

[dvanderleij]

Its currently possible to configure otel SDKs with OTEL_EXPORTER_OTLP_ENDPOINT. This is convenient as the otel sdks for separate languages are all configured using the same variable. However it is not possible to specify protocols other than http or https probably since http transport uses the same variable name. Our use case is that we use a daemon otel collector that listens on a unix socket where other processes written in a variety of languages on the same host send otlp grpc messages to the unix socket. To achieve this we have to therefore write boilerplate in every separate language to connect to this unix socket as we can't use the env variable for all of them.

It would reduce maintenance to use the same variable that is automatically picked up in different languages.
Perhaps adding a variable OTEL_EXPORTER_OTLP_GRPC_ENDPOINT which supports all the protocols supported by grpc described here: https://github.com/grpc/grpc/blob/master/doc/naming.md would be appropriate.

[dmathieu]

Note that this issue rose up in the Collector a few months ago.
open-telemetry/opentelemetry-collector#11941

This brought us to ensure the Go SDK does support unix endpoint (it already did, it just wasn't tested).
open-telemetry/opentelemetry-go#6130

So while I agree with you this should be supported, some SDKs already so. What we seem to be lacking is the specification to say each of them should.

[pichlermarc]

We also support this in the OTel JS gRPC exporters.
Adding it to the spec would be a nice addition. 🙂

[danielgblanco]

Looking at https://github.com/open-telemetry/opentelemetry-specification/blob/main/specification/protocol/exporter.md

The option SHOULD accept any form allowed by the underlying gRPC client implementation. Additionally, the option MUST accept a URL with a scheme of either http or https

This implies that http and https are required, but any other supported schemes are optional, as long as they're supported by the underlying gRPC client implementation. Does this solve this issue? Or is the proposal to have other schemes as required for all SDKs?

[dvanderleij]

I suppose it's up to the implementation then. I'll have a look in the golang SDK. The golang SDK currently does not resolve a unix address from the environment to correctly, resulting in a dns protocol instead.

However I understand this is unrelated to the current spec. To solve this in a backwards compatible way with the spec, perhaps a new more GRPC specific variable could be added. E.g. OTEL_EXPORTER_OTLP_GRPC_ENDPOINT where sdks must adhere to supporting these transports supported by GRPC (like unix).