Add `otlp_grpc` alias for `otlp` exporter

[codeboten]

Component(s)

No response

Describe the issue you're reporting

The OTLP gRPC exporter is currently configured via otlp, which is different than the otlphttp exporter. This has led to end user confusion. I'm suggesting supporting the key otlp_grpc to configure this exporter to make the protocol explicit. This would align with the configuration schema:

https://github.com/open-telemetry/opentelemetry-configuration/blob/26f29f8119042c05fd3e08317c025030e79476d9/schema/logger_provider.json#L73-L84

An alternative would be to follow the same path as we did for the log exporter when it was renamed to debug exporter and eventually deprecated the otlp exporter.

Alternatively we could decide to not support this and document that this configuration will be different.

Tip

_{React with 👍 to help prioritize this issue. Please use comments to provide useful context, avoiding +1 or me too, to help us triage it. Learn more here.}

[codeboten]

Will add for context that the configuration working group moved to split the exporters in this PR open-telemetry/opentelemetry-configuration#146

[JamieDanielson]

The omission of grpc in the exporter name has resulted in confusion for many people over the years who did not realize they were using grpc instead of http. Although it may be challenging to make this kind of change since it is such a critical component and so many people already rely on it today, it is a necessary fix to reduce confusion and it is ideal to change for 1.0 - especially to keep things more aligned with the configuration spec.

[braydonk]

Is there a particular reason this cannot match what the otlpreceiver does? i.e. one receiver that contains configuration options for both protocols. I always was curious why otlphttpexporter is separate whereas http is built right into the otlpreceiver.

[codeboten]

@braydonk it looks like the original issue suggests it could have been part of the same exporter.

Note that the configuration working group ended up choosing to go away from specifying the protocol and sharing the name otlp for the exporter configuration

[andrzej-stencel]

I agree that the otlp exporter only supporting gRPC is confusing. I'd be fine with either having an otlp exporter that handles both HTTP and gRPC, or renaming otlp to otlp_grpc (and otlphttp to otlp_http). Slightly prefering the latter option for naming compatibility with the configuration schema.

If we decide to have a single otlp exporter for both gRPC and HTTP, I think HTTP should be the default, and that's a change that's much more significant than a rename.