Managed Service for Prometheus:Connect Spring Boot applications to Managed Service for Prometheus

Procedure

For Spring Boot applications, the Spring community provides the out-of-the-box Spring Boot Actuator. Spring Boot Actuator allows developers to instrument applications in an efficient manner and facilitates the collection and exporting of monitoring data. Starting from Spring Boot 2.0, Spring Boot Actuator uses Micrometer, and provides stronger and more flexible monitoring capabilities. Micrometer is a monitoring facade and can be seen as the Simple Logging Facade for Java (SLF4J) for monitoring. You can use Micrometer to connect your applications to various monitoring systems, such as AppOptics, Datadog, Elastic, InfluxDB, and Managed Service for Prometheus.

Micrometer allows you to map the metrics of Java applications to Managed Service for Prometheus. The following table describes the mappings.

• The Counter metric type in Micrometer maps the Counter metric type in Managed Service for Prometheus. This metric type is used to monitor a variable whose value monotonically increases. For example, this metric type can be used to monitor the number of visits to an API, the number of cache hits, or the total number of visits. The Timer metric type provides information provided by the Counter metric type. For example, a metric of the Timer type that is used to collect data about the response time of each API also collects data about the number of visits. You do not need to configure metrics of both types for an API.

• The Gauge metric type in Micrometer maps the Gauge metric type in Managed Service for Prometheus. This metric type is used to monitor variables whose values fluctuate continuously within a value range. For example, this metric type can be used to monitor the CPU utilization or the number of task queues in a thread pool.

• The Timer metric type in Micrometer maps the Histogram metric type in Managed Service for Prometheus. The Timer metric type is used to provide distribution statistics of time-related data, such as the distribution of the response time of an API.

• The DistributionSummary metric type in Micrometer maps the Summary metric type in Managed Service for Prometheus. Similar to the Histogram metric type, the Summary metric type is also used to provide data distribution statistics. However, data distribution statistics are calculated by clients and then stored in Managed Service for Prometheus. Therefore, the results provided by multiple machines cannot be aggregated and an overview of data distribution cannot be provided.

Procedure

If you want to connect a Spring Boot application to Managed Service for Prometheus, you can instrument the application, deploy the application in a Kubernetes cluster, and then configure service discovery.

First, you must add Maven dependencies of Spring Boot Actuator to your code, and register the data you want to monitor, or annotate the methods in the Controller.

Then, you must deploy the instrumented application in a Kubernetes cluster, and expose an endpoint to Managed Service for Prometheus. The service discovery feature of Managed Service for Prometheus pulls monitoring data from the endpoint. Managed Service for Prometheus allows you to configure service discovery by creating ServiceMonitors based on custom resource definitions (CRDs).

After the endpoint of the application is discovered by Managed Service for Prometheus, you can configure a data source and a dashboard on Grafana. You can also configure alert rules for key metrics. You can also configure alert rules for key metrics.

Purposes

You can connect a Spring Boot application in a Kubernetes cluster to Managed Service for Prometheus to achieve the following purposes:

• Monitor the frontend of a system: An application built by using Spring Web MVC provides frontend services, and the rate, errors, and duration (RED) metrics of the application are monitored. Rate refers to the rate at which requests are handled. Errors refer to the number of failed requests. Duration refers to the amount of time that each request takes.

• Monitor objects in the critical paths of the backend service. For example, you can monitor the number of queues in a thread pool, or the cache hit ratio of the Guava Cache.

• Monitor custom metrics that are critical to your business. Example: the UV of an API.

• Monitor garbage collection tasks of a Java virtual machine and the memory usage.

• Aggregate and display the preceding metrics, and configure alert rules for key metrics.

Step 1: Add the dependencies of Spring Boot Actuator and perform initial configurations

In this example, a cloud-native microservice application built by using Spring Boot and Spring Cloud Alibaba is used to describe how to connect a Spring Boot application in a Kubernetes cluster to Managed Service for Prometheus.

1. Run the following code to add the dependencies of Spring Boot Actuator.

   <!-- Spring Boot Actuator dependencies  -->
   <dependency>
       <groupId>org.springframework.boot</groupId>
       <artifactId>spring-boot-starter-actuator</artifactId>
   </dependency>
   <!-- Managed Service for Prometheus dependencies  -->
   <dependency>
       <groupId>io.micrometer</groupId>
       <artifactId>micrometer-registry-prometheus</artifactId>
   </dependency>

