add the option to enable server reflection on otlp grpc receiver

[tvaintrob]

Describe the solution you'd like
a configuration to enable server reflection on the grpc otlp receiver something like the following:

receivers:
  otlp:
    protocols:
      grpc:
        enable_reflection: true

Describe alternatives you've considered
thought about adding a new receiver plugin but seems like the better solution is to add the functionality to the default one

id be happy to implement this one myself and submit a PR

[tigrannajaryan]

Please clarify the purpose of this feature. What does server reflection do?

[jpkrohling]

The biggest advantage is listing the resources a server provides. It allows a tool like grpccurl to be more user-friendly. We'd likely not have this enabled in production, but I can see how this can help debug connectivity and configuration issues.

[kvc0]

I'm trying to write a tool that sends messages directly to opentelemetry collector and I receive this when sending messages via your proto service definition:

(logged by my client - Channel established, request made it to otel collector, this is the response from otel collector)

{ code: Unimplemented, message: "unknown service opentelemetry.proto.metrics_service.MetricsService", metadata: MetadataMap { headers: {"content-type": "application/grpc"} }, source: None }

The very next thing I did to understand what the collector is looking for was to reach for grpcurl's list verb.

➜  ~ grpcurl -plaintext localhost:4317 list                        
Failed to list services: server does not support the reflection API

I still do not know what's wrong.

Here is how I'm running otel:

docker run -p 4317:4317 --name otel --rm otel/opentelemetry-collector

Not supporting reflection at all is quite hostile to those integrating with the collector. I actually thought the missing reflection was a bug!

[AlexDCraig]

Why is this not supported? Would love to be able to grpcurl this thing without it being a huge pain

[brandtkilian]

If that can be of any interest as a workaround, I am using grpcui, then I cloned opentelemetry-proto repository and I am using something along:

grpcui -plaintext -import-path /path/to/opentelemetry-proto/ -proto /path/to/opentelemetry-proto/opentelemetry/proto/collector/metrics/v1/metrics_service.proto 127.0.0.1:{your_otlp_grpc_port}

Then I can craft my export metrics test queries from a web ui.

As a side note, the -plaintext and -proto options of grpcui are really similar to the grpcurl ones so you might be able to replicate that with grpcurl easily.

reflection would be nice to have tho...

[K-MTG]

@brandtkilian, would you be able to share the example export metrics test queries?

I'm getting a undefined is not an object (evaluating 'schema.requestType')

[Sispheor]

For the other Googlers who will passe around this issue, here is an example of metric export using grpcurl (using the provided metric example)

You need to download proto repo and then:

cat payload.json | \
grpcurl \
    --plaintext \
    -d @ \
    -proto protos/opentelemetry/proto/collector/metrics/v1/metrics_service.proto \
    -import-path protos\
    -vv \
    <ip_or_host>:4317 \
    opentelemetry.proto.collector.metrics.v1.MetricsService/Export

Output example:

Resolved method descriptor:
// For performance reasons, it is recommended to keep this RPC
// alive for the entire life of the application.
rpc Export ( .opentelemetry.proto.collector.metrics.v1.ExportMetricsServiceRequest ) returns ( .opentelemetry.proto.collector.metrics.v1.ExportMetricsServiceResponse );

Request metadata to send:
(empty)

Response headers received:
content-type: application/grpc

Estimated response size: 2 bytes

Response contents:
{
  "partialSuccess": {}
}

Response trailers received:
(empty)
Sent 1 request and received 1 response
Timing Data: 10.672835ms
  Dial: 1.240466ms
    BlockingDial: 1.229131ms
  InvokeRPC: 2.54183ms