New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Retain default group membership when configuring additional paths on probe health groups #40268
Comments
This is a little confusing, but what's happening here is when you declare the following: management.endpoint.health.group.readiness.additional-path=server:/readyz
management.endpoint.health.group.liveness.additional-path=server:/livez Spring Boot is creating two new groups called management.endpoint.health.probes.add-additional-paths=true or you can update the properties to include the correct health indicators: management.endpoint.health.group.readiness.include=readinessState
management.endpoint.health.group.readiness.additional-path=server:/readyz
management.endpoint.health.group.liveness.include=livenessState
management.endpoint.health.group.liveness.additional-path=server:/livez |
Flagging for a team discussion since I wonder if we should do more to improve things. Perhaps if |
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. |
Thanks @philwebb!! I've applied the workaround (1) that you recommended and it is working as expected, thank you. |
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: