Data monitoring method, device and computer device of JAVA virtual machine, and storage medium
By configuring monitoring module plugins and service discovery modules in microservice clusters, the complexity of configuration and deployment difficulties of existing JVM monitoring methods in cloud-native environments are solved, enabling dynamic and large-scale monitoring of JVM status and reducing maintenance costs.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- ZHAOTONG LIANGFENGTAI INFORMATION TECH CO LTD
- Filing Date
- 2023-03-27
- Publication Date
- 2026-06-23
AI Technical Summary
Existing JVM monitoring methods in the cloud-native domain suffer from problems such as complex configuration, cumbersome operation, difficult deployment, and inability to dynamically discover monitoring targets, making it difficult to monitor microservice clusters in Kubernetes environments.
By configuring monitoring module plugins in the target application of the microservice cluster, writing operation and maintenance feature description configuration files, integrating service discovery and registration modules, and configuring monitoring module address information in Prometheus and Grafana, dynamic discovery and monitoring of JVM status can be achieved.
It enables efficient, dynamic, and scalable monitoring of the JVM status of microservice clusters in a Kubernetes environment, reducing maintenance costs and simplifying the deployment process.
Smart Images
Figure CN116302833B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of computer technology, and in particular to a data monitoring method, device, computer device, and storage medium for a Java Virtual Machine. Background Technology
[0002] In a Kubernetes container orchestration engine environment, applications run across multiple nodes within a cluster, and services are distributed across multiple clusters or cloud vendors. This makes tracking and monitoring the health of these applications and the infrastructure they depend on extremely challenging. Prometheus was developed to address this challenge, supporting Kubernetes and becoming the best monitoring tool for container scenarios.
[0003] In a production environment, system stability is a crucial foundation for maintaining business stability, and the JVM's runtime status directly impacts system stability. Providing reliable, scientific clues for troubleshooting, combined with JVM monitoring data, can enable optimization of application functionality and performance to a certain extent.
[0004] There are many methods for monitoring the JVM in microservices, including jmxexporter, springbootadmin, jvisualvm, jstatd, and Kubernetesservice. However, these methods are not well-suited for monitoring Java Virtual Machines in the cloud-native domain, or they are cumbersome to use. The main reasons are:
[0005] (1) The number of objects being monitored is usually small, and when there is too much data, the configuration becomes complicated or the operation becomes troublesome;
[0006] (2) The monitored objects are usually static and can usually be accessed through a fixed address;
[0007] (3) JMX requires mounting a JAR file in a specific directory in a container environment and then setting the JAR path in the runtime parameters. Deploying in a container environment is difficult, and fault migration is also quite challenging.
[0008] (4) It is not possible to dynamically discover monitored targets in batches. Target addresses need to be statically added in Prometheus.
[0009] (5) Microservices in Kubernetes run in Pods. Pods are volatile, so it is impossible to fix the monitoring address exposed by the application.
[0010] Kubernetes services offer a relatively good approach, allowing for the fixed-method retrieval of JVM data. However, they lack dynamic discovery capabilities. Each time a service is added, the target address needs to be statically added to Prometheus. Once a service is added, it cannot be dynamically discovered by Prometheus, making it impossible to monitor the newly added application's target JVM. This presents significant difficulties and challenges for monitoring microservice clusters in a Kubernetes environment. Summary of the Invention
[0011] To overcome the aforementioned technical deficiencies, the present invention aims to provide a data monitoring method, device, computer device, and storage medium for Java Virtual Machines that enables simple and efficient monitoring of microservice clusters based on cloud-native characteristics, thereby reducing usage costs and improving operational efficiency.
[0012] This invention discloses a data monitoring method for Java Virtual Machines (JVMs) in a microservice cluster, comprising the following steps: configuring a plugin for connecting to a monitoring module in the target application of the microservice cluster, and configuring a monitoring function module for the application, so that the monitoring module can discover the various monitoring indicator interfaces configured by the monitoring function module for monitoring the target application; writing an operation and maintenance characteristic description configuration file for the target application, including writing application characteristic information in the service metadata, so that the monitoring module can automatically discover the target application, thereby discovering the various monitoring indicator interfaces configured by the monitoring function module of the target application; adding a real-time monitoring class library for the target project to the monitoring module configuration file; and configuring the application characteristic information to be dynamically discovered by the monitoring module; configuring the monitoring module address information for the monitoring display module, so that the monitoring module can connect with the monitoring display module; configuring a JVM template in the monitoring display module, thereby viewing the JVM status of the target application in the configured microservice cluster through the monitoring module, wherein the JVM status includes the various monitoring indicators provided by the various monitoring indicator interfaces.
[0013] Preferably, after adding the real-time monitoring library of the target project to the monitoring module configuration file and configuring the application feature information to be dynamically discovered by the monitoring module, the monitoring module reloads the configuration file.
[0014] Preferably, the monitoring function module includes a monitoring function unit.
[0015] Preferably, after configuring the plugin for connecting to the monitoring module in the target application of the microservice cluster and configuring the monitoring function module for the application, the method further includes: integrating a service discovery and registration module in the target application of the microservice cluster and building an image of the target application.
[0016] Preferably, the service discovery and registration module includes a first service registration center, a second service registration center, and a third service registration center.
[0017] Preferably, the application feature information includes one or more of the following from the service metadata: application type, port number, interface of the monitoring module it is connected to, service rules, service namespace, and application service name.
[0018] Preferably, it further includes: dynamically monitoring the data of the Java Virtual Machine of the microservice cluster by modifying the application feature information in the operation and maintenance feature description configuration file of the target application and modifying the application feature information of the monitoring module.
[0019] This invention also discloses a data monitoring system for a Java Virtual Machine in a microservice cluster, including a microservice cluster, a monitoring module, a service discovery and registration module, and a monitoring display module. A plugin for connecting to the monitoring module is configured in the target application of the microservice cluster, and a monitoring function module for the application is configured. This module is used by the monitoring module to discover the various monitoring indicator interfaces configured by the monitoring function module for monitoring the target application. An operational characteristic description configuration file for the target application is written, including writing application characteristic information into the service metadata, so that the monitoring module can automatically discover the target application, thereby discovering the various monitoring indicator interfaces configured by the monitoring function module of the target application. In the target application of the microservice cluster... The service discovery and registration module is integrated, and an image of the target application is constructed. The service discovery and registration module includes a first service registry, a second service registry, and a third service registry. A real-time monitoring library for the target project is added to the configuration file of the monitoring module. The application characteristic information to be dynamically discovered by the monitoring module is configured. The address information of the monitoring module is configured for the monitoring display module, enabling the monitoring module to connect with the monitoring display module. A Java Virtual Machine template is configured in the monitoring display module, thereby allowing the monitoring module to view the Java Virtual Machine status of the target application in the configured microservice cluster. The Java Virtual Machine status includes various monitoring metrics provided by the various monitoring metric interfaces.
[0020] The present invention also discloses a computer device, the device comprising: a memory and a processor; the memory being used to store computer instructions; the processor executing the computer instructions to implement the method described in any one of the above-mentioned embodiments.
[0021] The present invention also discloses a computer-readable storage medium storing computer instructions, which, when executed, perform the method described in any of the preceding embodiments.
[0022] Compared with existing technologies, the above technical solution has the following advantages:
[0023] 1. This invention enables more efficient monitoring of the runtime status of Java Virtual Machines (JVMs) in large-scale microservices under Kubernetes. By introducing a simple dynamic discovery mechanism, Prometheus can dynamically obtain the address changes of the monitored targets. It can perform batch discovery, dynamic discovery, and large-scale access. Furthermore, the more nodes deployed and the larger the service scale, the lower the corresponding maintenance cost, thereby achieving simpler and more efficient monitoring of the JVM status of microservices in cloud-native environments. Attached Figure Description
[0024] Figure 1 A flowchart of the data monitoring method for a Java Virtual Machine in a microservice cluster provided by the present invention;
[0025] Figure 2 The schematic diagram of the module principle of the data monitoring system for the Java Virtual Machine of the microservice cluster provided by the present invention. Detailed Implementation
[0026] The advantages of the present invention will be further illustrated below with reference to the accompanying drawings and specific embodiments.
[0027] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numerals in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this disclosure. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this disclosure as detailed in the appended claims.
[0028] The terminology used in this disclosure is for the purpose of describing particular embodiments only and is not intended to be limiting of the disclosure. The singular forms “a,” “the,” and “the” as used in this disclosure and the appended claims are also intended to include the plural forms unless the context clearly indicates otherwise. It should also be understood that the term “and / or” as used herein refers to and includes any and all possible combinations of one or more of the associated listed items.
[0029] It should be understood that although the terms first, second, third, etc., may be used in this disclosure to describe various information, such information should not be limited to these terms. These terms are used only to distinguish information of the same type from one another. For example, without departing from the scope of this disclosure, first information may also be referred to as second information, and similarly, second information may also be referred to as first information. Depending on the context, the word "if" as used herein may be interpreted as "when," "when," or "in response to determination."
[0030] In the description of this invention, it should be understood that the terms "longitudinal", "lateral", "up", "down", "front", "rear", "left", "right", "vertical", "horizontal", "top", "bottom", "inner", "outer", etc., indicate the orientation or positional relationship based on the orientation or positional relationship shown in the accompanying drawings. They are only for the convenience of describing this invention and simplifying the description, and do not indicate or imply that the device or element referred to must have a specific orientation, or be constructed and operated in a specific orientation. Therefore, they should not be construed as limitations on this invention.
[0031] In the description of this invention, unless otherwise specified and limited, it should be noted that the terms "installation", "connection" and "linking" should be interpreted broadly. For example, they can refer to mechanical or electrical connections, or internal connections between two components. They can be direct connections or indirect connections through an intermediate medium. Those skilled in the art can understand the specific meaning of the above terms according to the specific circumstances.
[0032] In the following description, suffixes such as "module," "part," or "unit" used to denote elements are used only for the convenience of the description of the invention and have no specific meaning in themselves. Therefore, "module" and "part" can be used interchangeably.
[0033] The representative cloud-native technologies described in this invention include containers, service mesh, microservices, immutable infrastructure, and declarative APIs. Cloud-native applications are applications adapted to the characteristics of cloud computing. Cloud-native applications are designed from the outset to run in the cloud, whether it is a private cloud or a public cloud. The three main characteristics of cloud-native applications are: containerization, dynamic management, and microservices. (1) Containerization: Based on containers, the overall development level is improved, code and component reuse is achieved, the maintenance of cloud-native applications is simplified, applications and processes run in containers, and they are used as independent units for application deployment to achieve a high level of resource isolation; (2) Dynamic management: Dynamic management and scheduling are achieved through a centralized orchestration and scheduling system; (3) Microservice-oriented: Defining the dependencies between services and decoupling them from each other.
[0034] Microservices are an architectural style in which a large, complex software application is composed of one or more microservices. Each microservice in the system can be deployed independently, and the microservices are loosely coupled. Each microservice focuses on completing only one task and performing that task well. In all cases, each task represents a small business capability.
[0035] A container is a standardized, standalone software package that contains all the necessary elements to run anywhere without customization, including application code and supporting libraries. Similar to a virtual machine, a process can be virtualized into a container, hosting application deployments, providing simple isolation mechanisms, efficient resource utilization, and rapid packaging and deployment.
[0036] As containerized applications become increasingly complex, developers need tools to coordinate the interactions between containers running on different virtual machines, and even different physical machines. Such tools are called container orchestration platforms, and Kubernetes is one such platform. Kubernetes can work with any container that conforms to the Open Container Initiative (OCI) image specification; Podman's containers conform to this specification. Kubernetes is an open-source platform for managing containerized applications across multiple hosts in a cloud platform. Kubernetes aims to make deploying containerized applications simple and efficient, providing a mechanism for application deployment, planning, updating, and maintenance. Figuratively, Kubernetes can be understood as a centralized, integrated transportation tool. Kubernetes is a cornerstone of cloud-native computing. With the rapid development of container orchestration engine modules for cloud-native architectures, more and more companies and teams are deploying services in containerized form on cloud-native Kubernetes clusters.
[0037] A Pod is the smallest unit that can be created and managed in a Kubernetes system. Multiple application services can be deployed within a single Pod. Typically, services running within a cluster can be abstracted as Pods. A Pod is the basic execution unit of an application in a cloud-native architecture container orchestration engine module, also known as a service work unit. It is the smallest and simplest unit to create or deploy in the object model of the cloud-native architecture container orchestration engine module. A Pod represents a process running on the cluster. Pods and other container orchestration engine module resources are typically created by providing JSON or YAML files to the container orchestration engine module's REST API. For example, a Pod can be created using an nginx image.
[0038] A Service defines a logical grouping of Pods, a strategy for accessing them, and is used for Pod discovery and load balancing.
[0039] The JVM is a specification for computing devices. It is a virtual computer implemented by simulating various computer functions on an actual computer. It is the virtual machine that runs the Java programming language. The Java Virtual Machine mentioned in this invention refers to (but is not limited to) the JVM.
[0040] Prometheus is an open-source service monitoring system and time-series database used for monitoring the operational status of their respective systems.
[0041] This invention introduces a simple dynamic discovery mechanism, allowing Prometheus to dynamically obtain the address changes of monitored targets. For details, please refer to the appendix. Figure 1 A method for monitoring JVM data in a microservice cluster includes the following steps:
[0042] S100. Configure a plugin for connecting to the monitoring module in the target application of the microservice cluster, and configure a monitoring function module for the application, so that the monitoring module can discover the various monitoring indicator interfaces configured by the monitoring function module for monitoring the target application.
[0043] S200. Write the operation and maintenance feature description configuration file for the target application, including writing application feature information in the service metadata, so that the monitoring module can automatically discover the target application and thus discover the various monitoring indicator interfaces configured by the monitoring function module of the target application.
[0044] S300. Add the real-time monitoring library for the target project to the monitoring module configuration file;
[0045] S400, and configure the application feature information that the monitoring module needs to dynamically discover;
[0046] S500: Configure the monitoring module address information for the monitoring and display module to enable the connection between the monitoring module and the monitoring and display module;
[0047] S600 Configure the JVM template in the monitoring and display module, so that you can view the JVM status of the target application of the configured microservice cluster through the monitoring module. The JVM status includes various monitoring metrics provided by the various monitoring metric interfaces.
[0048] It should be noted that the target application of this invention is part or all of a microservice cluster, the monitoring module mainly refers to Prometheus, the service mainly refers to service, and the monitoring display module mainly refers to Grafana monitoring dashboard, but the scope of protection of this invention is not limited thereto.
[0049] The solution of this invention can be understood as including three main stages: application adjustment stage, Prometheus configuration stage, and Grafana monitoring dashboard configuration stage. Steps S100-S200 belong to the application adjustment stage, S300-S400 to the Prometheus configuration stage, and S500-S600 to the Grafana monitoring dashboard configuration stage.
[0050] In some embodiments, the plugin used to interface with the monitoring module (such as Prometheus) is typically the Micrometer plugin, but this is not limited to this. In some embodiments, the monitoring function module is preferably an actuator, used to expose the monitoring metric interface of the target application, facilitating Prometheus discovery. By introducing a Prometheus-interfacing plugin (such as the Micrometer plugin) into the target application and by adding application monitoring dependencies (such as the actuator), Prometheus can accurately access the target application and obtain data from its monitoring metric interface, thereby enabling monitoring.
[0051] For step S100, the monitoring metrics interface is used to monitor the real-time status parameters of the running target application. The monitoring metrics interface can monitor one or more of the following metrics, including but not limited to CPU usage, number of open files, system load, heap memory pool, number of GCs, and number of connections. In some embodiments, the monitoring metrics interface may include a health check interface (such as for monitoring whether the current status of the target application is healthy), but this is not limited. When application monitoring dependencies (such as actuators) are added, endpoint exposure is further required. The monitoring metrics interface of the target application is exposed by configuring the exposure scope and exposed service name of the monitoring metrics interface. In some embodiments, endpoint exposure includes the following process: (1) Configure endpoints: In a Spring Boot application, the endpoints that need to be exposed can be defined using the management.endpoints.* configuration property. For example, all web endpoints can be exposed by setting management.endpoints.web.exposure.include=*. (2) Register endpoints: The Spring Boot application will automatically register all exposed endpoints in a manager. The manager is a collection that maintains all registered endpoints. (3) Endpoint Access: A Spring Boot application generates a URL for each registered endpoint. Accessing this URL allows you to access the endpoint's functionality. For example, you can access ` / actuator / health` to retrieve the application's health status information. (4) Security Configuration: By default, Spring Boot endpoints do not require authentication. However, you can control which endpoints should be open and which should be closed by configuring the `management.endpoints.web.exposure.include` and `management.endpoints.web.exposure.exclude` properties. Additionally, Spring Security can be used to configure authentication and authorization for endpoints.
[0052] After exposing the configured monitoring metrics interfaces (such as the health check interface mentioned above), integrate the service discovery and registration module into the target application in the microservice cluster, and build an image of the target application. This service discovery and registration module is preferably the ETCD registry center. The ETCD registry center is implemented in Go and is mainly used for sharing configuration and service discovery components. It provides strong consistency and high availability in a distributed system and is used to store a small amount of important data. Of course, the service discovery and registration module can also be other service discovery and registration modules such as Nacos or Eurka; this is not a limitation here.
[0053] For step S200, a configuration file describing the operation and maintenance characteristics of the target application is written, and application characteristic information is written to enable the monitoring module to automatically discover the target application, thereby discovering the various monitoring indicator interfaces configured by the monitoring function module of the target application. In some embodiments, writing the configuration file describing the operation and maintenance characteristics can be done by adding application characteristic information to the annotations in the service's metadata. This application characteristic information includes one or more of the following (but is not limited to): application type, port number, the Prometheus interface it interfaces with, service rules, service namespace, and application service name, preparing for automatic discovery. In some embodiments, the configuration file describing the operation and maintenance characteristics can be an app.yaml file, which is not limited here.
[0054] After completing steps S100 and S200, the target application can be deployed to the Kubernetes cluster, completing the application tuning phase. Next, Prometheus configuration will be performed.
[0055] For step S300, add the real-time monitoring library for the target project to the Prometheus configuration file. In some embodiments, the target project can be a Spring project, and the real-time monitoring library can be metrics; this is just an example and not a limitation. Optionally, you also need to configure the job_name and kubernetes_sd_configs information next.
[0056] For step S400, configure the application characteristic information that Prometheus will dynamically discover. This application characteristic information includes one or more of the following from the service's metadata: application type, port number, the Prometheus interface it connects to, service rules, service namespace, and application service name (but is not limited to these). This should be understood as follows: the application characteristic information in the operation and maintenance characteristic description configuration file of the target application carrying monitoring data, and the application characteristic information configured for Prometheus to dynamically discover, both contain one or more of the following: application type, port number, the monitoring module interface it connects to, service rules, service namespace, and application service name. When the application characteristic information in the target application's operation and maintenance characteristic description configuration file matches the application characteristic information configured for Prometheus to dynamically discover, Prometheus can discover the target application to be monitored.
[0057] After configuring the application feature information that Prometheus wants to discover dynamically in step S400, Prometheus reloads the configuration file, and the loaded target can be seen in the console.
[0058] With the application and Prometheus monitoring client now configured, proceed to the Grafana monitoring dashboard configuration to display the monitoring information. Specifically, connect to Prometheus, configure the Prometheus address information, and then configure the JVM monitoring template. Download the corresponding template from the Grafana official website, import it into Grafana, and view the JVM status of the relevant services. Grafana will then display the JVM status of the target application in the microservice cluster configured through Prometheus. The JVM status includes the aforementioned monitoring metrics (such as the health of the target application, JVM memory usage, number of open files, system load, heap memory pool, GC count, and connection count).
[0059] Furthermore, by modifying the application feature information in the target application's operation and maintenance feature description configuration file, and by modifying the application feature information in the Prometheus configuration file, another batch of different application feature information can be monitored, thereby achieving large-scale, dynamic monitoring of the JVM state.
[0060] Furthermore, by changing the exposed monitoring indicator interface, monitoring of different application characteristic information can also be achieved.
[0061] This invention mainly involves introducing plugin dependencies (such as actuators) and exposing endpoints in the target application, and modifying the annotation information in the service's metadata in the target application's operation and maintenance feature description configuration file. For the Prometheus configuration part, only the relevant configuration needs to be modified according to the application feature information. This enables efficient and convenient access to the Prometheus monitoring system for dynamic, batch, and large-scale microservice cluster JVM runtime data.
[0062] See appendix Figure 2 The present invention also discloses a JVM data monitoring system for a microservice cluster, including a microservice cluster (application A, application B), Prometheus, ETCD registry center and Grafana.
[0063] Configure a Micrometer plugin for Prometheus in the target application of the microservice cluster, and add an application monitoring dependency actuator. This allows Prometheus to discover the various monitoring metrics interfaces configured by the actuator for monitoring the target application. Write an operational feature description configuration file for the target application, including writing application feature information into the annotations in the service's metadata. This enables Prometheus to automatically discover the target application and thus discover the various monitoring metrics interfaces configured by the actuator in the target application. Integrate the ETCD registry center into the target application of the microservice cluster and build an image of the target application.
[0064] Add the real-time monitoring library (e.g., metrics) for the target project (e.g., a Spring project) to the Prometheus configuration file; and configure the application feature information that Prometheus wants to discover dynamically.
[0065] Configure the Prometheus address information for Grafana to enable Prometheus to connect with Grafana; configure the JVM template in Grafana so that you can view the JVM status of the target application in the configured microservice cluster through Prometheus. The JVM status includes various monitoring metrics provided by the monitoring metrics interface.
[0066] The present invention also discloses a computer device, the device comprising: a memory and a processor; the memory for storing computer instructions; and a method for the processor to execute the computer instructions to implement any of the above.
[0067] The present invention also discloses a computer-readable storage medium storing computer instructions, wherein the computer instructions are executed to perform any of the above methods.
[0068] It should be noted that the embodiments of the present invention have better implementability and are not intended to limit the present invention in any way. Any person skilled in the art may use the above-disclosed technical content to change or modify it into equivalent effective embodiments. However, any modifications or equivalent changes and modifications made to the above embodiments based on the technical essence of the present invention without departing from the content of the technical solution of the present invention shall still fall within the scope of the technical solution of the present invention.
Claims
1. A method for monitoring data of a Java Virtual Machine in a microservice cluster, characterized in that, Includes the following steps: Configure a plugin for connecting to the monitoring module in the target application of the microservice cluster, and configure a monitoring function module for the application, so that the monitoring module can discover the various monitoring indicator interfaces configured by the monitoring function module for monitoring the target application. Write an operation and maintenance feature description configuration file for the target application, including writing application feature information in the service metadata, so that the monitoring module can automatically discover the target application and thus discover the various monitoring indicator interfaces configured by the monitoring function module of the target application. Add the real-time monitoring library for the target project to the monitoring module configuration file; and configure the application feature information that the monitoring module wants to dynamically discover. Configure the monitoring module address information for the monitoring display module, so that the monitoring module is connected to the monitoring display module; Configure a Java Virtual Machine template in the monitoring and display module, so as to view the Java Virtual Machine status of the target application in the configured microservice cluster through the monitoring module. The Java Virtual Machine status includes various monitoring indicators provided by the various monitoring indicator interfaces. The application feature information includes one or more of the following from the service metadata: application type, port number, interface of the monitoring module it is connected to, service rules, service namespace, and application service name. Furthermore, data monitoring methods also include: By modifying the application feature information in the operation and maintenance feature description configuration file of the target application, and by modifying the application feature information of the monitoring module, dynamic monitoring of the Java Virtual Machine data of the microservice cluster can be achieved.
2. The data monitoring method for a Java Virtual Machine in a microservice cluster according to claim 1, characterized in that, The real-time monitoring library for the target project is added to the monitoring module configuration file. After configuring the application feature information that the monitoring module wants to dynamically discover, it includes: The monitoring module reloads the configuration file.
3. The data monitoring method for a Java Virtual Machine in a microservice cluster according to claim 1, characterized in that, The monitoring function module includes monitoring function units.
4. The data monitoring method for a Java Virtual Machine in a microservice cluster according to claim 1, characterized in that, After configuring the plugin for interfacing with the monitoring module in the target application of the microservice cluster, and configuring the monitoring function module for the application, the process further includes: Integrate the service discovery and registration module into the target application in the microservice cluster, and build an image of the target application.
5. The data monitoring method for a Java Virtual Machine in a microservice cluster according to claim 4, characterized in that, The service discovery and registration module includes a first service registration center, a second service registration center, and a third service registration center.
6. A data monitoring system for a Java Virtual Machine in a microservice cluster, characterized in that, This includes a microservice cluster, a monitoring module, a service discovery and registration module, and a monitoring display module; Configure a plugin for connecting to the monitoring module in the target application of the microservice cluster, and configure a monitoring function module for the application, so that the monitoring module can discover the various monitoring indicator interfaces configured by the monitoring function module for monitoring the target application; write the operation and maintenance feature description configuration file of the target application, including writing application feature information in the service metadata, so that the monitoring module can automatically discover the target application, thereby discovering the various monitoring indicator interfaces configured by the monitoring function module of the target application. Integrate the service discovery and registration module into the target application within the microservice cluster, and build an image of the target application; The service discovery and registration module includes a first service registration center, a second service registration center, and a third service registration center; Add the real-time monitoring library for the target project to the configuration file of the monitoring module; and configure the application feature information that the monitoring module wants to dynamically discover. Configure the monitoring module address information for the monitoring display module so that the monitoring module is connected to the monitoring display module; configure a JAVA virtual machine template in the monitoring display module so that the JAVA virtual machine status of the target application in the configured microservice cluster can be viewed through the monitoring module. The JAVA virtual machine status includes various monitoring indicators provided by the various monitoring indicator interfaces. The application feature information includes one or more of the following from the service metadata: application type, port number, interface of the monitoring module it is connected to, service rules, service namespace, and application service name. The data monitoring system also achieves dynamic data monitoring of the Java Virtual Machines of the microservice cluster by modifying the application feature information in the operation and maintenance feature description configuration file of the target application and modifying the application feature information of the monitoring module.
7. A computer device, characterized in that, The device includes: a memory and a processor; the memory is used to store computer instructions; the processor executes the computer instructions to implement the method as described in any one of claims 1-5.
8. A computer-readable storage medium, characterized in that, The device stores computer instructions that, when executed, perform the method as described in any one of claims 1-5.