How does Spring Boot monitor?

If any service is not monitored, it will be smeared, unable to know the current operation of the service, and it will not be able to handle the possible abnormal conditions well. Therefore, monitoring is essential for any service. Less.

At present, most microservice applications are built based on SpringBoot, so it is very necessary to understand the monitoring features of SpringBoot, and SpringBoot also provides some features to help us monitor applications.

This article is based on the SpringBoot 2.3.1.RELEASE version demo.

SpringBoot monitoring

Monitoring in SpringBoot can be divided into HTTP endpoints and JMX to monitor the running status of the current application and collect metrics.

| HTTP Endpoints Monitoring

Actuator endpoints allow you to monitor and interact with your application. SpringBoot includes many built-in endpoints and allows us to add our own. Each endpoint can be enabled or disabled via HTTP or JMX and exposed (making it remotely accessible).

Each endpoint has a unique id, which can be accessed through the following address: http:ip:port/{id} (SpringBoot 1.x).

In SpringBoot 2.x version, a new /actuator is added by default as the basic road, and the access address corresponds to: http:ip:port/actuator/{id}.

Using HTTP monitoring is very simple. In the SpringBoot project, the following dependencies are introduced:


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



The basics of Spring Boot will not be introduced, but this practical tutorial is recommended:

https://github.com/javastacks/spring-boot-best-practice

By default, it can be accessed through the address http:localhost:8080/actuator/health, and the following results are obtained after access:

SpringBoot provides a lot of default endpoint monitoring, but for security reasons, some endpoints are not enabled by default, such as the shutdown endpoint is closed by default.

Built-in endpoint

Common built-in endpoints provided by default in SpringBoot are as follows:

Although most of the endpoints here are enabled by default, only the health and info endpoints are exposed by default (allowing external access), so if you need to allow endpoints to be exposed externally, you can configure the following (if you want to expose all endpoints, then "*" can be configured directly):

management:
endpoints:
web:
exposure:
include: [health,info,mappings] //Or directly configure "*"

In addition, enabling or disabling an endpoint can also be dynamically controlled through the following configuration:
management.endpoint..enabled=true

Next, we select a few key endpoints to introduce.

health endpoint

The health breakpoint only displays the current application health information by default, but we can open the detailed information through another configuration, which will not only monitor the current application, but also monitor other third-party applications related to the current application, such as Redis.

management:
endpoint:
health:
show-details: always

After this configuration is turned on, we connect to Redis and visit the health endpoint again to display the health information of the Redis service:

loggers endpoint
You can view information such as the log level of the current application:

This is not special in itself, but there is a function that is very useful. For example, the log level of our production environment is generally info, but now there is a bug that cannot be checked through the info level, so we can temporarily modify the log level.

For example, the ROOT node in the above figure is at the info level, then we can send a post request to modify the log level through tools such as postman.

metrics endpoint

Metrics is a very important monitoring endpoint. Its monitoring content covers some important indicators such as JVM memory, heap, class loading, processor and tomcat container:

It can be seen that there are a lot of indicators, and you can view the corresponding indicator information by accessing any indicator.