You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When configuring additional paths for Spring Boot actuator health groups ('readiness', 'liveness', etc.), unrelated health indicators to those groups unexpectedly start failing. This behavior presents risks for production environments, potentially leading to unnecessary restarts or pod terminations.
Impact:
This issue introduces the risk of unnecessary pod restarts or service disruptions within environments using health endpoints for availability checks (e.g., Kubernetes). A failing health indicator on one path could lead to cascading failures within liveness or readiness probes.
Steps to reproduce:
Bootstrap a new project with SpringBoot 3.2.4.
Create a custom health indicator that always reports "DOWN":
Spring Boot is creating two new groups called readiness and liveness which by default include all health indicators. If you want to only include the liveness and readiness probes you have two options. You can either set the following property to create /readyz and /livez additional paths:
Flagging for a team discussion since I wonder if we should do more to improve things. Perhaps if management.endpoint.health.probes.enabled=true is set and management.endpoint.health.group.liveness doesn't change the include or exclude we should keep the probe defaults.
philwebb
changed the title
Actuator health groups fail for unrelated indicators when additional paths are configured
Retain default group membership when configuring additional paths on probe health groups
Apr 17, 2024
We're going to look to see if we can improve the default behavior so that liveness and readiness groups have sensible memberships unless the user has specifically configured them otherwise. This is a breaking change so we can't consider it a bug.
When configuring additional paths for Spring Boot actuator health groups ('readiness', 'liveness', etc.), unrelated health indicators to those groups unexpectedly start failing. This behavior presents risks for production environments, potentially leading to unnecessary restarts or pod terminations.
Impact:
This issue introduces the risk of unnecessary pod restarts or service disruptions within environments using health endpoints for availability checks (e.g., Kubernetes). A failing health indicator on one path could lead to cascading failures within liveness or readiness probes.
Steps to reproduce:
Bootstrap a new project with SpringBoot
3.2.4
.Create a custom health indicator that always reports "DOWN":
Add an additional paths to the
readiness
andliveness
groups:Expected behavior (and this works without the additional path configs in step (3)):
/actuator/health
- should fail/actuator/health/readiness
- should pass/readyz
- should pass/actuator/health/liveness
- should pass/livez
- should passActual behavior:
/actuator/health
- fails/actuator/health/readiness
- fails (unexpectedly)/readyz
- fails (unexpectedly)/actuator/health/liveness
- fails (unexpectedly)/livez
- fails (unexpectedly)I would have expected readiness and livenss to have failed if I only set the following props:
Demo Project (see tests):
demo.zip
Potential Workaround (Temporary):
Avoid using
additional-path
on health groups where this side-effect could be disruptive.The text was updated successfully, but these errors were encountered: