[wildfly-dev] A look at Eclipse MicroProfile Healthcheck

[Jeff Mesnil]

> On 6 Jul 2017, at 21:00, Heiko Braun <hbraun at redhat.com> wrote:
> Kubernetes has different semantics for live and ready, i.e how it interprets and reacts to certain health responses, but underneath its the same protocol. 
> 
> With the health api it's no different: you can model readiness or liveness checks with it. I think the only constraint we are facing atm, is the usage of a single protocol entrypoint. This approach disallows to have live and readiness checks for the same node (i.e there is just /health) 
> 
> Maybe we should change that to support multiple protocol entry points? These could either be custom ones or defined in the spec. For instance rather then having /health, we could introduce /live and /ready. The api underneath however would remain the same.

Some further food for thought (that will go in an issue in the spec later today):

Maybe the spec could provide some additional metadata to further characterize the health check procedures.
For example a procedure annotated with @Ready would return UP when the component is “ready” (for whatever it is doing) and DOWN otherwise.
The same component could have another procedure (without any annotation or a @Live one) that returns UP when the component checks it is healthy.

The component would return different status depending on its state:
* during its initialization (READY = DOWN, LIVE = UP)
* after its initialization (READY = UP, LIVE = UP)
* if it is encountering some issues, (LIVE = DOWN, READY = <whatever>).

The spec could then provide a different entry point that only checks procedures annotated with @Ready.

TL;DR:
the spec should enforce only 2 states (UP and DOWN) for each check procedures but could characterise them to let consumers query different type of healthiness (live and ready)

jeff


-- 
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/