search

hashicorp / vault

A tool for secrets management, encryption as a service, and privileged access management
https://www.vaultproject.io/
Other
31.02k stars 4.2k forks source link

Health Check Endpoint #209

Closed nrocine closed 9 years ago

nrocine commented 9 years ago

I see there is the /sys/health endpoint in the API, but presumably that is only accessible by an authenticated user authorized for the /sys path.

I was wondering if there is any thought to adding a simple, publicly accessible health check endpoint--like /health that returns 200 if the server is up.

My target use case would be for an EC2 ELB to health check if vault is up, so that we could be notified if there is an issue with the instance.

We are only looking at non-HA right now, but even for HA, having a sense of how many instances are in service externally would probably be helpful for others.

Thanks for your consideration.

mitchellh commented 9 years ago

/sys/health is an unauthenticated endpoint, youcan hit it with anything. We'll update the docs to say such.

xuwang commented 8 years ago

On google cloud network balancing, the health check is done by method HEAD and expecting a return code of OK 200. It would be nice if Vault API could have an endpoint to support it when the server is up and ready for client call, rather than return 200 only after unsealed.

Thanks.

jefferai commented 8 years ago

@xuwang The server isn't ready for a client call when it's not unsealed!

xuwang commented 8 years ago

@jefferai I think we have different views on "server is ready". Did a client call server api /sys/unseal to unseal? So question is how a load balancer test a server is ready for "init" and "unseal" api calls?

xuwang commented 8 years ago

Also even a server is unsealed and "ready", google balancer still need a HEAD endpoint to check server's health. Of cause, gcloud may or may not have customizable health checking methods in the future.

jefferai commented 8 years ago

@xuwang A load balancer can certainly understand whether the server is ready for init and unseal calls; it's the particular case of the Google balancer that is the issue here. Requiring HEAD and 200 is a pretty onerous design (not that AWS is much better; for instance, it doesn't consider 204 to be an OK response).

xuwang commented 8 years ago

Agreed. On Mar 2, 2016 2:24 PM, "Jeff Mitchell" notifications@github.com wrote:

@xuwang https://github.com/xuwang A load balancer can certainly understand whether the server is ready for init and unseal calls; it's the particular case of the Google balancer that is the issue here. Requiring HEAD and 200 is a pretty onerous design (not that AWS is much better; for instance, it doesn't consider 204 to be an OK response).

— Reply to this email directly or view it on GitHub https://github.com/hashicorp/vault/issues/209#issuecomment-191461229.

ddgenome commented 8 years ago

For those finding this, the full health check endpoint is /v1/sys/health and is typically on port 8200.

@jefferai how would a load balancer tell if a server is ready for init and unseal calls? Having it check init seems like it would have unintended consequences and unseal would fail without providing an unseal key. This question is academic at this point since in an HA situation you would not want the load balancer to send traffic to any node but the primary.

jefferai commented 8 years ago

The latest released version of Vault allows to to specify the desired status codes for the different states; see https://www.vaultproject.io/docs/http/sys-health.html