“Spring Boot Actuator in Detail and In-depth Application” is expected to include three chapters. The first chapter focuses on the application and customization of Spring Boot Actuator 1.x. In the second part, compare the differences between Spring Boot Actuator 2.x and 1.x, and apply and customize 2.x endpoints. In chapter 3, the use of Actuator Metric metrics in conjunction with Prometheus and Grafana will be described. This part of the content is very common, and more introductory, welcome your attention.

These reviews

This article is the third part of “Spring Boot Actuator In Detail and In-depth Application”. In the first two articles, we mainly covered the application and customization of endpoints of Spring Boot Actuator 1.x and 2.x. Compared with Actuator 1.x, Spring Boot 2.0-based Actuator 2.x has significant changes in usage and customization, and more flexibility for expansion. Readers are advised to keep an eye out for the trend in Spring Boot 2.x.

The Actuator provides endpoints to expose the data, and we obtain the data for analysis, but only in this way, it is not intuitive or convenient for us to analyze. In microservice architectures, the number of microservice instances is often very large. Data visualization is what we have always expected. Spring Boot Admin provides support for Spring Boot’s EXOskeleton-endpoint UI and also provides some support for Spring Cloud. In this article, the use of Spring Boot Admin will be compared, and then the monitoring of Spring Boot 2.x applications: Actuator + Prometheus + Grafana.

Apply Spring Boot Admin

Spring Boot Admin is a Web application for managing and monitoring Spring Boot applications. Each application is treated as a client and registered with the administration server. The implementation principle is based on the endpoints provided by Spring Boot Actuator.

In this section, we describe the steps to configure the Spring Boot Admin server and how the application becomes a client.

Admin Server

Introduction of depend on

First, we need to introduce related dependencies:

        <dependency>
            <groupId>de.codecentric</groupId>
            <artifactId>spring-boot-admin-server</artifactId>
            <version>2.0.1</version>
        </dependency>
        <dependency>
            <groupId>de.codecentric</groupId>
            <artifactId>spring-boot-admin-server-ui</artifactId>
            <version>2.0.1</version>
        </dependency>
Copy the code

Admin-server and admin-server-UI were introduced, respectively.

Configure the Admin Server

Adding the @enableadMinServer annotation to the entry of the application will enable the service.

server:
  port: 8088

management:
  endpoints:
    web:
      exposure:
        include: "*"
  endpoint:
    health:
      show-details: always
Copy the code

Admin UI

Open http://localhost:8088/, we can see the following interface:

Now let’s register the client service to the Admin Server.

Admin Client

Introduction of depend on

        <dependency>
            <groupId>de.codecentric</groupId>
            <artifactId>spring-boot-admin-starter-client</artifactId>
            <version>2.0.1</version>
        </dependency>
Copy the code

Add admin Client dependencies in each service.

Configure the Admin Client

server:
  port: 8081

spring:
  application:
    name: admin-client

---
spring.boot.admin.client.url: "http://localhost:8088"
management.endpoints.web.exposure.include: "*"
---
management:
  endpoint:
    health:
      show-details: always
      defaults:
        enabled: true

eureka.client.serviceUrl.defaultZone: http://localhost:8761/eureka/
Copy the code

We specified the Admin Server address http://localhost:8088. All the endpoints of the Actuator are exposed and the health check details are displayed.

After the above configuration, a simple Admin Server and Client are set up.

UI

When our client registers with Admin Server, open the Admin interface, you can see the following information screenshot:

Using service discovery

In the example above, we configure Admin Server by specifying the URL. In a microservice cluster, services are typically registered with the service discovery and registration component. We can easily implement client registration by introducing existing components such as Eureka, Consul, etc.

Implementation here skipped, interested readers can see GitHub source: github.com/keets2012/S…

Monitored using Prometheus and Grafana

The information collected by the Actuator is stored in Prometheus for statistics, and Grafana provides a friendly interface display. Here we show you how to integrate these three components for application service and system monitoring.

Expose Prometheus endpoints

On the basis of the previous, we increase the dependence of Micrometer:

<dependency>
    <groupId>io.micrometer</groupId>
    <artifactId>micrometer-registry-prometheus</artifactId>
</dependency>
Copy the code

Expose the endpoints and add the following configuration:

