Expose functions for registering gRPC(-gateway) services

[axw]

Is your feature request related to a problem? Please describe.

I develop Elastic APM Server, for which there is an exporter in opentelemetry-collector-contrib.

We would like to support receiving OTLP directly in Elastic APM Server, cutting out the need to translate to our own protocol. For basic use cases this would enable users to send telemetry data directly to Elastic APM Server, reserving opentelemetry-collector for situations where additional preprocessing is needed, or for sending to multiple backends.

Furthermore, we would like to receive OTLP data on the same port as used by Elastic APM agents, which would necessitate using a shared gRPC server and grpc-gateway mux. This means we cannot use the existing otlpreceiver API, which owns the gRPC/HTTP servers/ports. We would call the RegisterTraceServiceServer, RegisterTraceServiceHandlerServer functions directly, but they are hidden inside an internal package.

Describe the solution you'd like

Add exported functions to receiver/otlpreceiver:

// RegisterTraceReceiver registers the trace receiver with a gRPC server and/or grpc-gateway mux, if non-nil.
func RegisterTraceReceiver(context.Context, *trace.Receiver, *grpc.Server, *gatewayruntime.ServeMux) error

// RegisterMetricsReceiver registers the metrics receiver with a gRPC server and/or grpc-gateway mux, if non-nil.
func RegisterMetricsReceiver(context.Context, *metrics.Receiver, *grpc.Server, *gatewayruntime.ServeMux) error

// RegisterLogsReceiver registers the logs receiver with a gRPC server and/or grpc-gateway mux, if non-nil.
func RegisterLogsReceiver(context.Context, *logs.Receiver, *grpc.Server, *gatewayruntime.ServeMux) error

(I'm more than happy to send a PR to this effect, if deemed reasonable.)

Describe alternatives you've considered

• Move internal/data/protogen out of internal. This would expose too much about the internal details.
• Run opentelemetry-collector internally with ephemeral port(s), and reverse proxy. Too many moving parts for my liking.
• Vendor opentelemetry-collector in Elastic APM Server, and rewrite internal package paths to be accessible. I'm currently looking into this, but it's clearly not ideal.
• Don't reuse opentelemetry-collector at all, and instead generate independent code from https://github.com/open-telemetry/opentelemetry-proto. This would work, but means any code we develop cannot be reused in opentelemetry-collector.

[axw]

#2411 implements this as described. If there are no objections in principle, I'll open that up for review.

[tigrannajaryan]

It is not clear why you need to expose these functions. Are you implementing a receiver in the Collector?

If you are implementing an OTLP receiver in your codebase that is not the Collector then you should generate your own OTLP gRPC/Protobuf messages from https://github.com/open-telemetry/opentelemetry-proto/tree/main/opentelemetry/proto

[axw]

@tigrannajaryan no, not a receiver in the Collector. Rather. We would like to embed the Collector inside another existing program (apm-server). The goal is to add support for receiving OTLP directly in apm-server.

If you are implementing an OTLP receiver in your codebase that is not the Collector then you should generate your own OTLP gRPC/Protobuf messages from https://github.com/open-telemetry/opentelemetry-proto/tree/main/opentelemetry/proto

Yes, that is another option. We would prefer to reuse code if possible. If we generate independent code from the protobuf definitions, anything we develop around that cannot easily be reused in opentelemetry-collector. Maybe there's never anything to share back, but I thought the small amount of code involved in implementing this (#2411) would be worth keeping the possibility open.

[tigrannajaryan]

Making these functions exported increases our API surface and is not something we want to do, no matter how small the increase. We are constantly looking for ways to keep our public API small. So, unfortunately, the answer is no.

You may be able to use https://github.com/open-telemetry/opentelemetry-proto-go once it is ready.

I am going to close this, please feel free to reopen if you have additional arguments.

[axw]

No worries, thanks for the discussion. Is the intention to have the collector use opentelemetry-proto-go at some point? (If this is documented somewhere I'd be happy to read up - couldn't find any issues mentioning it.)