The next essential point of the system's monitoring is the capability to check the service health status. In the most straightforward approach, service health might be interpreted as an ability for the service to respond to requests. Such a scenario is depicted in the following diagram:

The central problem here is that the service might be accessible via a network. However, some vital components such as a hard drive (if used), underlying database, or a dependent service might be inaccessible. Because of this, the service cannot be fully functional. From the operational perspective, a health check means much more than just an availability status. First of all, a healthy service is one in which sub-components are fitted and available as well. Moreover, the health information should include all details that allow an operational team to react to potential threats of failure as soon as possible. Responding to the unavailability of the database or free disc space shortage will enable DevOps to take corresponding actions. So, health information may include more details as depicted in the following diagram:

To our delight, the Spring Boot actuator offers a fully-fledged approach to health monitoring. Essential details of the service health might be accessed via the /actuator/health endpoint. This endpoint is enabled and exposed by default.  Moreover, a Spring Boot actuator has an extensive list of built-in health indicators for the most common components such as Cassandra, MongoDB, JMS, and other popular services integrated into the Spring Ecosystem.

Along with a built-in indicator, we may provide a custom implementation of a HealthIndicator. However, the most exciting part of Spring Boot Actuator 2.0 is proper integration with Spring WebFlux and Reactor 3. That mixture provides a new reactive interface for health indicators called ReactiveHealthIndicators. This may be vital when the health status requires additional I/O requests that could be processed more efficiently with WebClient, as described in Chapter 6, WebFlux Async Non-Blocking Communication. The following code implements a custom health indicator using the new API:

@Component
class TemperatureSensor {                                          // (1)
  public Mono<Integer> batteryLevel() {                            // (1.1)
    // A network request here
  }
  ...
}

@Component
class BatteryHealthIndicator implements ReactiveHealthIndicator {  // (2)
   private final TemperatureSensor temperatureSensor;              // (2.1)

   @Override
   public Mono<Health> health() {                                  // (3)
      return temperatureSensor
         .batteryLevel()
         .map(level -> {                              
            if (level > 40) {
               return new Health.Builder()
                  .up()                                            // (4)
                  .withDetail("level", level)
                  .build();
            } else {
               return new Health.Builder()
                  .status(new Status("Low Battery"))               // (5)
                  .withDetail("level", level)
                  .build();
            }
         }).onErrorResume(err -> Mono.                             // (6)
            just(new Health.Builder()
               .outOfService()                                     // (6.1)
               .withDetail("error", err.getMessage())
               .build())
         );
   }
}

The preceding example code shows how to wire communication with an external sensor that can be installed in a house but is available via a network:

1. The TemperatureSensor service has a Mono<Integer> batteryLevel() (1.1) method, which makes a request to the sensor, and, if this is available, returns the current battery level from 0 to 100 percent. This method returns a Mono with a response and uses WebClient for efficient communication.
2. To use the data about the sensor's battery level when calculating the service health status, we have to define a custom BatteryHealthIndicator class. This implements the ReactiveHealthIndicator interface and has a reference to the TemperatureSensor service (2.1).
3. To implement the interface, the health indicator implements the Mono<Health> health() method with a reactive return type. Consequently, the health status may be reactively calculated at the point when a network response arrives from the temperature sensor.
4. Depending on the battery level, we may return a predefined UP status with some additional details.
5. An example of a completely custom Health status. In this example, we receive a Low Battery status.
6. Furthermore, using reactor capabilities, we may react to communication errors and return an OUTOFSERVICE status with some details about the actual error (6.1).

Such a monitoring approach enables users to arrange corresponding actions such as raising a ticket for battery replacement or sending notifications to the housekeeper about the low battery status.