Allow non grpc services to report health/service existance

[ST-DDT]

What version of gRPC are you using?

0.15.0

Feature-Request

Not all applications are purely grpc based, so it would be nice if the HealthStatusManager could expose the health also to other beans. This is especially useful for most monitoring systems that still rely on plain http (html/text/json...).

It would be nice if a method like the following could be added:

• + getAllStatuses() : Map<String, Status>

as an alternative the following would also be OK:

• + getServices() : Set<String>
• + getStatus(name : String) : Status

Usecases:

• Spring Actuator HealthChecks
• Spring Actuator Info to report service existence/status

Alternatives considered: Create my own beans and track the health status twice.

Might be related to #1848, #4356.

PS: If this feature gets accepted, I can create a PR for that.

[dapengzhang0]

The API setStatus(String service, ServingStatus status) is protobuf-based, and it definitely make sense to replace the API with one that does not depend on proto-generated class at all.

For the API BindableService getHealthService(), yes it is grpc-based, but this is grpc library. The health servlce as in the design here "is a GRPC service itself".

We don't provide API getAllStatuses and getStatus(name) in HealthStatusManager. That will be health service implementer's job.

[ST-DDT]

So you are saying, that if I want to use the existing health feature for something not exclusively grpc related, I have to write it myself entirely? Even if I just want to lookup the health of a grpc service?

[zhangkun83]

Talked with @ejona86. It should be fine to expose the status via HealthStatusManager, while we may want to stop exposing protobuf types on the API first. We could define our own enum for the statuses.