We have a microservice architecture and one of our applications depends on services provided by several other applications. All these applications are Spring Boot applications, and all publish the actuator health endpoints. Currently, there are many auto-configured HealthIndicators for various databases etc., but none for own /actuator/health endpoint.

While writing custom health indicator is trivial, maybe this could be a part of the framework, as a nice enhancement.

Comment From: bclozel

I'm not sure I understand.

You'd like Spring Boot to provide a health indicator that checks the "/actuator/health" endpoint of remote applications?

Comment From: petrdvorak

Yes, precisely. Suppose we have some origin services with:

  • https://service1.origin.remote/actuator/health
  • https://service2.origin.remote/actuator/health
  • https://service3.origin.remote/actuator/health

Then we have a service that uses these services. We want to publish the health endpoint:

  • https://main.service.remote/actuator/health

... that returns the result based on the health status of service1, service2 and service3.

Writing this as a custom health indicator is simple, since the model is simple. It would just be nicer to have something like (super-lazy concept... using some model class instead of String would probably be better), so that the system can easily consume the healthchecks it produces, efficiently in parallel, etc.:

@Component
public class MyHealthIndicator implements AggregatedActuatorHealthIndicator {

    @Override
    public String[] paths() {
        return new String[] {
            "https://service1.origin.remote/actuator/health",
            "https://service2.origin.remote/actuator/health",
            "https://service3.origin.remote/actuator/health"
        }
    }

}

Comment From: bclozel

I think I understand now. I don't think we're going to implement this as I wouldn't consider this as a best practice for Spring Boot applications.

The global health endpoint is meant to be used as way to get insights into the current state of the application and its dependencies. We don't think that using the global health endpoint as a way for the platform to know if it should restart or route traffic to the application is a good idea. We've introduced the liveness and readiness endpoints for that purpose.

For the same reason, an application should not rely on that endpoint as a way to check its external dependencies. A remote application might be partially broken for other reasons, but the feature that we're using might not be - the reverse is also true. This is why we advise in this case to write a custom health indicator that uses the remote service itself by issuing a sample API request, for example. On top of that, remote services might not be essential to the application itself, as the app might implement fallbacks or cached values.

In short, there's no easy answer to that one and collecting the global health of remote applications is very likely to create a lot of false positives and negatives - leading to cascading failures. I'm closing this enhancement request as a result for now.

Comment From: petrdvorak

OK, it makes sense... It felt natural to have such functionality (our service dependencies are "critical" - failure of service would stop the main application from correct functionality, basically we do not see a difference between database down and REST service down) but I understand this might not have an easy generic answer...