How to Quickly Access Prometheus Monitoring for Spring Boot Applications

How to quickly access Prometheus monitoring for Spring Boot applications

SpringBoot The development, release and deployment of microservices only account for a small part of its life cycle , and application and system operation and maintenance are the top priority. In the operation and maintenance process , monitoring work plays an important role. So, in order to continuously observe the state of the system, how can we quickly implement Prometheus monitoring access for Spring Boot applications. This article explains the complete access process and access matters in detail!
For developers, most of the bad experience behind MVC applications with traditional SSM structure comes from a large number of configurations when building projects, and a little carelessness may lead to pitfalls. In order to solve the above problems, Spring Boot came into being. As its name suggests, the core value of Spring Boot is automatic configuration. As long as the corresponding jar package exists, Spring can automatically configure it. If the default configuration does not meet your needs, you can also replace the automatic configuration class and use custom configuration to quickly build enterprise-level applications.


Spring Boot applications.But building a Spring Boot application is only the first step. After the application is launched, how should we monitor it?

Spring Boot applications.Basic knowledge and concepts

First of all, before the formal explanation, I will explain to you the basic knowledge and concepts required for this sharing. Generally speaking, building a complete and easy-to-use monitoring system mainly includes the following key parts.

Spring Boot applications.Collect monitoring data

Spring Boot applications.At present, the common methods of collecting monitoring data in the industry are mainly divided into two modes: Push and Pull. Taking the increasingly widely used Prometheus monitoring system as an example, Prometheus is a typical system running in the pull mode. Application and infrastructure monitoring data is exposed to Prometheus in the form of the OpenMetrics standard interface, which is periodically captured by Prometheus and stored for a long time.

Here is a brief introduction to OpenMetrics . As a cloud-native and highly scalable indicator protocol, OpenMetrics defines the de facto standard for large-scale reporting of cloud-native indicators, and supports text representation protocol and Protocol Buffers protocol. Text representation protocol is more common among them, and it is also used for data capture in Prometheus. The protocol used by default. The following figure is an example of a metric representation format based on the
OpenMetrics format.

Spring Boot applications.The data model of the metric is defined by the metric name and a set of key/value labels (Label), with the same metric name and labels belonging to the same time series set. For example , acme_http_router_request_seconds_sum{path="/api/v1",method="GET"} can indicate that the index name is acme_http_router_request_seconds_sum , and the label method value is the one-time sampling point data of POST. The sample point contains a float64 value and a millisecond UNIX timestamp. Over time, these collected sample point data will draw dynamically changing lines on the chart in real time.

Spring Boot applications.At present, for most of the basic components under the cloud native system, most of them can support exposing indicators in the above-mentioned OpenMetrics text protocol format. Used by developers and operators . These components (or Exporter) record their own health status to Prometheus in time by responding to periodic fetch requests from Prometheus for subsequent processing and analysis. For application developers, they can also use the Prometheus multi-language SDK to bury their code and integrate their own business indicators into the above-mentioned Prometheus ecosystem.

Spring Boot applications.Data visualization and analysis

Spring Boot applications.After obtaining intuitive information such as application or infrastructure running status, resource usage, and service running status , it is convenient to track and compare nodes by querying and analyzing multi-type and multi-dimensional information. At the same time, the current operating status of the system is known through a standard and easy-to-use visual dashboard. The most common solution is Grafana. As a popular data visualization solution in the open source community, Grafana provides rich chart forms and templates. In Alibaba Cloud's ARMS Prometheus monitoring service, Grafana also provides users with a fully managed version of monitoring data query, analysis and visualization.

Timely alerts and emergency management

When the business is about to fail, the monitoring system needs to respond quickly and notify the administrator, so that the problem can be dealt with quickly or the occurrence of the problem can be prevented in advance to avoid the impact on the business. When the problem occurs, the administrator needs to claim and deal with the problem. Through the analysis of different monitoring indicators and historical data, root causes can be found and resolved.

Spring Boot applications.Overview of the access process



how to access Prometheus for Spring Boot microservice applications deployed on Kubernetes clusters . For Spring Boot applications, the community provides an out-of-the-box Spring Boot Actuator framework, which is convenient for Java developers to track code and monitor data collection and output. Starting from Spring Boot 2.0, Actuator changed the bottom layer to Micrometer, providing stronger and more flexible monitoring capabilities. Micrometer is a monitoring facade, which can be compared to Slf4j in the monitoring world. With Micrometer, applications can connect to various monitoring systems, such as: AppOptics , Datadog, Elastic, InfluxDB , etc., of course, including the Prometheus we introduced today.

Micrometer supports application developers to map with three types of semantics when connecting Prometheus metrics to Java application metrics:



•MicroMeter corresponds to the Counter in Prometheus, which is used to describe a monotonically increasing variable, such as the number of accesses to an interface, the total number of cache hits/accesses , etc. Timer contains Counter logically, that is, if Timer is used to collect the response time of each interface, the number of accesses must also be collected. Therefore, it is not necessary to specify both Timer and Counter indicators for an interface at the same time.

•MicroMeter corresponds to Gauge in Prometheus and is used to describe variables that fluctuate continuously in a range, such as CPU usage, thread pool task queue number, etc.

•MicroMeter corresponds to the Histogram in Prometheus, which is used to describe time-related data, such as the time distribution of an interface RT and so on.

•DistributionSummary in Micrometer corresponds to the Summary in Prometheus. Similar to the Histogram, the Summary is also used for statistical data distribution, but since the data distribution is sent to Prometheus for storage after the client's calculation is completed, the results of the Summary cannot be stored in multiple Data aggregation is performed between multiple machines, and the data distribution of the global view cannot be counted, which has certain limitations in use.

