On 7 Jul 2017, at 14:18, Heiko Rupp <hrupp(a)redhat.com> wrote:
On 6 Jul 2017, at 15:00, David Lloyd wrote:
> Is this a polling-only service, or is there a "push" mechanism?
Right now poll only, basically building the counterpart
of the Kubernetes/OpenShift health check calls.
> Just brainstorming, I can think of a few more potentially useful health checks beyond
what you've listed:
>
> • EJB failure rate (if an EJB starts failing more than some percentage of the last,
say 50 or 100 invocations, it could report an "unhealthy"
> condition)
> • Database failure rate (something with JDBC exceptions maybe)
> • Authentication realm failure rate (Elytron's RealmUnavailableException)
I think those are internal implementation details and something
each application needs to come up with good values.
While the HCP can have a detailed payload as above, it is not
required, and could only return 204 UP or 503 DOWN.
Kube will not look at the body anyway.
Some food for thought.
It’s not clear to me if any checks dealing with ranges ("over time" or
"over invocations" such a failure rate) should be handled by a health check
procedure at all.
Heiko R. has proposed a spec to cover Metrics via HTTP endpoints[1] that is also relevant
here.
Anything dealing with such range might be better addressed by monitoring tools with can
detect trends.
Health checks and telemetry are somehow related but it’s not clear to me where the
boundaries lie.
[1]
https://github.com/eclipse/microprofile-evolution-process/blob/master/pro...
--
Jeff Mesnil
JBoss, a division of Red Hat
http://jmesnil.net/