MicroProfile Health 2.2 Feeback on HealthGroup

[Emily Jiang]

I reviewed the new MicroProfile 2.2 functionalities and found the newly added Health Group is confusing detailed below.

Custom check

A new kind of Health Check can be defined with the @HealthGroup annotation.

One or more Health Check procedure(s) can be annotated with @HealthGroup to apply a custom group name to the procedure.

All the Health Check procedures belonging to the same group define a new kind of Health Check.

The @HealthGroup annotation must be applied on a HealthCheck implementation to define a custom check procedure with the given name, otherwise, this annotation is ignored.

A HealthCheck implementation can have multiple @HealthGroup annotations to make it a member of multiple custom Health Check’s groups.

As a consequence, this introduces two more end points

health/group/{name}
/health/group Since MP Health is primarily defined to work with Kubernetes, we have nice and clear readiness and liveness endpoint and operation team knows which one to use already. With this change, two more endpoints were introduced. I don't know for what purpose and it is confusing rather than helping. Can someone ellaborate the use case this new functionality is trying to cater for? I raised this issue on mp-health but want to bring to the group discussion so that more people might be able to voice their opinion. Thanks Emily

[Ken Finnigan]

My understanding from reading through the spec and the issue discussion is that @HealthGroup is a generic form of @Liveness and @Readiness.

Yes, @Liveness and @Readiness are particular to Kubernetes environments, but from a monitoring perspective, it could be beneficial to have different groups of Health Checks that you want to see the status of, such as all health checks for database connections. However, I don't think there's anything with the MP Health specification that says it should only deal with Kubernetes Health? Or have I missed that limitation in the spec?

The advantage to them not being a plain HealthCheck that requires a call to /health is that calling /health invokes every health check that's defined, which could be expensive and unnecessary in some circumstances. Therefore it's beneficial to be able to only execute a set of HealthChecks, defined by @HealthGroup, that may also happen to be used for @Liveness or @Readiness.

Seems like a reasonable addition to the API that adds needed flexibility for monitoring the health of a service

Ken

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/71fb848b-fe8e-4553-adea-6a546425707d%40googlegroups.com.

[Martin Stefanko]

Hi,

Ken summed it well. More and more MP Health users are looking for a way to get only some health checks executed - https://github.com/eclipse/microprofile-health/issues/81. @Readiness and @Liveness are still "special" groups that can be combined in any way with any other @HealthGroup annotations.

It basically provides you with a way to execute some checking code on demand which is not tied to the readiness or liveness lifecycle. 

So what the "health" of the application is in different circumstances may differ on the use cases so even after the application is ready and live we may, for instance, want to check for custom 3rd party services which add some non-critical functionalities to our application. It can function without it but the check can be useful for some monitoring. This is also what we are going to address with the @Wellness qualifier in Health 3.0.

Martin

[Alasdair Nottingham]

Hi,

I have a few concerns with the update in 2.2 based on what is in the spec and the github issue. In the past we have had debates saying that we should be use case led, but the GitHub issue for this says: 

It would be useful in the wire format if we specified a way to execute only some health checks, rather than all discovered @Health health checks.

I could see this being done from both client and server side. From client perspective, listing out a set of names to run, or a group name to run. On the server, I could see marker interfaces, annotations, or even a simple use of class name/@Inject @Named support.

That doesn’t explain the use case for doing this. It also isn’t clear why this was chosen over having the client indicate the checks to run by name. I wasn’t on the calls, where this was discussed and I am now trying to understand this and I’m struggling because it isn’t clear in the spec or issues why this is being done. 

When I next talk to someone about using MicroProfile and what has changed (something I do regularly even if I’m not involved in the specs on a daily basis) I want to be able to explain the use case for this and based on the specification I can’t. Saying that “it could be beneficial to have different groups of Health Checks” isn’t as helpful as describing the scenarios where that is beneficial. Otherwise this looks like a solution in search of a problem.

My second concern is that the spec uses different terms to describe this new capability. The specification calls it a custom check, the Java API says it is a HealthGroup. The REST API also talks about it in terms of groups. This is further confusing if you consider that a Liveness or Readiness check is custom in as much as a developer has to decide what the check does when they write the check, rather than it being something built into the microprofile runtime. I would like to use consistent terminology between the spec and Java API.

Thanks

Alasdair

-- 
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.
To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/84d92e2d-f186-40f2-9386-9cc78794beef%40googlegroups.com.

[Antoine Sabot-Durand]

Hi all,

As Ken and Martin already mentioned, this feature was requested by community members and makes sense IMO. It was discussed in issue #81 and also in all issues and thread regarding @Health deprecation (there has been discussion about "custom checks" with @Health at that time).

It doesn't impact existing @Liveness and @Readiness and provide a way to define some custom checks.

MP Health Check spec was never restricted to k8s, so it can contain features that are not useful under k8s (as long as it supports k8s of course)

As for use cases you could imagine a lot of them.

For instance having multiple procedure  to check connectivity to a datastore (connectivity, performance, specific data availability, etc...). Each of these procedure could be at a different level but all could be called at once with @HealthGroup("datastore")

Regarding the wording, I agree that we should make it clearer 

Antoine Sabot-Durand

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/3DD2F3C1-952D-4242-ADAB-A18F18D7AD91%40gmail.com.

[Emily Jiang]

Thanks everyone who commented! I would like to find out:

1. Who uses this endpoint? Was it the operation team?

2. How can he discover which healthgroup he should use as the health group is harded coded in the code?

3. From my understanding, the health spec provides info for cloud infrastructure so that cloud infastructure can either route requests or destory the pod. I don't see any other use case useful as yet. If this is designed for a human being, please ellaborate how he finds out the endpoint and then poke the endpoint. For me, the current liveness/readiness approach, you can see the payload clearly already.

Thanks

Emily

Alasdair

To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/84d92e2d-f186-40f2-9386-9cc78794beef%40googlegroups.com.

--
You received this message because you are subscribed to the Google Groups "Eclipse MicroProfile" group.

To unsubscribe from this group and stop receiving emails from it, send an email to microp...@googlegroups.com.

[Antoine Sabot-Durand]

Hi all,

Obviously this feature needs more discussion before make it to the specification. So I suggest that we revert this change and restart the discussion in ticket #81 [1] that I just reopened.

Please add your question to this ticket. 

Antoine Sabot-Durand

[1] https://github.com/eclipse/microprofile-health/issues/81

Le 27 janv. 2020 à 17:35, 'Emily Jiang' via Eclipse MicroProfile <microp...@googlegroups.com> a écrit :



To unsubscribe from this group and stop receiving emails from it, send an email to microprofile...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/microprofile/a90766e2-3df5-4d34-91a9-aaf25daba77c%40googlegroups.com.

[John Clingan]

I think this is a good idea.

To unsubscribe from this group and stop receiving emails from it, send an email to microprofile+unsubscribe@googlegroups.com.