The Spring Boot Actuator starter adds a number of important features that give insight into the runtime state of the application. The library contains a number of autoconfigurations that add and configure the various endpoints to access the runtime monitoring data and health of the application. Those endpoints all share a common context path: /actuator. To expose any other endpoints besides /info and /health, we need to explicitly expose them by setting the management.endpoints.web.exposure.include=* property. When the value is set to *, it will expose all of the endpoints. The following endpoints are available to aid us in getting an insight into the application runtime state and configuration:

• /env: This endpoint enables us to query the application about all of the environment variables that the application has access to via the environment implementation, which we have seen earlier. It is very useful when you need to debug a particular issue and want to know a value of any given configuration property. If we access the endpoint by going to http://localhost:8080/actuator/env, we will see a number of different configuration sections, for example, the class path resource [tomcat.https.properties], applicationConfig: [classpath:/application.properties], commonsConfig, systemEnvironment, systemProperties, and others. They all represent an instance of an individual PropertySource implementation that is available in the environment and depending on their place in the hierarchy, may or may not be used to provide the value resolution at the runtime. To find out exactly which entry is used to resolve a particular value, for example, for the book.count.rate property, we can query it by going to the http://localhost:8080/actuator/env/book.counter.rate URL. By default, we should get 10,000 as a result unless, of course, a different value was set via the system environment or command-line arguments as an override. If you really want to dig deep into the code, the EnvironmentEndpoint class is responsible for handling the logic behind this capability.
• /configprops: This endpoint provides you with an insight into the settings of the various configuration property objects, such as our WebConfiguration.TomcatSslConnectorProperties starter. It is slightly different from the /env endpoint as it provides insight into the configuration object bindings. If we open the browser to go to http://localhost:8080/actuator/configprops and search for custom.tomcat.https, we will see the entry for our configuration property object that we will use to configure TomcatSslConnector, which was automatically populated and bound for us by Spring Boot.
• /conditions: This endpoint serves as a web-based analog to the AutoConfiguration Report, which we saw in Chapter 4, Writing Custom Spring Boot Starters. This way, we can get the report using the browser at any time without having to start the application with the specific flags to get it printed.
• /beans: This endpoint is designed to list all the beans that have been created by Spring Boot and are available in application context.
• /mappings: This endpoint exposes a list of all the URL mappings that are supported by the application as well as a reference to the HandlerMapping bean implementation. This is very useful for answering the question of where would a specific URL get routed to. Try going to http://localhost:8080/actuator/mappings to see the list of all the routes that our application can handle.
• /threaddump: This endpoint allows extraction of the Thread Dump information from the running application. It is rather useful when trying to diagnose a potential thread deadlock.
• /heapdump: This endpoint is similar to /dump with the exception that it produces Heap Dump information instead.
• /info: This endpoint shows the basic description and application information that we added and we've seen this in action, so it should be familiar to us as of now. The nice support in the build tools gives us the ability to configure additional or replace existing values inside our build.gradle configuration, which would then be propagated to be consumed by the /info endpoint. Additionally, any properties defined in the application.properties file, that start with info. will be displayed while accessing the /info endpoint, so you are definitely not limited to only the build.gradle configuration. Configuring this specific endpoint in order to return the relevant information can be very helpful when building various automated discovery and monitoring tools as it is a great way to expose application-specific information in the form of a nice JSON RESTful API.
• /actuator: This endpoint gives a nice JSON-formatted list of links in a Hypertext Application Language (HAL) style for all the available actuator endpoints.
• /health: This endpoint provides information about the general application health status as well as a detailed breakdown and health status of the individual components.
• /metrics: This endpoint gives an overview of all the various data points that are emitted by the metrics subsystem. You can experiment with it by accessing it via the http://localhost:8080/actuator/metrics URL in the browser. We will cover this in more detail in the next recipe.

Now that we know in general what is being provided for us by Spring Boot Actuator, we can move on to take a look at the details of what we did to get our custom HealthIndicator class working and how the whole health monitoring subsystem in Spring Boot functions.

As you saw, getting the basic HealthIndicator interface to work is very easy; all we have to do is create an implementing class that will return a Health object upon a call to the health() method. All you have to do is expose the instance of the HealthIndicator class as @Bean for Spring Boot to pick it up and add it to the /health endpoint.

In our case, we went a step further because we had to deal with the need to create HealthIndicator for each CrudRepository instance. To accomplish this, we created an instance of CompositeHealthIndicator to which we added all the instances of DbHealthIndicator for each CrudRepository. We then returned this as @Bean and this is what was used by Spring Boot to represent the health status. Being a composite, it preserved the inner hierarchy as is evident from the returned JSON data representing the health status. We also added some extra data element to provide the indication of the entry count as well as the name of each particular repository so that we can tell them apart.

Looking at the code, you are probably wondering: what is this HealthAggregator instance that we've wired in? The reason that we needed a HealthAggregator instance is because CompositeHealthIndicator needs to know how to decide if the inner composition of all the nested HeathIndicators represents good or bad health as a whole. Imagine that all the repositories, but one, return UP but one is DOWN. What does this mean? Is the composite indicator healthy as a whole or should it also report DOWN because one inner repository has issues?

By default, Spring Boot already creates and uses an instance of HealthAggregator, so we just autowired it and used it in our use case as well. We did have to explicitly add the import of the HealthIndicatorAutoConfiguration and MetricsDropwizardAutoConfiguration classes in order to satisfy the bean dependency during slice tests for DataJpaTest and WebMvcTest, since those only partially instantiate the context, and the actuator autoconfigurations are missing.

Even though the default implementation is an instance of OrderedHealthAggregator, which just collects all the inner status responses and chooses the lowest on the priority level out of DOWN, OUT_OF_SERVICE, UP, and UNKNOWN, it doesn't always have to be that way. For example, if the composite indicator consists of the indicators for redundant service connections, your combined result could be UP as long as at least one of the connections is healthy. Creating a custom HealthAggregator interface is very easy; all you have to do is either extend AbstractHealthAggregator or implement a HealthAggregator interface itself.