Health checks with liveness and readiness probes

To monitor the health of the modules deployed in Airlock IAM instances, health check endpoints for liveness and readiness are available. The current health check implementation uses MicroProfile Health version 3.0.

Deprecation warning – migrate to new endpoints

With Airlock IAM 7.4 a limited feature set for health checks was introduced to enable the Airlock Gateway to check the liveness of the loginapp.

Note that the health endpoint residing at /{instance}-login/rest/health is deprecated and scheduled for removal with Airlock IAM 8.0.

We recommended migrating all installations to the new health check endpoints as soon as possible.

The following table compares the MicroProfile Health specification with the usage pattern from Kubernetes:

Kubernetes

MicroProfile

Liveness

Kubernetes uses liveness probes to know when to restart a container.

A health check for liveness allows third-party services to determine if the application is running. This means that if this procedure fails the application can be discarded (terminated, shut down).

Readiness

Kubernetes uses readiness probes to decide when the container is available for accepting traffic. readinessProbe: indicates whether the container is ready to respond to requests. If the readiness probe fails, the endpoints controller removes the pod's IP address from the endpoints of all services that match the pod.

A health check for readiness allows third-party services to know if the application is ready to process requests or not.

Startup

If such a probe is configured, it disables liveness and readiness checks until it succeeds, making sure those probes don't interfere with the application startup.

Not available in Airlock IAM.