Feature Request: gRPC Unary Method Support

[Maixy]

It would be really awesome if blackbox_exporter were able to exercise (and validate the response payloads of) gRPC service methods beyond the existing GRPC Health Checking Protocol support.

Proposed workflow:

• A grpc_unary_method configuration is provided that describes a grpc request and response expectations (example below)
• Based on the provided config, the probe would first reach out to the grpc server's Reflection API to grok the expected request and response types
• The probe would marshal the request_plaintext payload provided in plaintext in the config and send it to the target gRPC method
• The response would be compared to the expected_response_plaintext payload provided in plaintext in the config

Recorded metrics for each probe execution would include (but not be limited to):

• Duration of the reflection API request
• Success-iness of the reflection request (maybe a counter with different result types, ex. SUCCESS|REFLECTION_NOT_ENABLED|etc.
• Duration of the unary method request
• Counter including the status code of the method request (standard codes available here)
• Success-iness of the probe (maybe a counter with different result types, ex. SUCCESS|REFLECTION_FAILED|UNARY_METHOD_NOT_FOUND|INVALID_REQUEST_PAYLOAD|EXPECTED_RESPONSE_NOT_RETURNED|etc.)
• Duration of the entire probe execution

There are a few command line utilities that implement similar plaintext friendly functionality, ex gRPCurl and grpc_cli

Example configuration

grpc_unary_method_example:
  prober: grpc_unary_method
    service: hello.HelloService.SayHello
    tls: false
    request_plaintext: "name: Foo"
    expected_response_plaintext: "message: \"Hello Foo\""

[electron0zero]

I would love to see this, happy to review if someone PRs it in.

[makotonakai]

Can I work on this issue?

[electron0zero]

@makotonakai sure, go for it.