External-Mirrors/keycloak
2
0
Fork 0
mirror of https://github.com/keycloak/keycloak.git synced 2026-01-08 14:32:05 -03:30
Code Issues Packages Projects Releases Wiki Activity

fix: updating the health check docs

Browse Source 
closes: #44634

Signed-off-by: Steve Hawkins <shawkins@redhat.com>
Signed-off-by: Steven Hawkins <shawkins@redhat.com>
Co-authored-by: Alexander Schwartz <alexander.schwartz@gmx.net>
Co-authored-by: Klemens Böswirth <23529132+kodebach@users.noreply.github.com>
This commit is contained in:
Steven Hawkins 2025-12-19 08:31:22 -05:00 committed by GitHub
parent aefecade5c
commit 6bb586e871
No known key found for this signature in database
GPG Key ID: B5690EEEBB952194
1 changed files with 8 additions and 6 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

14
docs/guides/observability/health.adoc
View File

@ -18,12 +18,10 @@ When this option is `false` you should block unwanted external traffic to `/heal
{project_name} exposes 4 health endpoints:
* `/health/live`
* `/health/ready`
* `/health/started`
* `/health`
See the https://quarkus.io/guides/smallrye-health#running-the-health-check[Quarkus SmallRye Health docs] for information on the meaning of each endpoint.
* `/health/started` - Startup probe used for initial startup of {project_name} before the liveness probe takes over.
* `/health/live` - Check if {project_name} is running. If this fails the application should be discarded (terminated, shutdown) and started again.
* `/health/ready` - Checks if {project_name} is ready to process requests or not. Only direct traffic to a newly started instance once the readiness probe succeeds. If this procedure fails, the application is temporarily unavailable to serve new requests, and traffic should be directed elsewhere.
* `/health` - accumulates all health check procedures in the application.
These endpoints respond with HTTP status `200 OK` on success or `503 Service Unavailable` on failure, and a JSON object like the following:
@ -54,6 +52,8 @@ These endpoints respond with HTTP status `200 OK` on success or `503 Service Una
}
----
See the https://github.com/microprofile/microprofile-health/blob/main/spec/src/main/asciidoc/protocol-wireformat.asciidoc[wire format] for a more detailed description.
== Enabling the health checks
It is possible to enable the health checks using the build time option `health-enabled`:
@ -97,6 +97,8 @@ The Containerfile `+HEALTHCHECK+` instruction defines a command that will be per
The above code depends on the values of the {project_name} options such as `http-relative-path` (`http-management-relative-path`) and `http-management-port`. In case those are changed the code needs to be modified accordingly.
NOTE: the `+HEALTHCHECK+` shown is based upon the ready endpoint. This is appropriate for informational purposes or to determine if the container should receive requests. It should not be used to determine if the container needs restarted.
If you enable TLS as shown in <@links.server id="enabletls" />, the management interface will also use TLS. Depending upon how the management interface endpoints are intended to be used you can still have plain HTTP health checks if:
- the management interface uses HTTP, not HTTPS, by setting `http-management-scheme` to `http`.