Today’s sharing started, please give us more advice ~

Pre

With the introduction of the Actuator component, we add system monitoring to the Spring Boot application. Based on the various HTTP endpoints exposed by the Actuator, developers can obtain the system’s runtime state. Endpoints are a low-level monitoring technology that requires some understanding of the HTTP protocol and how Spring Boot applications are built.

So, is there an easier, visuality-based way to get the information behind these endpoints? We will introduce the Spring Boot Admin component.

Introduce the Spring Boot Admin component

Spring Boot Admin is an application for monitoring Spring Boot. Its basic principle is to provide concise visual WEB UI by counting and integrating various HTTP endpoints provided by Spring Boot Actuators, as shown in the figure below

From the figure above, we can see that there are two roles in the overall architecture of Spring Boot Admin, namely, the Server component Admin Server and the Client component Admin Client. The Admin Client is actually a normal Spring Boot application, while the Admin Server is a standalone service that needs to be built specifically.

Next, let’s look at two implementations of building Admin Server:

  • One is a simple Admin service based on its own.

  • The other is more complex and relies on the service registry’s service registration and discovery mechanism.

Build Admin Server based on standalone services

Regardless of how Admin Server is implemented, first we need to create a Spring Boot application and add the following dependencies to the POM file:

Please note: The Spring Boot Admin component is not officially provided by the Spring family but comes from a codecentric AG team.

If we want to turn a normal Spring Boot application into a Spring Boot AdminServer, all we need to do is add an @enableadMinServer annotation to the Bootstrap class. The BootStrap class with the annotation added looks like this:

As you can see from the figure, there are currently no applications associated with the Admin Server. If we want to associate the application with the Admin Server, we also need to make some changes to the existing Spring Boot application.

First, we introduce a dependency on the Spring Boot Admin Client component in the Maven dependency, as shown in the following code:

We then add the following configuration information to the configuration file so that the application can be associated with the Admin Server.

Note: 9000 here is the Server port of Admin Server.

Now we start the application and see that the name and address of the application already appear in the Admin Server.

Build the Admin Server based on the registry

Although it is easy to build Admin Server and Admin Client based on separate services, we need to add a Maven dependency on Spring Boot Admin and specify the Admin Server address in each application. This is actually code intrusion, meaning there is a strong coupling between the application and the Admin Server.

So is there a better way to separate or shift the coupling?

Thinking of the need to establish a service registrie-like relationship between Admin Server and Admin Client, we can think of this as a manifestation of the service registration and discovery mechanism.

In the Spring family, there is a Spring Cloud framework for building microservices architecture, and in this framework there happens to be a dedicated component for service registration and discovery — Service registry Spring Cloud Netflix Eureka. And Spring Boot Admin has built in seamless integration with this registry implementation tool.

Based on the registry, the interaction between the Admin Server and each Admin Client is shown as follows:

The process of building a registry using Eureka is also simple. First we create a standalone Spring Boot application and add Maven dependencies to the POM file to provide Eureka server functionality as shown below:

With Maven dependencies introduced, we can create a Boot class for Spring Boot. In the sample code, we name the startup class EurekaServerApplication, as follows:

Note: In the above code, we added an @enableeurekaserver annotation to the startup class. In SpringCloud, a service with the @enableeurekaserver annotation is a Eureka server component. Thus, the Eureka service is built.

Also, the Eureka service provides us with a visual UI interface that can be used to view the application information currently registered with Eureka, as shown in the following figure:

Next, we need the Admin Server to adjust accordingly. First, we add a dependency on the Spring-cloud-starter-Netflix-Eureka-client eureka client component to the POM file:

In this case, the Admin Server acts as the Eureka client, so we need to add the @enableEurekaclient annotation to its BootStrap class to register the Admin Server with Eureka.

The final step in reconstructing the Admin Server is to adjust the configuration information. In this case, we need to add the following configuration items to the configuration file to specify the Eureka Server address.

Ok, now that the Admin Server has been refactored, let’s take a look at the Admin Client.

The purpose of introducing a registry is to decouple the Admin Client from the Admin Server, as evidenced by Maven dependencies. With the registry in place, the Admin Client no longer relies on the Spring-boot-admin-starter-client component and instead uses the Eureka Client component shown below.

In the configuration file, we need to remove the reference to the Admin Server address and directly use the Eureka Server address without changing the Bootstrap class in the Admin Client.

With the above adjustments, each Admin Client can be associated with the Admin Server through the Eureka registry.

Use the Admin Server to monitor the system

According to Spring Boot Admin’s official Github, the Admin Server monitoring system provides a complete set of visualization solutions. Based on Admin Server, health, JVM, memory, Micrometer metrics, threads, HTTP tracing, and other core functions can be presented through a visual UI.

Monitor key indicators during system operation

Note that there is a “Wallboard” in the Admin Server menu. Click on this menu to see an app wall, as shown below:

Click on an application in the app wall, and we can enter the main interface of monitoring information for the application. On the left side of the interface, there are directories at all levels of monitoring function, as shown in the figure below:

If so, see if you can

In the figure, we see the most important “Health” information, which obviously comes from the Health endpoint of Spring Boot Actuator components.

Further down the page, we see some JVM-related monitoring information, such as useful threads, garbage collection, memory state, and so on, as shown in the following figure:

This JVM data is presented visually and updated in real time as the runtime state changes.

Metrics in Spring Boot Actuator, and in Admin Server, there is also a “Metrics” menu, as shown below:

From the “Metrics” menu, developers can filter through various criteria and then add corresponding Metrics. For example, in the figure above, we filter the /actuator/ Health endpoints in HTTP requests to get the measurements.

Let’s take a look at the system environment attributes. Because there are so many attributes, Admin Server also provides a filter, as shown in the following figure:

In the figure above, by entering the “spring.” parameter, we get a set of environment properties associated with that parameter.

Logging is also an important way to monitor the system. In the “Loggers” menu of the Admin Server, you can see all the log information about the application, as shown in the following figure:

By filtering these logs with the keyword “SpringCSS”, we can get the details of the logs in SpringCSS, which also shows the log level for each logger.

Finally, take a look at the “JVM” menu in Admin Server, which has two submenus: “Thread Dump” and “Heap Dump.”

In the case of “Thread Dump”, although the Actuator provides /threaddump endpoints, developers can only obtain the Dump information when the endpoints are triggered, while the Admin Server provides a continuous visual monitoring interface, as shown below:

Click on the color bar in the image to get detailed information about each thread, where you can try to do some analysis.

Controlling access security

At this point, it turns out that Admin Server has a lot of power, and it’s clear that this power should not be exposed to all developers. Therefore, we need to control the access security of the Admin Server.

To do this, we simply need to integrate Spring Security. We add a Maven dependency on Spring-boot-starter-Security to our Spring Boot application:

We then add the following configuration items to the configuration file:

After restarting the Admin Server, we need to enter the user name and password when accessing the Web interface again, as shown in the following picture:

Today’s share has ended, please forgive and give advice!