No programmatic API to register health checks

[rmannibucau]

Hi,

There are cases where (un)registering at runtime checks would be useful (think about a CDI bean managing clients on whatever backend - JDBC, LDAP, HTTP, ...). Don't think it is doable after startup today so think the health check registry should be exposed and enable - as in metrics spec - to do that.

Romain

[kenfinnigan]

Can you provide some concrete use cases where would be required?

[rmannibucau]

@kenfinnigan when the healthchecks are dynamic, typically in multi tenant applications you create/destroy datasources (JDBC or LDAP for the ones i met) and http clients so you need to align the health checks with these lifecycles, it is not "application scoped".

[kenfinnigan]

I presume this is for a liveness and not readiness check?

[rmannibucau]

in general yes - until it is made boostrap+app scoped by its config (case of enforced default tenant for ex).

[derekm]

People using MicroProfile with OSGi would also be able to upgrade application components or install new application components without restarting their app, which implies adding and removing health checks at runtime.

[rmannibucau]

@derekm hmm, just to ensure to get the exact case and avoid a wrong couter-argument it is without OSGi-CDI spec right but a global health registration with a registry backed by a service right? (this one would be per bundle lifecycle)

[derekm]

@rmannibucau -- I wasn't really thinking about implementation details at that level... I was just thinking about other highly-dynamic environments where one might want new checks to come online or old checks to be removed at runtime due to the loading and unloading of bundles.

[xstefank]

We took a stance to not introduce new features into the specification which may be still unstable. So we introduced health registry in the SmallRye Health implementation -> https://github.com/smallrye/smallrye-health/tree/master/implementation/src/main/java/io/smallrye/health/registry. We also would like to encourage different implementations to also introduce some form of their version of the API so we can catch most of the errors before we move the API to the spec which would result in a smaller need for breaking changes in the future.

If you can, please give a try and report any problems/enhancements that you find.

[rmannibucau]

Personally I use that:

@Getter
@ApplicationScoped
public class GlobalHealthRegistry {
    private final Collection<HealthCheck> readinessCustomChecks = new CopyOnWriteArrayList<>();
    private final Collection<HealthCheck> livenessCustomChecks = new CopyOnWriteArrayList<>();

    public Removable registerReadinessCheck(final HealthCheck check) {
        readinessCustomChecks.add(check);
        return () -> readinessCustomChecks.remove(check);
    }

    public Removable registerLivenessCheck(final HealthCheck check) {
        livenessCustomChecks.add(check);
        return () -> livenessCustomChecks.remove(check);
    }

    @FunctionalInterface
    public interface Removable extends AutoCloseable {
        @Override
        void close();
    }
}