2. Add the following configurations to the application.properties file to expose the port that you want to use to export monitoring data. For example, set the port to 8091.

   # Add the following configurations to the application.properties file to expose metrics.
   spring.application.name=frontend
   
   management.server.port=8091
   management.endpoints.web.exposure.include=*
   management.metrics.tags.application=${spring.application.name}

   After the configuration is complete, Managed Service for Prometheus can access port 8091 of the application. Then, Managed Service for Prometheus can obtain the monitoring data in the OpenMetrics format from the /actuator/prometheus path.

Step 2: Instrument and modify the application

To obtain the RED metrics of an API, you can add a @Timed annotation to the method of the API. The following code shows how to add a @Timed annotation to the API of an index page:

@Timed(value = "main_page_request_duration", description = "Time taken to return main page", histogram = true)
@ApiOperation(value = "Main page", tags = {"Main page"})
@GetMapping("/")
public String index(Model model) {
    model.addAttribute("products", productDAO.getProductList());

    model.addAttribute("FRONTEND_APP_NAME", Application.APP_NAME);
    model.addAttribute("FRONTEND_SERVICE_TAG", Application.SERVICE_TAG);
    model.addAttribute("FRONTEND_IP", registration.getHost());

    model.addAttribute("PRODUCT_APP_NAME", PRODUCT_APP_NAME);
    model.addAttribute("PRODUCT_SERVICE_TAG", PRODUCT_SERVICE_TAG);
    model.addAttribute("PRODUCT_IP", PRODUCT_IP);

    model.addAttribute("new_version", StringUtils.isBlank(env));
    return "index.html";
}

If your application uses an in-process cache library, for example, the Guava Cache library, and you want to monitor the health of the in-process cache, you can encapsulate the key objects to be monitored by using the modification method provided by Micrometer.

Modify Guava Cache

1. Inject MeterRegistry. In this example, PrometheusMeterRegistry is automatically injected by Spring Boot.

2. Use a utility class API to encapsulate the local cache. In this example, GuavaCacheMetrics.monitor is used.

3. Enable caching for data records by using the .recordStats() method.

4. Specify a name for the cache. The name is used in metrics that are generated.

Modify the thread pool

1. Inject MeterRegistry. In this example, PrometheusMeterRegistry is automatically injected by Spring Boot.

2. Use a utility class API to encapsulate the thread pool.

3. Specify a name for the thread pool. The name is used in metrics that are generated.

Many custom metrics that are critical to your business require monitoring in the development process. To monitor these metrics, you can inject the MeterRegistry into a bean, and configure metrics of the Counter, Gauge, or Timer types based on your business requirements and the scenarios. Then, you can register these metrics to MeterRegistry to expose the metrics. The following code provides an example:

@Service
public class DemoService {

    Counter visitCounter;

    public DemoService(MeterRegistry registry) {
        visitCounter = Counter.builder("visit_counter")
            .description("Number of visits to the site")
            .register(registry);
    }

    public String visit() {
        visitCounter.increment();
        return "Hello World!";
    }    
}

After you complete the preceding steps, the application code is modified. Then, you must rebuild and deploy the application image in the Kubernetes cluster for which Managed Service for Prometheus is enabled, and configure a ServiceMonitor in the Managed Service for Prometheus console to discover the Service that corresponds to the application. For more information, see Create a Prometheus instance to monitor an ACK cluster and Manage service discoveries.

After the ServiceMonitor is configured, you can view the newly registered Service on the Targets tab of the Service Discovery page.

Step 3: Configure dashboards

After the monitoring data of the application is collected and stored in Managed Service for Prometheus, you can configure dashboards and alert rules for the monitoring data. The following two open-source dashboard templates are provided by the Grafana community. You can use these templates to create custom dashboards for your business.

• Spring Boot 2.1 Statistics

• JVM (Micrometer)

You can use the preceding templates and the Grafana service provided by Managed Service for Prometheus to display key metrics on a Grafana dashboard. This helps you facilitate development and O&M. You can also create custom dashboards for daily monitoring. The following figure shows a dashboard that is built based on the preceding templates and business requirements. The dashboard provides an overview and metrics such as the running duration of components, memory usage, heap memory usage and non-heap memory usage, and garbage collection data about different generations.