spring-boot: Kubernetes readiness probe endpoint returning 404

This issue is now fixed in the 2.3.3 and 2.4.0 SNAPSHOTs.

I’ve carefully read the comments on this issue regarding the following surprising behavior: getting a 404 status on a configured health group, when no indicator is present. In this very case it’s arguably wrong, but we’re in a case of a regression. But some of you thought that

1. a missing indicator in a group should fail the application at startup or
2. that an empty group should disappear from the list of groups on the main endpoint.

The first alternative sounds nice, especially for detecting bad configurations. But it’s also likely to fail in perfectly valid cases. Your application could configure a group management.endpoint.health.group.custom.include=ping,redis and fail in a test environment where no redis instance is available. Because Spring Boot reacts to the environment, it’s expected to behave differently and adapt to the situation.

The second alternative is debatable. Right now our health groups support is auto-configured with the configuration properties and does not look into the application context to check for the existence of health indicators. We seem to all agree that a 404 response status is right in this case. Removing the group information would, in my opinion, make things less consistent as we wouldn’t know that a group has been configured. After all, a health group is just a way to wrap several indicators under the same name and customize its global health status - but health indicators are still dynamic.

After discussing that briefly with the team, we didn’t think that this needs to be changed. Note that this behavior exists since the introduction of the health groups feature. If you can make a stronger case for changing this, please create a dedicated issue and explain how this behavior is inconsistent or could lead to issues.

Thanks!

want to be aware the groups exist, so we know we can add components to them with include ?

The API response is supposed to be for consumers of the API, not documenting configuration options for the developer. Like the rest of the actuator system, only endpoints that are currently available should be listed as available.

I’ve tagged this issue as a regression.

I’m really sorry for letting in that one.

After a bit more digging, I’m not really sure why or whether it was intended, however the issue seems to be that readinessState has become readinessStateProbeIndicator (and same for livenessState) so the old configuration was not correctly including the indicator at all, leaving the readiness group empty.

This seems to work as expected.

management.endpoint.health.group.liveness.include=livenessStateProbeIndicator,diskSpace,refreshScope
management.endpoint.health.group.readiness.include=readinessStateProbeIndicator

Thanks @bclozel - fix is working fine in 2.3.3 after removing the workaround to the probe names I mentioned above 😃

When management.health.[readiness|livenessstate].enabled properties are set to false(by default)

FYI surprisingly enough Spring Boot decided to name the readiness state property management.health.readynessstate.enabled with a y in the 2.3.2.RELEASE version (most recent release at this date).

See the reference: https://docs.spring.io/spring-boot/docs/2.3.2.RELEASE/reference/html/appendix-application-properties.html#actuator-properties

Yes this is an unintended side effect of #22107. The workaround you’re mentioning is the right one in the meantime.

Thanks for raising this issue!

@bclozel what are values am supported to give in my deployment manifests

...
livenessProbe:
  httpGet:
    path: /actuator/health/liveness
    port: http
readinessProbe:
  httpGet:
    path: /actuator/health/readiness
    port: http
...

The issue has been resolved with version 2.3.3. You can expose separate probes with dedicated Health Indicators. You may want to look up here.

Does this cover the fact that they are listed under groups at /health, but then don’t actually exist?