Should gRPC health checking be limited to gRPC services?

Question

With regards to gRPC Health Checking, if a gRPC service is hosted on the same port as other HTTP services that also need health checking, should the responses to grpc.health.v1.Health.Check be only for gRPC services provided, or is it reasonable to also answer about other services as well? If the latter, what model for service names should be used?

I ask in part because there's already a /healthz model for Kubernetes health checking and am trying to figure out whether we need to provide a ligature to the gRPC health checking, or could convolve the existing health checking, e.g.,

import "google.api.http";
…
rpc Check(HealthCheckRequest) returns (HealthCheckResponse) {
  option (google.api.http) = { get: "/healthz" }
}

such that the stock gRPC health check monitor could be so used.

Answer 1

gRPC health check shares fate with gRPC server because it is a gRPC method by itself. If the gRPC server outlives or shares fate with your other services, then I think it is ok to use gRPC health checking service to serve the status of other services.

I am not aware of official support for sharing a port between gRPC server and other servers in C++, Java or Go. I am not sure what setup you are thinking, but the general idea above applies.