Allow HealthIndicator registration in runtime

[vpavic]

Currently HealthIndicator instances are required to be registered as Spring beans in order to provide health information. This means that Boot's Health information infrastructure cannot be easily used for health information on integration points which are not known when application context is created, or are simply dynamic by nature and can be changed in runtime.

IMO introduction of something like HealthIndicator registry would allow this use case while also retaining compatibility with current approach.

If this suggestion is accepted I'd be willing to work on a PR to provide such functionality.

[vpavic]

Requested feature would be similar to HealthCheckRegistry from Dropwizard Metrics.

[wilkinsona]

Here's a proposal for the registry API:

package org.springframework.boot.actuate.health;

import java.util.Map;

/**
 * A registry of {@link HealthIndicator}s.
 * <p>
 * Implementations <strong>must</strong> be thread-safe.
 *
 * @author Andy Wilkinson
 * @author Vedran Pavic
 */
public interface HealthIndicatorRegistry {

    /**
     * Registers the given {@code healthIndicator}, associating it with the given
     * {@code name}.
     * @param name the name of the indicator
     * @param healthIndicator the indicator
     * @throws IllegalStateException if an indicator with the given {@code name} is
     * already registered.
     */
    void register(String name, HealthIndicator healthIndicator);

    /**
     * Unregisters the {@code HealthIndicator} previously registered with the given
     * {@code name}.
     * @param name the name of the indicator
     * @return the unregistered indicator, or {@code null} if no indicator was found in
     * the registry for the given {@code name}.
     */
    HealthIndicator unregister(String name);

    /**
     * Returns the health indicator registered with the given {@code name}.
     * @param name the name of the indicator
     * @return the health indicator, or {@code null} if no indicator was registered with
     * the given {@code name}.
     */
    HealthIndicator get(String name);

    /**
     * Returns a snapshot of the registered health indicators and their names. The
     * contents of the map do not reflect subsequent changes to the registry.
     * @return the snapshot of registered health indicators
     */
    Map<String, HealthIndicator> getAll();

}

Note that the API deliberately doesn't make any promises about the ordering of the health indicators returned by getAll. It's likely that an implementation may want to order the health indicators (insertion order, Spring's @Order, etc) but I can't see a need for the API to constrain an implementation's options.

[vpavic]

OK, I'll create a new PR to address the registry implementation.

My idea in the original PR was also to leave the ordering out of the API. Regarding getAll, as discussed in the original PR, should we prefer to return a List of holder objects?

[wilkinsona]

as discussed in the original PR, should we prefer to return a List of holder objects?

I'm still not sure about that. That's one reason why this is labelled as being for team discussion.

[snicoll]

I much prefer Andy's proposal regarding getAll.

[wilkinsona]

This means that Boot's Health information infrastructure cannot be easily used for health information on integration points which are not known when application context is created, or are simply dynamic by nature and can be changed in runtime

@vpavic Can you give us some concrete examples please? We're struggling to think of a real-world use case for this.

[vpavic]

@wilkinsona I didn't know this was such an exotic requirement :)

We're having such use cases in virtually all of our projects.

We develop solutions for telcos and these projects regulary include a lot of integration with proprietary external systems. Having some sort of a healt indicator to monitor the status of connection is a must, but also we often have the requirement to register, unregister and reconfigure connections to those systems during runtime. When connector to some instance of these external systems is either discarded, or a new one is created, naturally this also affects the HealthIndicator.

Previously we've been using Dropwizard Metrics for our projects, and as mentioned in second post it has its registry so this is something we miss in Spring Boot and was inspiration for this issue and subsequent PR.

[wilkinsona]

@vpavic

I didn't know this was such an exotic requirement :)

You're the first person who's asked for it.

When connector to some instance of these external systems is either discarded, or a new one is created, naturally this also affects the HealthIndicator.

Could this also be tackled with a custom health indicator that's aware of a dynamic set of connections?

[vpavic]

@wilkinsona

You're the first person who's asked for it.

Yes, I'm aware of that. I jokingly referred to it as "exotic requirement" because it's a pattern seen in other libraries and one that definitely has its advantages.

Could this also be tackled with a custom health indicator that's aware of a dynamic set of connections?

No, I'm afraid not. That makes it hard to obtain a reference to individual HealthIndicators that make a dynamic set of connections since they wouldn't be registered in a central place with other HealthIndicators (unfortunately that central place is ApplicationContext ATM).

Your suggestion is part of the workaround we have in place at the moment in our project and I'm not quite happy with it.

[philwebb]

We're going to need to redesign a large chunk of our actuator code to support reactive programming. I think this one should go on hold until that work has been completed.

[snicoll]

Duplicate of #4965