When we need to connect the Spring Boot application deployed in the Kubernetes cluster to Prometheus, we need to follow the process of code embedding -> deploy application -> service discovery.

First, we need to introduce Spring Boot Actuator-related maven dependencies into the code, and register the data we need to monitor, or annotate the methods in the Controller with responsive annotations.

Second, we deploy the embedded application in Kubernetes, and register with Prometheus the endpoint that pulls monitoring data from the application (that is, Prometheus service discovery). Alibaba Cloud Prometheus service provides a method to use ServiceMonitor CRD for service discovery.

Finally, after the monitoring and collection endpoint of the target application is successfully discovered by Prometheus, we can start to configure the data source and the corresponding large disk on Grafana. Of course, we also need to configure corresponding alarms according to some key indicators. These requirements can be easily met by the Alibaba Cloud Prometheus monitoring service.


Spring Boot applications.Detailed access process



Next, we enter the actual combat exercise. Here we select a cloud-native microservice application ( https://github.com/aliyun/alibabacloud-microservice-demo ) based on Spring Boot & Spring Cloud Alibaba as the baseline for our transformation.


Our ultimate goal is to:


1. The entrance of the monitoring system: Frontend service is an entrance application developed based on SpringMVC , which undertakes external customer traffic. We mainly focus on the key RED indicators of the external interface (call rate Rate, number of failures Error, request duration);
2. Monitor the key links of the system: monitor the objects on the critical path of the back-end service, such as the queue status of the thread pool and the hit status of the Guava Cache in the process;
3. Custom indicators that are strongly related to the business (such as the UV of an interface, etc.);
4. Monitor JVM GC and memory usage;
5. Perform unified aggregation and display of the above indicators, and configure alarms for key indicators.

The first step is to introduce Spring Boot Actuator dependencies for initial configuration

First, we need to introduce the relevant dependencies of Spring Boot Actuator and expose the monitoring data port (defined here as 8091) in the application.properties configuration. After success, we can access the /actuator/ prometheus path of the 8091 port of the application to get the monitoring data of the OpenMetrics standard.



org.springframework.boot
spring-boot-starter-actuator



io.micrometer
micrometer-registry-prometheus


# application.properties add the following configuration to expose metrics
spring.application.name=frontend

management.server.port = 8091
management.endpoints.web.exposure.include = *
management.metrics.tags.application =${ spring.application.name }

The second step, code embedding and transformation

In order to obtain the RED indicator of an Api interface, we need to annotate the corresponding interface method with the following @Timed annotation. Let's take the index page interface in the demo project as an example. Note that the value in the @Timed annotation is the name of the indicator exposed to /actuator/ prometheus , and histogram=true means that we expose the histogram histogram type indicator of the request duration of this interface, which is convenient for us to calculate the time distribution of requests such as P99 and P90 in the future. Condition.


@ Timed( value = " main_page_request_duration ", description = "Time taken to return main page", histogram = true)
@ ApiOperation (value = "Homepage", tags = {"Homepage operation 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 our application uses an in-process cache library, such as the most common Guava Cache library and so on. If we want to track the running status of the in-process cache, we need to encapsulate the key objects to be monitored according to the decoration methods provided by Micrometer.

•The Guava Cache transformation mainly consists of four steps. The code changes are relatively small and can be easily accessed:

1. Inject MeterRegistry , the specific implementation injected here is PrometheusMeterRegistry , which can be injected by Spring Boot itself
2. Use the tool class api , that is, the GuavaCacheMetrics.monitor shown in the figure to wrap the local cache
3. Turn on the cache data record, that is, call the .recordStats () method
4. Add a name to generate the corresponding indicator.

•The thread pool transformation is mainly three steps, and it is not very complicated:


1. Inject MeterRegistry , the specific implementation injected here is PrometheusMeterRegistry ;
2. Use the tool class API to wrap the thread pool;
3. Add a name to generate the corresponding indicator.


Of course, we must have many custom indicators that are strongly related to business in the development process. In order to monitor these indicators, after injecting MeterRegistry into the bean, we need to construct Counter, Gauge or Timer (these types) according to our needs and corresponding scenarios. The difference and usage scenarios are mentioned above) to conduct data statistics, and register it with the MeterRegistry for indicator exposure. The following is a simple 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!";
}
}


So far, our application code transformation work has been completed here. The next step is to rebuild and redeploy the application image to the Kubernetes cluster where ARMS Prometheus has been installed. After that, we configure ServiceMonitor in the ARMS Prometheus console for service discovery.

adding ServiceMonitor , we can see the newly registered application Service in the Targets list.


The third step, Kanban configuration

The monitoring data of the application has been successfully collected and stored in ARMS Prometheus. The next and most critical step is to configure the corresponding dashboards and alarms based on these data. Here, we use the open source template in the Grafana community to build our own business monitoring template. Mainly based on the following two templates:


•Spring Boot 2.1 Statistics:
https://grafana.com/grafana/dashboards/10280

•JVM (Micrometer):
https://grafana.com/grafana/dashboards/4701

With these templates and the built-in Grafana service of ARMS Prometheus, we can easily organize the metrics that we care about in the daily development and operation and maintenance process on a single Grafana Dashboard. Here, I will give you some ideas, and put a real big market that we built based on the above templates and our own business. This includes some overviews , such as component running time, memory usage, etc., as well as some detailed indicators, such as on-heap and off-heap memory, generational GC status, etc., as well as RED for interface requests, etc., here But to repeat, you can give full play to your imagination to create a unique and cool market~


Related Articles

Explore More Special Offers

  1. Short Message Service(SMS) & Mail Service

    50,000 email package starts as low as USD 1.99, 120 short messages start at only USD 1.00