16.1.1.15. Healthcheck endpoints¶
This module is intended to ensure the application can be monitored effectively and provide insights into whether the application and its dependencies are operational. A primary intention was to create a way for Kubernetes to check on containers.
- Endpoints:
GET /healthz/: Combined health check for liveness and readiness.GET /healthz/startupz: Startup check to confirm if the app has started.GET /healthz/livez: Liveness check to verify if the app is running.GET /healthz/readyz: Readiness check to confirm if the app is ready to serve requests.GET /healthz/resolversz: Resolver check to test the connection to all LDAP and SQL resolvers.
The corresponding code is tested in tests/test_api_healthcheck.py.
For information on the current standard and how to configure these probes, see the Kubernetes documentations:
https://kubernetes.io/docs/reference/using-api/health-checks/
- GET /healthz/¶
Combined health check endpoint for liveness and readiness.
The health check verifies the liveness of the app, ensuring it is running, and the readiness, ensuring the app and its dependencies are ready to serve requests.
- resheader Content-Type:
application/json
- status 200:
Application is live and ready.
- status 503:
Application is live but not ready.
Example Request:
GET /healthz HTTP/1.1 Host: example.com Accept: application/json
Example Response:
HTTP/1.1 200 OK Content-Type: application/json { "status": "ready", "hsm": "OK" }
- GET /healthz/startupz¶
Startup check endpoint that indicates if the app has started.
This endpoint returns a status of “started” if the app is initialized and running, otherwise it returns “not started” with an HTTP status code of 503.
- resheader Content-Type:
application/json
- status 200:
Application has started.
- status 503:
Application has not started yet.
Example Request:
GET /healthz/startupz HTTP/1.1 Host: example.com Accept: application/json
Example Response:
HTTP/1.1 200 OK Content-Type: application/json { "status": "started" }
- GET /healthz/livez¶
Liveness check endpoint that indicates if the app is running.
This endpoint returns an HTTP status 200 and a JSON object indicating that the application is live and running.
- resheader Content-Type:
application/json
- status 200:
Application is live.
Example Request:
GET /healthz/livez HTTP/1.1 Host: example.com Accept: application/json
Example Response:
HTTP/1.1 200 OK Content-Type: application/json { "status": "OK" }
- GET /healthz/readyz¶
Readiness check endpoint that indicates if the app is ready to serve requests.
The endpoint checks the readiness of the app, ensuring that the app has started and the HSM (Hardware Security Module) is in a ready state. If any condition is not met, a 503 status is returned with appropriate information.
- resheader Content-Type:
application/json
- status 200:
Application is ready.
- status 503:
Application is not ready or HSM is not ready.
Example Request:
GET /healthz/readyz HTTP/1.1 Host: example.com Accept: application/json
Example Response:
HTTP/1.1 200 OK Content-Type: application/json { "status": "ready", "hsm": "OK" }
- GET /healthz/resolversz¶
Resolver check endpoint that tests the connection to all resolvers types defined in resolver_types. For now LDAP and SQL resolvers are tested.
The endpoint returns a JSON object with the status of each resolver (either “OK” or “fail”). It attempts to establish a connection to each resolver, and if any exception occurs during the check, a 503 status is returned.
- resheader Content-Type:
application/json
- status 200:
All resolvers have been successfully checked.
- status 503:
Failed to check resolvers or an error occurred.
Example Request:
GET /healthz/resolversz HTTP/1.1 Host: example.com Accept: application/json
Example Response:
HTTP/1.1 200 OK Content-Type: application/json { "status": "ready", "ldapresolver": { "ldapresolver1": "OK", "ldapresolver2": "OK" }, "sqlresolver": { "sqlresolver1": "OK", "sqlresolver2": "OK" }, }