management:
  metrics:
    export:
      prometheus:
        enabled: true
        step: 1m
        descriptions: true
  web:
    server:
      auto-time-requests: true
  endpoints:
    prometheus:
      id: springmetrics
    web:
      exposure:
        include: health,info,env,prometheus,metrics,httptrace,threaddump,heapdump,springmetrics

server:
  port: 8082
Copy the code

Prometheus is introduced

Prometheus, a system and service monitoring system, is a project of the Cloud Native Computing Foundation. The way it works is that the monitored service needs to expose a Prometheus endpoint, an HTTP interface that exposes a list of metrics and current values, from which Prometheus periodically pulls data, typically stored in a sequential database, The data is then presented via visual dashboards such as Grafana.

Prometheus features:

  • Dimensional data model (time series defined by measure name and key/value dimension set)
  • Flexible query languages to take advantage of this dimension
  • Not dependent on distributed storage; Individual server nodes are autonomous
  • Time series collection occurs through pull Models over HTTP
  • Push time series are supported through an intermediate gateway
  • Discover targets through service discovery or static configuration
  • Multiple modes of graphics and dashboard support
  • Support for hierarchical and horizontal federation

Support for Prometheus Metrics, such as Counter, Gauge, Histogram, Summary, etc. It should be noted that counter can only be increased and cannot be decreased, which is applicable to the statistics of service request volume and user access number, etc. However, Gauge is needed for the statistics of increasing and decreasing indicators. Support many, you can easily monitor a lot of applications, but also can customize the development of unofficial offers.

Install the Prometheus

Can be directly installed through compression, the author lazy directly use docker image.

docker run -it -p 9090:9090 -v /etc/spring-boot-samples/spring-boot-actuator-prometheus/src/main/resources/prometheus.yml:/etc/prometheus/prometheus.ym l prom/prometheusCopy the code

Configure the Prometheus file as follows:

Prometheus global configuration item
global:
  scrape_interval:     15s # Set the data capture period, default is 1min
  evaluation_interval: 15s Set the interval for updating the rules file. Default is 1min
  scrape_timeout: 15s # set the timeout period for fetching data. Default is 10s
  external_labels: # Additional attributes will be added to pull data and stored in the database
   monitor: 'codelab_monitor'


# Alertmanager configuration
alerting:
 alertmanagers:
 - static_configs:
   - targets: ["localhost:9093"] Set the interface between AlertManager and Prometheus, i.e. the IP address and port monitored by AlertManager

The # rule configuration is loaded by default for the first read and then at an interval set by evaluation_interval
rule_files:
 - "alertmanager_rules.yml"
 - "prometheus_rules.yml"

# scape configuration
scrape_configs:
- job_name: 'prometheus' # job_name is written to timeseries labels by default and can be used for queries
  scrape_interval: 15s Fetch cycle, default is global
  static_configs: Static configuration
  - targets: ['localdns:9090'] The address of the instance item from which Prometheus captures data

- job_name: 'example-random'
  static_configs:
  - targets: ['localhost:8082']
Copy the code

The above is the configuration file for Prometheus, and port 8082 is the port of the application started in the previous section. Port 9090 for Prometheus. In addition, the Alertmanager is configured for email alarms.

Grafana introduction

Grafana is an open source Dashboard presentation tool that supports many major data sources, both sequential and non-sequential. Its display configuration and extensible performance meet most of the time series data display requirements, is a relatively excellent tool. Supported data sources include Prometheus, Zabbix, ElasticSearch, mysql, and openTSDB.

The installation

Grafana is also installed using the docker image, execute the following startup command:

docker run -d -p 3000:3000 grafana/grafana
Copy the code

Add Prometheus data source as follows:

Configure the data source:

Configuration Dashboard:

Statistics interface

After the above configuration, we can see the following statistical graph:

Of course, we can also install plug-ins, as follows:

The figure above shows some plugins configured by the author, such as Zabbix, K8S, etc. The configurations are relatively simple and are not listed here.

For the code and script designed in this section, see github.com/keets2012/S…

conclusion

This article is relatively simple, mainly describes the monitoring application of the combined Actuator. First, it describes the application of Spring Boot Admin and gives an example program. I then covered integration monitoring using Prometheus + Grafana. In general, the latter approach is more powerful, more professional, and supports richer data sources, so readers can try it on their own.

Subscribe to the latest articles, welcome to follow my official account

reference

  1. grafana docs
  2. Prometheus + Grafana + SpringBoot2 monitors the integration configuration