-
Notifications
You must be signed in to change notification settings - Fork 238
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
A90: Add List Method to gRPC Health Service #468
base: master
Are you sure you want to change the base?
Conversation
This proposal introduces a new `List` RPC endpoint for the Health service, allowing clients to retrieve the statuses of all monitored services or a filtered list of specific services. This feature simplifies integration with status-reporting dashboards and enhances observability for microservices.
@a11r care to give it a review whenever you can? :) |
Co-authored-by: Benjamin Krämer <[email protected]>
A##-list-health.md
Outdated
|
||
The existing Health service provides basic health check functionality but lacks a mechanism to retrieve a comprehensive list of all monitored services and their statuses. | ||
|
||
This limitation makes it challenging for clients to aggregate health information across multiple services, particularly for use cases like publishing service statuses to dashboards such as [Cachet](https://cachethq.io/) or [Statuspage](https://www.atlassian.com/software/statuspage). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can you help me understand the use-case here? Both of those publishing services seem to be aimed at communicating overall service health to end-users. However, the gRPC health service is really about exposing the health of an individual endpoint, not of the service as a whole. In what context would these be used together?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for the review.
I imagine the following use case: We need to aggregate these endpoint statuses to get overall service health. We'd build an aggregator service that polls these endpoints, applies logic to determine service status, and then feeds that consolidated data to tools like Cachet
or Statuspage
for end-user visibility, and also for internal monitoring. So, while gRPC
is endpoint-focused, the Health service is a key data source for a broader service health system. Adding a new List
endpoint would allow towards that end.
Hope that helps.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for explaining. I chatted briefly with some folks internally about this, and our feeling is that this is a reasonable approach, as long as you're willing to contribute the implementation to gRPC.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'd be honored to contribute to gRPC. Thank you.
A##-list-health.md
Outdated
* **Status:** Draft | ||
* **Implemented in:** TBD | ||
* **Last updated:** 2024-12-17 | ||
* **Discussion at:** TBD |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Please create a thread for this on the grpc.io mailing list and add a link to that thread here, as per the gRFC process.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Done, will wait until it gets posted to update with the link.
A##-list-health.md
Outdated
|
||
The existing Health service provides basic health check functionality but lacks a mechanism to retrieve a comprehensive list of all monitored services and their statuses. | ||
|
||
This limitation makes it challenging for clients to aggregate health information across multiple services, particularly for use cases like publishing service statuses to dashboards such as [Cachet](https://cachethq.io/) or [Statuspage](https://www.atlassian.com/software/statuspage). |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Thanks for explaining. I chatted briefly with some folks internally about this, and our feeling is that this is a reasonable approach, as long as you're willing to contribute the implementation to gRPC.
A##-list-health.md
Outdated
## Implementation | ||
|
||
1. Add the `List` RPC endpoint and the associated request/response messages in the Health service .proto file. | ||
2. Update client libraries to support the `List` endpoint. Provide examples demonstrating how to call the endpoint and handle its response. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there's another important step before this one, which is to implement the new method in the health service implementations in each gRPC language.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Would you mind pointing me in the right direction? I'm happy to write code in pretty much all the languages supported by gRPC, but I just want to make sure what are those places I need to change.
Signed-off-by: Marcos Huck <[email protected]>
Signed-off-by: Marcos Huck <[email protected]>
Context
This proposal introduces a new
List
RPC endpoint for the Health service, allowing clients to retrieve the statuses of all monitored services or a filtered list of specific services. This feature simplifies integration with status-reporting dashboards and enhances observability for microservices.Change
This PR submits the proposal document for review and potential approval by the gRPC maintainers.
Additional information
I started the implementation of the health service (including just the gRPC service endpoint spec) in this PR: grpc/grpc-proto#143