preface

When I saw the Framework that operates in Spring Boot, I wondered: What does it do? While it is known that it provides a number of endpoints to help with application monitoring and management, it is difficult to be persuasive without a direct practice case.

It was not until the previous article microservices Architecture: Nacos Local Cache PK Microservices Elegant offline that the endpoint defined in the Actuator can be used to achieve the elegant offline effect of microservices that we found to be really useful.

This article expands based on how the Spring Boot system integrates Actuator, how to use it, and how to customize an Endpoint.

Introduction to Spring Boot Actuator

Spring Boot provides a function module for introspect and monitoring of application systems, enabling developers to view, collect statistics, audit, and collect monitoring indicators of application systems. Actuator provides the ability to manage and monitor applications based on Http endpoints or JMX.

How does it differ from the @Controller external service provided by Spring Web? Both allow external access to the application via Http, but the functionality is defined at different boundaries. As mentioned above, the use of Actuator is usually used to monitor and operate the application itself, while @Controller is more of a business application. By comparing this with @controller, you might be able to better understand the function of the Actuator.

Default functions of THE Actuator

The DEFAULT REST interfaces provided by THE Actuator provide an easy way to understand the health of applications. Some ports are sensitive and can be accessed only with the specified permission.

Using the Actuator, you can monitor application Health information, APPLICATION Info, HTTP Request tracking information, Metrics information, @RequestMapping path information, application configuration information, and application Request count and time.

I will not explain the specific endpoints here, because there are some differences between different versions. First take a look at all the endpoint is opened, and then visit http://localhost:8080/actuator to see the endpoint information.

Use the same approach to see which endpoints are included in the version you are using.

Spring Boot integration

Integrating Spring Boot Actuator with the Spring Boot project is convenient by adding a dependency to the POM file:

<dependency>
    <groupId>org.springframework.boot</groupId>
    <artifactId>spring-boot-starter-actuator</artifactId>
</dependency>
Copy the code

Spring Boot 2.2.2.RELEASE is used here. Start the project, visit http://localhost:8080/actuator can see now can access the port list information:

{
"_links": {
"self": {
"href": "http://localhost:8080/actuator",
"templated": false
},
"health-path": {
"href": "http://localhost:8080/actuator/health/{*path}",
"templated": true
},
"health": {
"href": "http://localhost:8080/actuator/health",
"templated": false
},
"info": {
"href": "http://localhost:8080/actuator/info",
"templated": false
}
}
}
Copy the code

As you can see, the current version supports the self, health-path, health, and INFO endpoint information by default, and the rest of the information is not open to the public.

At this point, if you want to see all endpoints like the one mentioned earlier, you can do the following configuration in the Application configuration file:

management:
  endpoints:
    web:
      exposure:
        include: '*'
    jmx:
      exposure:
        include: '*'
Copy the code

So you can see all the endpoints. This method only works for versions of Spring Boot after 2.0. Note that the * in the configuration requires single or double quotation marks.

In addition, this form of configuration is not recommended. This exposes all endpoints without permission verification. The recommended pattern is to specify which endpoints to use directly in the include. At the same time, sensitive operations need to be authenticated.

The configuration format is as follows:

management:
  endpoints:
    web:
      exposure:
        include: health,info
    jmx:
      exposure:
        include: health,info
Copy the code

Use commas (,) to separate endpoints.

Data structure for the Endpoint

We started by looking at the data structure returned by /actuator, which is the information of the endpoint self. In/physical return information can also be seen in other accessible endpoint address, here at http://localhost:8080/actuator/health, for example, structure is as follows:

{
"status": "UP"
}
Copy the code

The result returned by the endpoint is in JSON format, and the status returned above is UP, which means the system is healthy. Of course, for other endpoint access, the results are pretty much the same, so I won’t show you all of them here.

Stop taking action

In the above endpoints, you will find that there is no endpoint that closes the service. Yes, by default, operations that affect services such as shutdown are not enabled even if include is set to *.

For this type of operation, we first set it available:

management:
  endpoint:
    shutdown:
      enabled: true
  endpoints:
    web:
      exposure:
        include: '*'
    jmx:
      exposure:
        include: '*'
Copy the code

At this point, and then access/physical can see the corresponding path/shutdown endpoint http://localhost:8080/actuator/shutdown.

Send a post request to the endpoint using the curl command or postman:

curl -X "POST" "http://localhost:8080/actuator/shutdown"
Copy the code

Upon execution, the service was found to be shut down. There are many operations similar to stopping a server, such as restart, pause, restart, and so on. The configuration depends on the version. Currently, only shutdown endpoint is found, and no configuration items for endpoints such as restart, pause, and restart are found.

In this way, the SpringBoot application can be shut down gracefully, but there is a big security risk. If you know the IP and port number, you can simulate the request to stop service, so you need to add some security restrictions.

  • Management endpoints. Web. Base – path custom shutdown request path;
  • Management server. The IP address is set to local, prevent the remote access to close the connection service;
  • Manage.server. port Specifies the port number of the shutdown request path.

The modified configuration file is as follows:

management: endpoint: shutdown: enabled: true endpoints: web: exposure: include: '*' jmx: exposure: include: '*' server: # custom port: 8080 # Remote admin connection not allowed for security concerns address: 127.0.0.1Copy the code

If that doesn’t work for you, consider introducing spring-boot-starter-security, which allows users to access Endpoints using user names and passwords. Spring Security will not be extended in this article.

Custom Endpoint

The default endpoint can meet most requirements, but some special requirements require the ability to support custom endpoints. To customize an Endpoint, simply use the @endpoint annotation on our new Bean, and the methods in the Bean can be exposed via JMX or HTTP. In addition, you can also write an EndPoint using @jmxEndpoint or @webEndpoint. But these endpoints are limited to their own way of being exposed. For example, @webendpoint is exposed only through HTTP, not through JMX.

Do all methods in a class support disclosure? Clearly not. Only three annotated methods are allowed to be exposed, and each annotation has an HTTP method that supports it.

@readOperation corresponds to HTTP GET requests, @WriteOperation corresponds to HTTP POST requests, and @deleteOperation corresponds to HTTP DELETE requests.

Here’s a simple example:

@Component @Endpoint(id = "my") public class EndpointCustom { @ReadOperation public String endpointCustomRead(String Content) {return "requested content:" + content; } @writeOperation public String endpointCustomWrite(String content) {return "Write content:" + content; } @deleteOperation public String endpointCustomDelete(String Content) {return "Delete content:" + content; }}Copy the code

Corresponding to GET request:

curl -X GET http://localhost:8080/actuator/my? content=endpointGetCopy the code

After execution, the message “Requested content: endpointGet” is returned.

The same POST request is:

curl -X POST http://localhost:8080/actuator/my? content=endpointPostCopy the code

The DELETE request is:

curl -X DELETE http://localhost:8080/actuator/my? content=endpointDELETECopy the code

The above is a simple custom instance, but depending on your business scenario, you can define richer endpoint implementations.

summary

In this article, we learned the basic operation of the Spring Boot integration that operates. Integration is very simple because Spring Boot already does most of the work for us and we just need to configure it accordingly. Specialization can also be implemented in the form of customization in cases where pre-defined endpoints do not meet business requirements. The most important point in learning the Actuator is to know the scenarios in which it is used.

This article complete source address: github.com/secbr/sprin…

Author of SpringBoot Tech Insider, loves to delve into technology and write about it.

Official account: “Program New Horizon”, the official account of the blogger, welcome to follow ~

Technical exchange: please contact the blogger wechat id: Zhuan2quan