We've created a Spring web app with minimal code and released it to production. This is the perfect time to introduce production-grade support features.

There are some questions that often arise in production, and these are as follows:

• What do we do when the system administrator wants to configure his or her monitoring software to ping our app to see if it's up?
• What happens when our manager wants to know the metrics of people hitting our app?
• What are we going to do when the ops center supervisor calls us at 2:00 a.m. and we have to figure out what went wrong?

The last feature we are going to introduce in this chapter is Spring Boot's Actuator module. This module provides some super slick Ops-oriented features that are incredibly valuable in a production environment.

We start by adding this dependency to our build.gradle as follows:

    compile('org.springframework.boot:spring-boot-starter-actuator') 

When you run this version of our app, the same business functionality is available that we saw earlier, but there are additional HTTP endpoints; these are listed in the following table:

Endpoints, by default, are disabled. We have to opt in. This is accomplished by setting endpoints.{endpoint}.enabled=true inside src/main/resources/application.properties, like this:

endpoints.health.enabled=true

This line added to application.properties mentions the endpoint, health, and enables it. If we restart the application, we can ping for its health, as shown in the next section.

Each of these endpoints can be visited using our browser or using other tools like curl:

$ curl localhost:9000/application/health
{
  "status": "UP",
  "details": {
    "mongo": {
      "status": "UP",
      "details": {
        "version": "3.2.2"
      }
    },
    "diskSpace": {
      "status": "UP",
      "details": {
        "total": 498937626624,
        "free": 66036432896,
        "threshold": 10485760
      }
    }
  }
}

This preceding health status gives us the following:

• An overall UP status
• The status of MongoDB
• The status of the diskspace

When other components are added, they may, optionally, add their own health checks.

This immediately solves our first need listed previously. We can inform the system administrator that he or she can write a management script to interrogate our app's health.

Be warned that each of these endpoints serve up a compact JSON document. Generally speaking, command-line curl probably isn't the best option. While it's convenient on *nix and Mac systems, the content is dense and hard to read. It's more practical to have the following:

• a JSON plugin installed in our browser (such as JSON Viewer at https://github.com/tulios/json-viewer)
• a script that uses a JSON parsing library if we're writing a management script (such as Groovy's JsonSlurper at http://docs.groovy-lang.org/latest/html/gapi/groovy/json/JsonSlurper.html or JsonPath at https://code.google.com/p/json-path)

To really get operational, we need metrics. Most production systems have metrics in one form or another. Thankfully, we don't have to start from scratch. There is a metric endpoint in Spring Boot Actuator. If we add this following setting to application.properties:

    endpoints.metrics.enabled=true

With this property setting, if we restart the application, we can get a quick read out on thing.

Assuming we have JSON Viewer installed, it's easy to surf to http://localhost:9000/application/metrics and get a listing on all sorts of metrics. We even have counters for every good/bad web hit, broken down on a per-page basis, as shown here:

    {
      "names": [
        "jvm.buffer.memory.used",
        "jvm.memory.used",
        "jvm.buffer.count",
        "logback.events",
        "process.uptime",
        "jvm.memory.committed",
        "jvm.buffer.total.capacity",
        "jvm.memory.max",
        "process.starttime",
        "http.server.requests"
      ]
    }

We can visit any one of these metrics by appending it's name to the metrics URL. For example, to view the http.server.requests, visit http://localhost:9000/application/metrics/http.server.requests:

    {
      "name": "http.server.requests",
      "measurements": [
        {
          "statistic": "TotalTime",
          "value": 3.53531643E8
        },
        {
          "statistic": "Count",
          "value": 57.0
        }
      ],
      "availableTags": [
        {
          "tag": "exception",
          "values": [
            "none",
            "none",
            "none",
            "none"
          ]
        },
        {
          "tag": "method",
          "values": [
            "GET",
            "GET",
            "GET",
            "GET"
          ]
        },
        {
          "tag": "uri",
          "values": [
            "/application/metrics/{requiredMetricName}",
            "/application/metrics/{requiredMetricName}",
            "/application/metrics",
            "/favicon.ico"
          ]
        },
        {
          "tag": "status",
          "values": [
            "200",
            "404",
            "200",
            "200"
          ]
        }
      ]
    }

This provides a basic framework of metrics to satisfy our manager's needs. It's important to understand that metrics gathered by Spring Boot Actuator aren't persistent across application restarts. To gather long-term data, we have to write them elsewhere (http://docs.spring.io/spring-boot/docs/2.0.0.M5/reference/htmlsingle/#production-ready-metrics).