LR(S) probes
7.5.2. 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.

Further information and links