In the project, I saw the buried point monitoring, report and log analysis. I'm a little interested and want to make some trouble slowly
1. Data embedding point
Monitor the performance of the machine environment and various data such as business processes or logic, and generate corresponding indicators according to these data, then we call it data embedding point. For example, we want to know the TPS invoked by an interface and the utilization rate of the machine CPU, which can use the data embedding point
2. Micrometer
Micrometer provides a simple facade (similar to log facade) for various popular monitoring systems - provides supplier independent interfaces (counters, timers, gauges, etc.). These interfaces are called meter interfaces, which are created and saved by MeterRegistry. It can be understood that MeterRegistry stores the measurement data of various meters, The following shows the use of the simplest counter interface
2.1 simple use
It also has timers, gauges and other interfaces, which can be consulted by yourself
// Create a meter registry
MeterRegistry registry = new SimpleMeterRegistry();
// Create a measure called test
Counter counter = meterRegistry.counter("test");
// Add 1 to the count of this metric
counter.increment();
It is so simple. For example, when calling the specified interface, you can use the counter interface to measure the number and frequency of calls
2.2 naming conventions
Micrometer naming . Separate lowercase words and characters. When connected to other monitoring systems, the naming will be automatically converted to its appropriate format (or a NamingConvention converter can be rewritten to override the default naming conversion). It also supports multi label quantification, that is, with multi-dimensional measurement, the statistics are richer. The following is a simple example of naming conventions:
# Represents an http request
Counter counter = meterRegistry.counter("http.server.requests");
# Indicates that the user module is requested in the http request
Counter counter = meterRegistry.counter("http.server.requests", "user");
# Indicates the login login method in the http request and the user module
Counter counter = meterRegistry.counter("http.server.requests", "user", "login");
3. SpringBoot Actuator
The underlying layer of SpringBoot Actuator uses Mircometer, which can measure SpringBoot applications and obtain its indicators. Various endpoints exposed by the Actuator can be called through HTTP or JMX, and then the internal state of a running application can be obtained
Of course, not all internal indicators can be exposed, so we have to open them selectively or add permission verification to obtain the following contents:
- What are the configurable properties
- Log level of each dependent package
- How much memory is used
- How many times has the HTTP buried point been requested
- The health status of the application itself and the external services of the collaboration
- ......
3.1 adding dependencies
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
<version>2.4.3</version>
</dependency>
3.2 basic configuration
management:
server:
port: 9090 # Generally, the independent port is started (the default is the same as the application port). After enabling, the source port cannot be checked
endpoints:
web:
base-path: /actuator # Default prefix path, modifiable
exposure:
include: health,info,metrics # For exposed endpoints, wildcards ('*', single quotation marks are required)
exclude: env,heapdump # Exclude exposed endpoints
3.3 viewing consumable endpoints
HTTP can be used to access localhost: 9090 / actor to obtain HATEOAS (which can be simply understood as exposed endpoint document). It is the map of all exposed endpoints, and the indicator can be obtained through the address corresponding to the attribute. The content is as follows:
{
"_links": {
"self": {
"href": "http://localhost:9090/actuator",
"templated": false
},
"health-path": {
"href": "http://localhost:9090/actuator/health/{*path}",
"templated": true
},
"health": {
"href": "http://localhost:9090/actuator/health",
"templated": false
},
"info": {
"href": "http://localhost:9090/actuator/info",
"templated": false
}
}
}
3.4 obtaining basic information of application
For the corresponding indicators of consumption, just add the name after the address. The basic information of the application needs to be configured by itself. There is no default value, so you can access localhost: 9090 / Actor / info for the first time. It is an empty json.
The properties starting with info can be configured, such as contact information, application function, etc. the configuration and consumption results are as follows:
info:
contact:
email: support@howl.com
phone: 123456789
description: actuator test application
# Consumption results
{
"contact": {
"email": "support@howl.com",
"phone": 123456789
},
"description": "actuator test application"
}
3.5 health indicators
First, try to access localhost: 9090 / Actor / health to get the index content
{
"status": "UP"
}
Here, the aggregation status of one or more health indicators is displayed, that is, the aggregation status of the health status of the current application and the external systems interacting with it (database, message queue, Eureka, etc.). We can add the following configuration to get the cohesion status of the health indicator
management:
endpoint:
health:
show-details: always
# Consumption results
{
"status": "UP",
"components": {
"diskSpace": {
"status": "UP",
"details": {
"total": 493516484608,
"free": 436332154880,
"threshold": 10485760,
"exists": true
}
},
"ping": {
"status": "UP"
}
}
}
The automatic configuration function of SpringBoot can ensure that only the components interacting with the application will be displayed in health
3.6 endpoint metrics
You can access the following address to get the out of the box indicator classification provided by Actuator, including indicators such as memory, processor, garbage collection, HTTP request, etc
http://localhost:9090/actuator/metrics
# Consumption results
{
"names": [
"http.server.requests",
"jvm.buffer.count",
"jvm.buffer.memory.used",
"jvm.buffer.total.capacity",
"jvm.classes.loaded",
"jvm.classes.unloaded",
"jvm.gc.live.data.size",
"jvm.gc.max.data.size",
"jvm.gc.memory.allocated",
"jvm.gc.memory.promoted",
"jvm.gc.pause",
"jvm.memory.committed",
"jvm.memory.max",
"jvm.memory.used",
"jvm.threads.daemon",
"jvm.threads.live",
"jvm.threads.peak",
"jvm.threads.states",
"logback.events",
"process.cpu.usage",
"process.start.time",
"process.uptime",
"system.cpu.count",
"system.cpu.usage",
"tomcat.sessions.active.current",
"tomcat.sessions.active.max",
"tomcat.sessions.alive.max",
"tomcat.sessions.created",
"tomcat.sessions.expired",
"tomcat.sessions.rejected"
]
}
# You can use standard address + indicator endpoint name to consume an indicator endpoint
http://localhost:9090/actuator/metrics/http.server.requests
4. Examples
Count the number of times the / user/login interface is called. The meterRegistry registry adds a container to the automatic configuration and can be used directly
4.1 test interface
Start the application and access the interface multiple times
@RestController
@RequestMapping("/user")
public class UserController {
@Autowired
SimpleMeterRegistry meterRegistry;
@GetMapping("/login")
public String userLogin() {
Counter counter = meterRegistry.counter("http.server.requests", "uri", "/user/login");
counter.increment();
return "Login succeeded";
}
}
4.2 consumption index endpoint
Access the following address to consume the endpoint
http://localhost:9090/actuator/metrics/http.server.requests?tag=uri:/user/login
# Consumption results
# You can see that the interface counts 18 accesses (the data is partially cleared)
{
"name": "http.server.requests",
"baseUnit": "seconds",
"measurements": [
{
"statistic": "COUNT",
"value": 18.0
}
],
"availableTags": [
{
"tag": "method",
"values": [
"GET"
]
}
]
}
5. SpringBoot Admin
Using the above address access indicators is very unfriendly. It is impossible to see a pile of such data. You have to use some beautified UI interfaces. SpringBoot Admin provides such a framework
As a simple monitor, SpringBoot Admin is divided into server-side and client-side
5.1 Admin server
The monitoring server is usually deployed on another server, and then the server will regularly pull the monitoring index data from the configured address
5.1.1 enable functions and add dependencies
You can also choose Spring Initializr when initializing applications
@EnableAdminServer
@SpringBootApplication
public class AdminApplication {
public static void main(String[] args) {
SpringApplication.run(AdminApplication.class, args);
}
}
<dependency>
<groupId>de.codecentric</groupId>
<artifactId>spring-boot-admin-starter-server</artifactId>
<version>2.4.3</version>
</dependency>
5.1.2 select a port
server: port: 10000
5.1.3 access
You can directly access 10000 ports. Of course, there is nothing to monitor now. The main page is blank and has no application
5.2 Client
5.2.1 add dependency
<!-- actuator -->
<dependency>
<groupId>org.springframework.boot</groupId>
<artifactId>spring-boot-starter-actuator</artifactId>
<version>2.4.3</version>
</dependency>
<!-- admin-client -->
<dependency>
<groupId>de.codecentric</groupId>
<artifactId>spring-boot-admin-starter-client</artifactId>
<version>2.4.3</version>
</dependency>
5.2.2 add configuration
# The server communicates with the host name of the client, but the host name of the client on the virtual machine will not be resolved correctly, resulting in the instance being offline all the time
# The following configuration is required
spring:
application:
name: actuatorApplicaton
boot:
admin:
client:
url: http://admin-serve-ip:10000 # Send requests to the server regularly
instance:
service-url: http://admin-client-ip:8080 # homepage
management-base-url: http://admin-client-ip:9090 # Basic address of various indicators
5.2.3 accessing admin serve
After visiting, you can find that the indicators of an application have been obtained, and then you can see various exposed endpoint indicators
5.3 Eureka server discovery
It is troublesome to manually configure the monitored IP address every time a client is started. Since the micro service architecture has a service discovery mechanism, we can configure Eureka's address on the monitored server, and the admin server will go to the registry to obtain the address and then pull the index
5.3.1 add dependency
<dependency>
<groupId>org.springframework.cloud</groupId>
<artifactId>spring-cloud-starter-netflix-eureka-client</artifactId>
<version>2.4.3</version>
</dependency>5.3.2 add configuration
eureka:
client:
service-url:
defaultZone: http://xxx.xxx.xxx.xxx:xxx/eureka/
6 disadvantages
I personally think that this combination is enough for personal small projects to monitor buried points. In addition, warning processing is a good choice. However, SpringBoot Admin can only monitor application information in a short time. If monitoring in each time period is required, it needs the support of sometimes ordinal database (such as viewing statistics in this month), These seem powerless.
Of course, there are alternatives:
- Actuator: embedded point operation
- Promethus: regularly pull data from the actor and store it in the form of time sequence (internal time sequence database)
- Granfan: user friendly UI data display, displaying Promethus data
Later, the author will write a note on Promethus monitoring
Original link:
https://www.cnblogs.com/Howlet/p/15552709.html
Author: Howl
For more information, you can pay attention to the official account "w's programming diary" and reply to Java for more information.