Consider defaulting OTLP exporter to HTTP

[pjanotti]

(Edit 03/01/22: per discussion below, tracking future exporter change via #2959)

As per latest spec HTTP is preferred over gRPC, see https://github.com/open-telemetry/opentelemetry-specification/blob/ce50e4634efcba8da445cc23523243cb893905cb/specification/protocol/exporter.md?plain=1#L111-L114 and respective PR discussion: open-telemetry/opentelemetry-specification#1969

There is an exception for already released SDKs but I would like to consider a change for the following reasons:

1. Anecdata: most usage of OTLP is with HTTP (easier to get correct configuration for load balancers, proxies, etc)
2. For .NET auto-instrumentation the dependency challenges of earlier versions are harder to deal with, see OTLP Exported as default for .NET (Core) opentelemetry-dotnet-instrumentation#343

cc @open-telemetry/dotnet-instrumentation-approvers @open-telemetry/dotnet-approvers

[alanwest]

I agree with the benefits of defaulting to HTTP over gRPC.

I just opened #2857. OTLP/HTTP should default to use port 4318 not 4317. The one concern I might have with changing the default is if there's a potential for this causing a breaking change for folks. I'm imagining a user who has explicitly configured their environment allowing 4317 but not 4318... though maybe this would be an unlikely problem since folks are most likely overriding the default endpoint configuration.

[CodeBlanch]

I can confirm that if the SDK changed the default it would certainly break deploys in the environments under my purview. We're setting the endpoint but not specifying the protocol. When we set everything up the protocol setting didn't even exist 🤣 I think we may have to live with this.

[pjanotti]

@CodeBlanch just to be 100% certain here: you are saying to keep the current default to avoid breaking the deployments like the ones that you work with. Is that correct?

[CodeBlanch]

@pjanotti Yes I would vote to keep the current default. I just went and double-checked in the 1.1.0 version of OpenTelemetry.Exporter.OpenTelemetryProtocol we didn't have a protocol option because it only supported gRPC. So if 1.2.0 (or whatever 1.* version) is released and suddenly switches to HTTP by default I think that would be breaking. We could do in 2.* version?

[reyang]

+1

[reyang]

Maybe when metrics and logs are both covered by the OTLP exporter, we can ship v2.0 of OpenTelemetry.Exporter.OpenTelemetryProtocol. I think bumping major version of an exporter won't be a big concern to the users (while bumping the major version of the SDK is going to be a big concern).

[pjanotti]

Sorry for the delay on getting back to this - pto :)

Thanks for confirming @CodeBlanch.

@reyang the idea of a version 2 of the exporter is good. Should I create an issue to track that?

[reyang]

@pjanotti 👍

[pjanotti]

Linking #2959 for completeness.