A method and apparatus for performance analysis of cloud-native middleware based on large models

Abstract

This invention discloses a cloud-native middleware performance analysis method and apparatus based on a large model, applicable to the field of artificial intelligence. The method includes: creating task information based on a performance analysis task; configuring task resources through a container orchestration platform when the task status is empty; determining the configuration information of the middleware to be analyzed based on its topology; generating large model prompts based on the task information and the middleware's topology; inputting the large model prompts into a preset large model; and using monitoring metrics and runtime logs to preliminarily infer the causes affecting the middleware's performance; if the preliminary inference by the large model fails to identify the causes affecting the middleware's performance, obtaining internal runtime data of the middleware based on the configuration information, and then re-inferring the causes affecting the middleware's performance using the large model. This invention can improve the efficiency and accuracy of middleware performance analysis.

Description

Technical Field

[0001] This invention relates to the field of artificial intelligence, and in particular to a method and apparatus for performance analysis of cloud-native middleware based on large models. Background Technology

[0002] This section is intended to provide background or context for embodiments of the present invention. The description herein is not intended to imply that it is prior art simply because it is included in this section.

[0003] In cloud-native architectures, container orchestration platforms allow users to easily manage and scale various middleware services. However, despite the powerful container orchestration capabilities offered by these platforms, existing middleware performance analysis methods still have many shortcomings.

[0004] First, existing technologies perform poorly in data fusion, lacking cross-layer analytical capabilities. Performance analysis typically relies on monitoring metrics and log data, but these data sources are diverse and scattered, requiring reliance on monitoring data, log data, and management interfaces (commands) simultaneously, leading to high complexity in data integration and analysis. Second, these analytical methods are highly dependent on manual operation, usually requiring experienced operations and maintenance personnel to analyze logs and monitoring data, and sometimes even manually executing environment commands for troubleshooting. This not only increases the difficulty of operation but also reduces the efficiency and accuracy of the analysis.

[0005] Therefore, how to implement efficient, automated, and data-integration-capable middleware performance analysis methods in cloud-native environments is an important problem that urgently needs to be solved in the current technology field. Summary of the Invention

[0006] This invention provides a cloud-native middleware performance analysis method based on a large model to improve the efficiency and accuracy of middleware performance analysis. The method includes:

[0007] After receiving a performance analysis task for cloud-native middleware created by a user, task information is created based on the performance analysis task, including the task status.

[0008] Monitor the task status of performance analysis tasks, and configure task resources through the container orchestration platform when the task status is empty;

[0009] Obtain the topology of the middleware to be analyzed, and determine the configuration information of the middleware to be analyzed based on the topology.

[0010] Based on the task information and the topology of the middleware to be analyzed, a large model prompt is generated. After the large model prompt is input into the preset large model, the monitoring indicators and operation logs of the middleware to be analyzed within a preset time period are obtained according to the configured task resources. Based on the monitoring indicators and operation logs, the large model is used to preliminarily infer the reasons affecting the performance of the middleware to be analyzed. The large model prompt is used to guide the large model to analyze the problem. The large model is used to infer the reasons affecting the performance of the middleware to be analyzed by calculating the health score of the middleware according to the prompt, based on the monitoring indicators and operation logs. The health score is used to quantify the performance of the middleware.

[0011] When the initial reasoning of the large model fails to identify the cause affecting the performance of the middleware to be analyzed, the internal operating data of the middleware is obtained based on the configuration information. Based on the internal operating data, monitoring indicators, and operating logs of the middleware, the cause affecting the performance of the middleware to be analyzed is re-inferred through the large model.

[0012] This invention also provides a cloud-native middleware performance analysis device based on a large model to improve the efficiency and accuracy of middleware performance analysis. The device includes:

[0013] The task acquisition module is used to receive a performance analysis task created by the user for cloud-native middleware, and then create task information based on the performance analysis task, including the task status.

[0014] The task monitoring module is used to monitor the task status of performance analysis tasks. When the task status is empty, task resources are configured through the container orchestration platform.

[0015] The topology analysis module is used to obtain the topology of the middleware to be analyzed and determine the configuration information of the middleware to be analyzed based on the topology.

[0016] The initial reasoning module is used to generate large model prompts based on task information and the topology of the middleware to be analyzed. After inputting the large model prompts into a preset large model, the module obtains the monitoring indicators and operation logs of the middleware to be analyzed within a preset time period according to the configured task resources. Based on the monitoring indicators and operation logs, the module uses the large model to initially infer the reasons affecting the performance of the middleware to be analyzed. The large model prompts are used to guide the large model in analyzing problems. The large model is used to infer the reasons affecting the performance of the middleware to be analyzed by calculating the health score of the middleware according to the prompts, monitoring indicators, and operation logs. The health score is used to quantify the performance of the middleware.

[0017] The re-inference module is used when the initial inference of the large model fails to find the cause affecting the performance of the middleware to be analyzed. Based on the configuration information, it obtains the internal operating data of the middleware, and re-infers the cause affecting the performance of the middleware to be analyzed through the large model based on the internal operating data, monitoring indicators and operation logs.

[0018] This invention also provides a computer device, including a memory, a processor, and a computer program stored in the memory and executable on the processor. When the processor executes the computer program, it implements the above-described cloud-native middleware performance analysis method based on a large model.

[0019] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described cloud-native middleware performance analysis method based on a large model.

[0020] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described cloud-native middleware performance analysis method based on a large model.

[0021] In this embodiment of the invention, after receiving a performance analysis task created by a user for cloud-native middleware, task information is created based on the performance analysis task, including the task status; the task status of the performance analysis task is monitored, and when the task status is empty, task resources are configured through a container orchestration platform; the topology of the middleware to be analyzed is obtained, and the configuration information of the middleware to be analyzed is determined based on the topology; large model prompts are generated based on the task information and the topology of the middleware to be analyzed, and after inputting the large model prompts into a preset large model, monitoring indicators and operation logs of the middleware to be analyzed within a preset time period are obtained based on the configured task resources. Based on monitoring metrics and operational logs, a large-scale model is used to initially infer the reasons affecting the performance of the middleware under analysis. The large-scale model uses prompts to guide its analysis, and, following these prompts, calculates a health score to quantify the middleware's performance. If the initial inference using the large-scale model fails to identify the cause of the performance issue, internal middleware operational data is retrieved based on configuration information. This data, along with monitoring metrics and operational logs, is used to re-infer the reasons for the performance impact using the large-scale model. This approach improves the efficiency and accuracy of middleware performance analysis by receiving performance analysis tasks, creating task information based on task status, determining configuration information based on the middleware topology, generating prompts, retrieving monitoring metrics and operational logs of the middleware under analysis, using a large-scale model to infer the reasons for performance impact, and re-inferring internal middleware information when inference fails. Attached Figure Description

[0022] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort. In the drawings:

[0023] Figure 1 This is a flowchart of a cloud-native middleware performance analysis method based on a large model provided in an embodiment of the present invention;

[0024] Figure 2 This is a flowchart illustrating the knowledge feedback process provided in this embodiment of the invention.

[0025] Figure 3 This is a diagram illustrating the operational architecture of the cloud-native middleware performance analysis method based on a large model provided in this embodiment of the invention.

[0026] Figure 4This is a schematic diagram of a cloud-native middleware performance analysis device based on a large model provided in an embodiment of the present invention;

[0027] Figure 5 This is a structural block diagram of a computer device provided in an embodiment of the present invention. Detailed Implementation

[0028] To make the objectives, technical solutions, and advantages of the embodiments of the present invention clearer, the embodiments of the present invention will be further described in detail below with reference to the accompanying drawings. Here, the illustrative embodiments of the present invention and their descriptions are used to explain the present invention, but are not intended to limit the present invention.

[0029] In this document, the term "and / or" merely describes a relationship, indicating that three relationships can exist. For example, A and / or B can represent three cases: A alone, A and B simultaneously, and B alone. Furthermore, the term "at least one" in this document means any combination of at least two of any one or more elements. For example, including at least one of A, B, and C can mean including any one or more elements selected from the set consisting of A, B, and C.

[0030] In the description of this specification, the terms "comprising," "including," "having," and "containing" are open-ended terms, meaning that they include but are not limited to. The terms "an embodiment," "a specific embodiment," "some embodiments," and "for example," etc., refer to specific features, structures, or characteristics described in connection with that embodiment or example that are included in at least one embodiment or example of this application. In this specification, the illustrative expressions of the above terms do not necessarily refer to the same embodiment or example. Furthermore, the specific features, structures, or characteristics described can be combined in any suitable manner in one or more embodiments or examples. The order of steps involved in the various embodiments is used to illustrate the implementation of this application, and the order of steps is not limited and can be adjusted appropriately as needed.

[0031] This invention provides a method for performance analysis of cloud-native middleware based on a large model. Figure 1 The flowchart shows a cloud-native middleware performance analysis method based on a large model, such as... Figure 1 As shown, it includes:

[0032] Step 101: After receiving the performance analysis task created by the user for the cloud-native middleware, create task information based on the performance analysis task, the task information including the task status.

[0033] Step 102: Monitor the task status of the performance analysis task. When the task status is empty, configure task resources through the container orchestration platform.

[0034] Step 103: Obtain the topology of the middleware to be analyzed, and determine the configuration information of the middleware to be analyzed based on the topology of the middleware to be analyzed;

[0035] Step 104: Generate large model prompts based on task information and the topology of the middleware to be analyzed. After inputting the large model prompts into the preset large model, obtain the monitoring indicators and operation logs of the middleware to be analyzed within a preset time period according to the configured task resources. Based on the monitoring indicators and operation logs, use the large model to preliminarily infer the reasons affecting the performance of the middleware to be analyzed. The large model prompts are used to guide the large model to analyze the problem. The large model is used to infer the reasons affecting the performance of the middleware to be analyzed by calculating the health score of the middleware according to the prompts, monitoring indicators and operation logs. The health score is used to quantify the performance of the middleware.

[0036] Step 105: If the initial reasoning of the large model fails to identify the cause affecting the performance of the middleware to be analyzed, obtain the internal operating data of the middleware based on the configuration information. Based on the internal operating data, monitoring indicators, and operating logs of the middleware, re-infer the cause affecting the performance of the middleware to be analyzed through the large model.

[0037] In a specific embodiment, for step 101, after receiving the performance analysis task for cloud-native middleware created by the user, task information is created based on the performance analysis task, and the task information includes the task status.

[0038] In practice, users can submit performance analysis tasks through a custom resource object (TaskResource). This object describes the middleware type, namespace, connection information, task parameters, and result return method. The Operator component in the system continuously monitors the lifecycle changes of this resource and automatically creates and schedules the corresponding analysis job (i.e., a Job object in Kubernetes) upon detecting a new analysis task, thus automating task execution. This step simplifies the user's workflow, reduces manual intervention, and improves the efficiency and reliability of task scheduling.

[0039] In another embodiment, the task information includes task type, middleware type to be analyzed, task name, user question, and task status.

[0040] In practice, users can submit task information via the API interface, including the task type (such as performance analysis, health check, etc.), the type of middleware to be analyzed (such as Redis, MySQL, etc.), the task name (such as "redis-performance-analysis"), the user's question (such as "Around noon today, Redis queries were slow; please help me analyze the cause"), and the task status (such as Pending, Running, Success, Failed). This step ensures the completeness and accuracy of the task information, providing a reliable foundation for subsequent analysis.

[0041] For step 102, monitor the task status of the performance analysis task. When the task status is empty, configure task resources through the container orchestration platform.

[0042] In practice, the Operator component continuously monitors the task status in the task information through the controller; when the task status is empty, a computing task resource is created through the controller. Through this step, real-time monitoring and automated scheduling of task status can be achieved, ensuring that tasks can start and execute in a timely manner, thereby improving the system's response speed and processing capacity.

[0043] In another embodiment, the topology of the middleware to be analyzed is obtained, and the configuration information of the middleware to be analyzed is determined based on the topology of the middleware to be analyzed.

[0044] In a specific embodiment, the topology of the middleware to be analyzed running in the container orchestration platform is obtained; based on the topology of the middleware to be analyzed, the IP address, port, and authentication account password of the middleware to be analyzed are extracted.

[0045] In practice, the system can obtain the topology of the target Redis StatefulSet, including Pods, PVCs, and Services, through k8s-mcp-server, and automatically extract the Redis instance's IP address, port, and authentication information (e.g., decrypted from the Secret). This step ensures accurate middleware configuration information is obtained, providing necessary data support for subsequent analysis.

[0046] In another embodiment, when the initial inference of the large model fails to identify the cause affecting the performance of the middleware to be analyzed, the internal operating data of the middleware is obtained based on the configuration information, including:

[0047] When the initial reasoning of the large model fails to identify the cause affecting the performance of the middleware to be analyzed, an executable read command is created within the middleware based on the IP address, port, and authentication account password in the middleware to be analyzed.

[0048] Based on the executable read commands within the created middleware, return the internal running data of the middleware with read-only permissions.

[0049] For step 104, generate large model prompt words based on task information and the topology of the middleware to be analyzed. After inputting the large model prompt words into the preset large model, obtain the monitoring indicators and operation logs of the middleware to be analyzed within a preset time period according to the configured task resources. Based on the monitoring indicators and operation logs, preliminarily infer the reasons affecting the performance of the middleware to be analyzed through the large model.

[0050] In practice, the system constructs a Prompt based on the user-input `spec.content` field, combines it with the Redis cluster context (such as master-slave structure, number of running nodes, etc.), and sends the Prompt to the locally or remotely deployed large language model. The model returns a Tool Call type operation command. The `mcp-client` recognizes the Tool Call, connects to the `prometheus-mcp-server` and `es-mcp-server`, and pulls monitoring metrics and logs. The large model performs preliminary inference based on the returned data. If the root cause of the problem can be directly determined, the analysis ends early. Through this step, the powerful analytical capabilities of the large model can be utilized to quickly locate the root cause of the problem, improving the accuracy and efficiency of the analysis.

[0051] In one embodiment, the middleware includes a CPU and memory;

[0052] Based on monitoring metrics and runtime logs, a preliminary inference is made using a large model to determine the factors affecting the performance of the middleware under analysis, including:

[0053] Based on monitoring metrics and operation logs, assess CPU utilization health, throttling health, and trend health.

[0054] Calculate the CPU health score based on CPU utilization health, throttling health, and trend health.

[0055] Based on monitoring metrics and operational logs, preliminary reasoning using a large model examines the factors affecting the performance of the middleware under analysis, including:

[0056] Based on monitoring metrics and runtime logs, assess the health of memory usage, upper limit, and trend.

[0057] Calculate the memory health score based on memory usage health, upper limit health, and trend health.

[0058] In one specific embodiment, a multi-dimensional Kubernetes workload performance evaluation system is defined, aiming to analyze the performance of middleware containers in Kubernetes based on resource health calculations. CPU and memory are used as the following dimensions, as shown in Table 1:

[0059] Table 1

[0060]

[0061] 1. CPU health score algorithm:

[0062] The CPU Health Score (HCPU) is a metric used to comprehensively evaluate the current operating status and stability of a system's CPU. It reflects the CPU's "health level" and potential risks under the current workload from multiple perspectives, including performance utilization, resource scheduling constraints, and trend changes. This score is calculated by weighting three core dimensions: CPU utilization health, CPU throttling health, and CPU trend health.

[0063] 1) CPU utilization health:

[0064] It measures the degree of matching between actual CPU utilization and configured resources (Requests), identifying insufficient or excessive resource allocation.

[0065] formula:

[0066]

[0067] in:

[0068] U short Short-term average CPU utilization (e.g., average within a sliding window);

[0069] R cpu CPU request value;

[0070] clamp(x, 0, 1): Limits the result to the interval [0, 1].

[0071] If the usage rate is lower than that of Request, it indicates that the configuration is reasonable, and H_use will approach 1.

[0072] If the usage rate is close to or exceeds the Request rate, H_use will decrease, indicating increased resource pressure.

[0073] 2) CPU throttling health:

[0074] Measuring the proportion of CPUs that are restricted during scheduling reflects scheduling fairness and availability.

[0075] formula:

[0076]

[0077] in:

[0078] T avg Average number of throttling cycles;

[0079] P avg Average total number of cycles;

[0080] clamp(x, 0, 1): Computes the result within the interval [0, 1].

[0081] High throttling ratio (CPU is frequently limited) ⇒ H_throttle decreases.

[0082] A low throttling ratio leads to H_throttle being close to 1, resulting in stable system operation.

[0083] 3) CPU trend health:

[0084] By comparing the differences in short-term and long-term CPU utilization, we can detect load change trends and identify risks of continuous increases or decreases.

[0085] formula:

[0086]

[0087] in:

[0088] U short Short-term average CPU utilization;

[0089] U long Long-term average CPU utilization (can represent historical benchmarks);

[0090] clamp(x, 0, 1): Limits the result to the interval [0, 1].

[0091] When short-term and long-term trends are close (system is stable) ⇒ H_trend approaches 1.

[0092] If short-term usage continues to rise or fall (H_trend decreases), it indicates an abnormal trend.

[0093] 4) Comprehensive Health Score Formula (HCPU):

[0094] A score is calculated to evaluate the overall performance of the CPU based on the above three dimensions.

[0095] formula:

[0096]

[0097] Weights: w1=0.4, w2=0.3, w3=0.3, ∑w i =1, but can be adjusted according to the actual situation.

[0098] All scores were normalized using clamp(x, 0, 1);

[0099] The CPU health status reference range is shown in Table 2:

[0100] Table 2

[0101]

[0102] Table 3 shows the corresponding results for each dimension of CPU:

[0103] Table 3

[0104]

[0105] 2. Memory health score algorithm:

[0106] HMemory is used to comprehensively evaluate system memory usage efficiency, cache contribution, and trend stability, reflecting the system's memory health and potential risks under current load. The score is calculated by weighting the following three core dimensions: usage health, memory limit health, and trend health.

[0107] 1) Memory usage health:

[0108] It measures how well the actual memory usage matches the configured capacity, identifying insufficient or excessive resource allocation.

[0109] formula:

[0110]

[0111] in:

[0112] M used Short-term average memory usage (can be averaged using a sliding window);

[0113] M total : The system's available memory or the requested configuration value;

[0114] clamp(x, 0, 1): Normalizes the result by limiting it to the interval [0, 1].

[0115] When memory usage is lower than the total capacity, H_use is close to 1, indicating that the configuration is reasonable.

[0116] When memory usage approaches or exceeds capacity, H_use decreases, indicating that the system may be facing memory pressure.

[0117] 2) Memory limit health status:

[0118] Measure whether the actual memory usage of the container is close to or reaches the K8s memory limit to avoid being out of memory (OOMill) due to exceeding the limit.

[0119] formula:

[0120]

[0121] in:

[0122] M peak : Maximum memory usage within the monitoring time window;

[0123] M limit K8s Memory Limit;

[0124] clamp(x, 0, 1): Restricts the result to [0, 1].

[0125] p: The larger the descent slope p, the faster the score drops (the higher the sensitivity to memory overuse); the smaller p, the greater the overuse ratio is required to trigger a low score.

[0126] p = 1: Used for high-reliability scenarios in production environments to avoid any risk of approaching OOM (conservative strategy).

[0127] p = 0.7 ~ 0.9: Balances performance and security, commonly used for dynamic loads (such as web services), allowing for small peak fluctuations.

[0128] p < 0.5: Provides greater resilience in testing or low-risk environments, but may overlook potential OOM (Out of Memory) vulnerabilities.

[0129] H limit →1 → Memory usage is far below the limit, ensuring safety and health;

[0130] Hlimit → 0 indicates that memory usage is close to or has reached the limit, which poses a high risk.

[0131] 3) Memory Trend Health:

[0132] Analyze short-term and long-term memory usage trends to detect the risks associated with continued growth or decline.

[0133] formula:

[0134]

[0135] in:

[0136] Mshort Short-term average memory usage;

[0137] M long Long-term average memory usage (historical baseline).

[0138] Small value protection to avoid division by zero errors (e.g., 0.01);

[0139] clamp(x, 0, 1): Limits the result to the interval [0, 1].

[0140] When short-term and long-term usage are close, H_trend is close to 1, indicating that the system is stable.

[0141] If short-term memory usage continues to rise or fall → H_trend decreases, it indicates an abnormal trend.

[0142] 4) Memory Overall Health Score Formula (HMemory):

[0143] A score is calculated to evaluate the overall memory performance based on the above three dimensions.

[0144] formula:

[0145]

[0146] Weight example:

[0147] w1=0.4, w2=0.3, w3=0.3, which can be adjusted according to actual business needs;

[0148] All scores were normalized using clamp(x, 0, 1).

[0149] Table 4 shows the reference range for memory health status.

[0150] Table 4

[0151]

[0152] Table 5 shows the corresponding results for each dimension of memory usage.

[0153] Table 5

[0154]

[0155] Based on the CPU and memory health algorithms mentioned above, the large model is fine-tuned using data to construct a large model that includes analytical algorithms, capable of calculating the input data and returning scores for the corresponding dimensions.

[0156] In another embodiment, when the initial reasoning of the large model fails to determine the cause affecting the performance of the middleware to be analyzed, the internal operating data of the middleware is obtained based on the configuration information. Based on the internal operating data of the middleware, monitoring indicators, and operating logs, the cause affecting the performance of the middleware to be analyzed is re-reasoned through the large model.

[0157] In a specific embodiment, when the initial reasoning of the large model fails to determine the cause affecting the performance of the middleware to be analyzed, an executable read command is created within the middleware based on the IP address, port, and authentication account password in the middleware to be analyzed; based on the created executable read command within the middleware, the internal running data of the middleware is returned under read-only permissions.

[0158] In practice, the large model selects a specific Redis instance node for command-level in-depth analysis, generating commands (such as INFO, SLOWLOG GET, MONITOR, etc.), calling redis-mcp-server to execute them and obtaining the returned results; multiple rounds of interaction continue until a complete judgment is formed or the analysis limit is reached. Through this step, the analysis can be further refined to ensure the comprehensiveness and accuracy of the root cause of the problem.

[0159] For step 105, after determining the cause affecting the performance of the middleware to be analyzed, the task status of the performance analysis task is set to success; the cause affecting the performance of the middleware to be analyzed is rendered into a visual interface for users to view.

[0160] In practice, the system renders the JSON output from the model into an HTML report, uploads it to object storage, and generates an intranet or public network access link. The Operator writes the report link to the `status.doc` field, the model summary content to the `status.reason` field, and updates `status.phase` to `Success`. This step presents the analysis results in a user-friendly format, making it easy for users to view and understand.

[0161] Figure 2 This is a flowchart of knowledge feedback provided in the embodiments of the present invention, such as... Figure 2 As shown, in this embodiment of the invention, it further includes:

[0162] Step 201: After determining the causes affecting the performance of the middleware to be analyzed, obtain the intermediate data and the inference results corresponding to the intermediate data during the inference process;

[0163] Step 202: Update the knowledge base of the large model based on the intermediate data and the inference results corresponding to the intermediate data in the inference process. The knowledge base is constructed by text preprocessing and embedding model vectorization to build a retrieval foundation for enhancing the large model generation process.

[0164] In practice, the system periodically vectorizes knowledge documents (using vector models such as Qwen-Embedding / BGE) and stores them in a vector database. When a user submits a new TaskResource, its content field triggers a semantic vector retrieval process, extracting the most relevant knowledge fragments from the historical knowledge base and injecting them into the new task's prompt, thus implementing a Retrieval Enhancement (RAG) mechanism for analytical reasoning. Through this step, the knowledge base can be continuously accumulated and optimized, improving the analytical capabilities and response quality of large models.

[0165] Figure 3 This is a diagram illustrating the operational architecture of the cloud-native middleware performance analysis method based on a large model provided in this embodiment of the invention. Figure 3 As shown, in a specific embodiment, the execution of the cloud-native middleware performance analysis method based on a large model is divided into three processes: task scheduling, task execution, and knowledge feedback.

[0166] Here Figure 3 A brief explanation of each component:

[0167] TaskResource: Unlike the built-in resources in Kubernetes, TaskResource is a custom resource in Kubernetes that contains multiple custom fields, including information such as task type, task name, task status, middleware type, and user issue.

[0168] mcp-analyze-operator: A custom resource controller in Kubernetes used to create, update, and delete custom resources, and maintain the state of custom resources.

[0169] API: An interface for large models and various plugin clients to interact and obtain information.

[0170] mcp-server repository: A local repository for storing various plugins. When it is necessary to analyze the status of a certain middleware, Kubernetes will download the latest plugins from this repository.

[0171] mcp-client: Large models obtain middleware information from various plugins through this client.

[0172] Extended MCP Server: A general term for various plugins of middleware to be analyzed. Unlike the built-in MCP Server, the extended MCP Server can be continuously expanded according to the types of middleware to be analyzed.

[0173] redis-mcp-server: A plugin for analyzing Redis data, enabling it to interact with the Redis server and retrieve data.

[0174] mysql-mcp-server: A plugin for analyzing MySQL data, capable of interacting with the MySQL server to retrieve data.

[0175] other-mcp-server: This term refers to plugins used to analyze other types of middleware and obtain data from the corresponding middleware.

[0176] REDIS: A mature, open-source, non-relational database middleware.

[0177] MySQL: A mature open-source relational database middleware.

[0178] Built-in MCP Server: A general term for various plugins that include log analysis, monitoring metrics, and topology information.

[0179] elastic-mcp-server: A plugin used to obtain log information of middleware to be analyzed.

[0180] prometheus-mcp-server: A plugin used to obtain monitoring metrics for middleware to be analyzed.

[0181] kubernetes-mcp-server: A plugin used to obtain topology information of the middleware to be analyzed.

[0182] Kubernetes platform: A mature open-source process virtualization technology that serves as the foundational environment for running various middleware.

[0183] Task Scheduling: The system utilizes the Kubernetes platform within a cloud-native architecture. Users submit performance analysis tasks by defining custom resource objects called `TaskResource`. These objects describe the middleware type, namespace, connection information, task parameters, and result feedback method. The `Operator` component continuously monitors the lifecycle changes of this resource and automatically creates and schedules the corresponding analysis job (i.e., a `Job` object in Kubernetes) upon detecting a new analysis task. This automates task execution. The `Job` executes the specific analysis task, and upon completion, it is marked as successful and relevant metadata (such as analysis results and links to analysis reports) is written to it.

[0184] In one specific embodiment, based on dynamic resource allocation, automated matching of resources required by different middlewares is achieved. Resource quotas are mapped by predefining "middleware-task" templates in the operator. Examples of templates are shown in Table 6.

[0185] Table 6

[0186]

[0187] Based on resource mapping templates, the Operator dynamically matches templates. When a Job is created, the Operator automatically matches resource configurations from the template library based on the spec.middlewareType and spec.taskType of TaskResource and injects them into the spec.template.spec.containers.resources field of the Job, without requiring manual configuration by the user.

[0188] Task Execution: In specific analysis jobs, the core component is the mcp-client process. This process is responsible for initializing the analysis context, including obtaining topology information, downloading adaptation plugins, configuring analysis parameters, and driving the analysis process through Prompt interaction with a large language model deployed locally or privately. This Prompt template supports injecting middleware context information, including instance structure, performance monitoring, log characteristics, etc., and also supports user natural language queries, based on which the model selects analysis tools and instruction sets.

[0189] Specific middleware-type mcp-server plugins (such as redis-mcp-server, mysql-mcp-server, etc.) are used to execute diagnostic commands under read-only permissions and return the internal running status of the middleware. This invention supports dynamic expansion through an mcp-server plugin repository mechanism. The mcp-client dynamically downloads the required mcp-server plugins from this repository as needed based on the task type and middleware characteristics, and loads and uses them during task execution. This eliminates the need to pre-install all supporting components, greatly improving the system's adaptability and maintainability.

[0190] During the analysis, the mcp-client interacts with the large model using a multi-round session mechanism. The model automatically decides whether to request more data sources, issue more commands, or terminate the task based on the analysis objectives. The command results, model inference process, and conclusions in each round of interaction are recorded and written to TaskResource as structured fields for subsequent organization and traceability.

[0191] Knowledge Feedback: After the analysis task is completed, the system summarizes all intermediate data and final conclusions from the analysis process into an analysis report and automatically stores it in the knowledge base. This knowledge base, through text preprocessing (cleaning, denoising, and tagging) and embedding model vectorization, constructs the retrieval foundation for the Retrieval Augmented Generation (RAG) process. When users submit similar tasks subsequently, the system can quickly locate historical cases based on vector similarity, assisting the large model in building more accurate prompts, improving response quality and efficiency. This ignores the traditional RAG process and only guarantees the incremental addition of knowledge to the knowledge base.

[0192] For example, a user initiates and creates a performance analysis task, posing their question to the large model, such as: "Around noon today, Redis queries were slow; please help me analyze the cause." The Kubernetes platform, as the underlying runtime environment, creates a custom TaskResource resource upon receiving the user's question. This resource includes the task type, the type of middleware being queried, the task name, the user's question, and the task status (default is empty, nil). Simultaneously, the Operator controller (custom-developed based on Kubernetes) continuously monitors the TaskResource's status. Since the task status is empty by default, the Operator is triggered to perform the next operation, creating a Job-type Kubernetes resource to complete the expected user task.

[0193] The job task is divided into three phases: initialization, logging and monitoring, and command analysis. It primarily involves using the `mcp-client` to connect to different `mcp-server`s to obtain relevant information. In the initialization phase, the `mcp-client` first calls the `k8s-mcp-server` module to obtain the topology of the middleware being analyzed (server information, CPU / memory / storage information, IP address, port, authentication account password, etc.), extracts the IP address, port, and authentication account password, and downloads and starts the corresponding middleware MCP analysis plugin from the local private MCP repository. For example, in this case, for Redis, it downloads and starts the `redis-mcp-server`. In the logging and monitoring phase, the system first generates a large-scale prompt based on the `spec.content` field in the user's `TaskResource` (e.g., in this case, `spec.content` is "Around noon today, Redis experienced slow query behavior; please analyze the cause") and the middleware topology obtained in the initialization phase. This prompt guides the large-scale model analysis. The prompt word is sent to the locally deployed large model. The large model returns a tool call command. After the mcp-client recognizes the tool call command, it connects to the prometheus-mcp-server and es-mcp-server built into the Kubernetes cluster to obtain recent monitoring metrics and operation logs of the Redis middleware. The locally deployed large model performs preliminary inference based on the monitoring metrics and operation logs. If the current information can determine the root cause of the problem, the process ends early without further command analysis. During the command analysis phase, if the large model cannot determine the root cause of the problem based on the logs and monitoring, it generates executable commands within the Redis middleware (such as INFO, SLOWLOG GET, MONITOR, etc.) and calls the redis-mcp-server module started during the initialization phase to execute the commands and obtain the return information. The large model repeats the steps of executing commands and obtaining information until it obtains complete judgment information. The results are then summarized and formed into JSON data for subsequent processing.

[0194] As the Job task is completed, the TaskResource status changes from "empty" to "Success" and returns a rendered, easy-to-understand interface for the user to view. The system preprocesses and vectorizes JSON data, multi-turn dialogues, and other information and saves them to a vector database that the large model can read. When the user asks questions later, the large model will refer to historical data to answer subsequent questions, and at the same time, it will use new data to improve the database, forming a continuous cycle of feedback and optimization.

[0195] The following example illustrates the cloud-native middleware performance analysis method based on a large model proposed in this application:

[0196] Taking Redis performance analysis as an example, consider a 6-node Redis cluster running in Kubernetes as a stateful application. The goal is to analyze the reasons for slow execution. The process is as follows:

[0197] (a) User task declaration and resource definition

[0198] A custom Kubernetes resource object, TaskResource, is introduced to serve as the entry point for user analytics tasks. This resource type is registered with the cluster using a CRD (Custom Resource Definition).

[0199] (II) Operator Controller Scheduling and Task Management

[0200] The system has a built-in Operator developed based on the Kubernetes controller pattern, which is responsible for listening to and responding to TaskResources.

[0201] Listener triggered:

[0202] The Operator listens for TaskResource creation or modification events. Once a new task declaration is detected (such as status.phase == nil), the scheduling process is triggered.

[0203] Analysis task Job start:

[0204] The operator constructs an analysis job with environment parameters based on the middlewareType, namespace, and name fields in the CR, and then starts the actual analysis process. The job container has built-in mcp-client, k8s-mcp-server, and language model invocation modules.

[0205] Status Changes and Management:

[0206] The Operator is responsible for synchronizing the Job's running status to the CR's status.phase field in real time, for example, from Pending -> Running -> Success. If the task fails, a reason is entered and it is marked as Failed.

[0207] (III) Task Execution Logic (Three-Phase Process)

[0208] Task execution phase: Specifically, the analysis task in the job is divided into three phases: initialization phase, log and monitoring analysis phase, and command execution analysis phase.

[0209] Initialization phase:

[0210] 1. Call k8s-mcp-server to obtain the topology of the target Redis StatefulSet, including Pods, PVCs, Services, etc.;

[0211] 2. Automatically extract the IP address, port, and authentication information of the Redis instance (e.g., decrypt from the Secret);

[0212] 3. Download and start the redis-mcp-server subprocess for subsequent command execution and monitoring data collection;

[0213] 4. Generate middleware configuration files and complete sub-service initialization.

[0214] Log and monitoring analysis phase:

[0215] 1. The system constructs a Prompt based on the user-input spec.content field, combined with the Redis cluster context (such as master-slave structure, number of running nodes, etc.).

[0216] 2. Send a Prompt to the large language model deployed locally or remotely; the model returns an operation command of type Tool Call.

[0217] 3. The mcp-client identifies Tool Calls, connects to the prometheus-mcp-server and es-mcp-server, and pulls monitoring metrics and logs;

[0218] 4. The large model performs preliminary reasoning based on the returned data. If the root cause of the problem can be directly determined, the analysis ends early. If the cause cannot be determined, the next stage is performed.

[0219] Command analysis phase:

[0220] 1. A specific Redis instance node is selected within the larger model for in-depth command-level analysis;

[0221] 2. Generate commands (such as INFO, SLOWLOG GET, MONITOR, etc.), call redis-mcp-server to execute them, and obtain the return results;

[0222] 3. Multiple rounds of interaction until a complete judgment is formed or the analysis limit is reached;

[0223] 4. Upload all results and generate a final diagnostic conclusion JSON package.

[0224] (iv) Task result generation and CR backfilling

[0225] Report generation:

[0226] The system renders the JSON output from the model into an HTML report, uploads it to object storage, and generates an intranet or public network access link.

[0227] CR status update:

[0228] The operator writes the report link to the status.doc field, the model summary content to the status.reason field, and updates status.phase to Success.

[0229] Supports both callback and front-end display:

[0230] Users can obtain the current or historical analysis task status and results through kubectl get taskresource or the front-end visual interface.

[0231] (v) Automatic Knowledge Accumulation and Enhanced Retrieval (RAG)

[0232] The system periodically vectorizes knowledge documents (using vector models such as Qwen-Embedding / BGE) and stores them in a vector database.

[0233] When a user submits a new TaskResource, its content field will trigger a semantic vector retrieval process, extracting the most relevant knowledge fragments from the historical knowledge base and injecting them into the new task's Prompt, thus implementing a retrieval enhancement (RAG) mechanism for analytical reasoning.

[0234] The cloud-native middleware performance analysis method based on a large model proposed in this invention utilizes cloud-native operator capabilities to automate middleware analysis and diagnostic tasks, simplifying the interactive operation process. It boasts a high degree of automation: avoiding a series of independent and tedious operations such as manually querying logs, obtaining monitoring data, executing commands, and interacting with the large model, automating all processes. It also offers high data security: both the large model and the MCP tool are deployed in an intranet environment, preventing data leakage. Furthermore, it exhibits good scalability: based on the MCP tool approach, it can be decoupled from the large model and easily adapted to other middleware.

[0235] This invention also provides a cloud-native middleware performance analysis device based on a large model, as described in the following embodiments. Since the principle by which this device solves the problem is similar to the cloud-native middleware performance analysis method based on a large model, the implementation of this device can refer to the implementation of the cloud-native middleware performance analysis method based on a large model; repeated details will not be elaborated further.

[0236] Figure 4 This is a schematic diagram of a cloud-native middleware performance analysis device based on a large model provided in an embodiment of the present invention, such as... Figure 4 As shown, the device includes:

[0237] The task acquisition module 401 is used to receive a performance analysis task for cloud-native middleware created by the user, and then create task information based on the performance analysis task, the task information including the task status.

[0238] The task monitoring module 402 is used to monitor the task status of performance analysis tasks. When the task status is empty, the task resources are configured through the container orchestration platform.

[0239] The topology analysis module 403 is used to obtain the topology of the middleware to be analyzed and determine the configuration information of the middleware to be analyzed based on the topology of the middleware to be analyzed.

[0240] The initial reasoning module 404 is used to generate large model prompts based on task information and the topology of the middleware to be analyzed. After inputting the large model prompts into a preset large model, it obtains the monitoring indicators and operation logs of the middleware to be analyzed within a preset time period according to the configured task resources. Based on the monitoring indicators and operation logs, it uses the large model to initially reason about the reasons affecting the performance of the middleware to be analyzed. The large model prompts are used to guide the large model to analyze the problem. The large model is used to reason about the reasons affecting the performance of the middleware to be analyzed by calculating the health score of the middleware according to the prompts, monitoring indicators and operation logs. The health score is used to quantify the performance of the middleware.

[0241] The re-inference module 405 is used to obtain the internal operating data of the middleware based on the configuration information when the initial inference of the large model fails to find the cause affecting the performance of the middleware to be analyzed. Based on the internal operating data of the middleware, monitoring indicators and operating logs, the module re-infers the cause affecting the performance of the middleware to be analyzed through the large model.

[0242] In one embodiment, the task acquisition module 401 is specifically used for:

[0243] Based on the performance analysis task, create interface-level task information, which includes task type, middleware type to be analyzed, task name, user issue, and task status.

[0244] In one embodiment, the middleware includes a CPU and memory;

[0245] Initial reasoning module 404 is specifically used for:

[0246] Based on monitoring metrics and operation logs, assess CPU utilization health, throttling health, and trend health.

[0247] Calculate the CPU health score based on CPU utilization health, throttling health, and trend health.

[0248] Based on monitoring metrics and runtime logs, assess the health of memory usage, upper limit, and trend.

[0249] Calculate the memory health score based on memory usage health, upper limit health, and trend health.

[0250] Generate large model prompts based on preset fields in the task information and the topology of the middleware to be analyzed.

[0251] In one embodiment, the task monitoring module 402 is specifically used for:

[0252] The controller continuously monitors the task status in the task information;

[0253] When the task status is empty, a computing task resource is created through the controller.

[0254] In one embodiment, the topology analysis module 403 is specifically used for:

[0255] Obtain the topology of the middleware to be analyzed running on the container orchestration platform;

[0256] Based on the topology of the middleware to be analyzed, extract the IP address, port, and authentication account password of the middleware to be analyzed.

[0257] In one embodiment, the re-inference module 405 is specifically used for:

[0258] When the initial reasoning of the large model fails to identify the cause affecting the performance of the middleware to be analyzed, an executable read command is created within the middleware based on the IP address, port, and authentication account password in the middleware to be analyzed.

[0259] Based on the executable read commands within the created middleware, return the internal running data of the middleware with read-only permissions.

[0260] In one embodiment, a visualization module is further included, specifically for:

[0261] After identifying the cause affecting the performance of the middleware to be analyzed, set the task status of the performance analysis task to a success status.

[0262] The reasons affecting the performance of the middleware being analyzed are rendered into a visual interface for users to view.

[0263] In one embodiment, a knowledge feedback module is also included, specifically used for:

[0264] After identifying the causes affecting the performance of the middleware to be analyzed, obtain the intermediate data and the corresponding inference results during the inference process;

[0265] Based on the intermediate data and the corresponding reasoning results in the reasoning process, the knowledge base of the large model is updated. The knowledge base is constructed through text preprocessing and embedding model vectorization to build a retrieval foundation for enhancing the large model generation process.

[0266] Based on the aforementioned inventive concept, such as Figure 5 As shown, the present invention also proposes a computer device 500, including a memory 510, a processor 520, and a computer program 530 stored in the memory 510 and executable on the processor 520. When the processor 520 executes the computer program 530, it implements the aforementioned cloud-native middleware performance analysis method based on a large model.

[0267] This invention also provides a computer-readable storage medium storing a computer program that, when executed by a processor, implements the above-described cloud-native middleware performance analysis method based on a large model.

[0268] This invention also provides a computer program product, which includes a computer program that, when executed by a processor, implements the above-described cloud-native middleware performance analysis method based on a large model.

[0269] In summary, in this embodiment of the invention, after receiving a performance analysis task created by a user for a cloud-native middleware, task information is created based on the performance analysis task, including the task status; the task status of the performance analysis task is monitored, and when the task status is empty, task resources are configured through a container orchestration platform; the topology of the middleware to be analyzed is obtained, and the configuration information of the middleware to be analyzed is determined based on the topology; large model prompts are generated based on the task information and the topology of the middleware to be analyzed, and after inputting the large model prompts into a preset large model, the monitoring indicators and running days of the middleware to be analyzed within a preset time period are obtained based on the configured task resources. Based on monitoring metrics and operational logs, a large-scale model is used to initially infer the reasons affecting the performance of the middleware under analysis. The large-scale model uses prompts to guide its analysis, and, following these prompts, calculates a health score to quantify the middleware's performance. If the initial inference by the large-scale model fails to identify the cause affecting the middleware's performance, internal operational data is retrieved based on configuration information. This data, along with monitoring metrics and operational logs, is used to re-infer the cause of the performance impact through the large-scale model. This process, by receiving a performance analysis task, creating task information, configuring task resources based on task status, determining configuration information based on the middleware topology, generating prompts, retrieving monitoring metrics and operational logs of the middleware under analysis, using a large-scale model to infer the cause of the performance impact, and re-inferring internal middleware information when inference fails, improves the efficiency and accuracy of middleware performance analysis.

[0270] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage, CD-ROM, optical storage, etc.) containing computer-usable program code.

[0271] This invention is described with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of the invention. It will be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processor of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processor of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations and / or block diagrams. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0272] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0273] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0274] The specific embodiments described above further illustrate the purpose, technical solution, and beneficial effects of the present invention. It should be understood that the above descriptions are merely specific embodiments of the present invention and are not intended to limit the scope of protection of the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the scope of protection of the present invention.

Claims

1. A performance analysis method for cloud-native middleware based on a large model, characterized in that, include: After receiving a performance analysis task for cloud-native middleware created by a user, task information is created based on the performance analysis task, including the task status. Monitor the task status of performance analysis tasks, and configure task resources through the container orchestration platform when the task status is empty; Obtain the topology of the middleware to be analyzed, and determine the configuration information of the middleware to be analyzed based on the topology. Based on the task information and the topology of the middleware to be analyzed, a large model prompt is generated. After the large model prompt is input into the preset large model, the monitoring indicators and operation logs of the middleware to be analyzed within a preset time period are obtained according to the configured task resources. Based on the monitoring indicators and operation logs, the large model is used to preliminarily infer the reasons affecting the performance of the middleware to be analyzed. The large model prompt is used to guide the large model to analyze the problem. The large model is used to infer the reasons affecting the performance of the middleware to be analyzed by calculating the health score of the middleware according to the prompt, based on the monitoring indicators and operation logs. The health score is used to quantify the performance of the middleware. When the initial reasoning of the large model fails to identify the cause affecting the performance of the middleware to be analyzed, the internal operating data of the middleware is obtained based on the configuration information. Based on the internal operating data, monitoring indicators, and operating logs of the middleware, the cause affecting the performance of the middleware to be analyzed is re-inferred through the large model.

2. The method as described in claim 1, characterized in that, Create task information based on the performance analysis task, including: Based on the performance analysis task, create interface-level task information, which includes task type, middleware type to be analyzed, task name, user issue, and task status.

3. The method as described in claim 1, characterized in that, Monitor the task status of performance analysis tasks. When the task status is empty, configure task resources through the container orchestration platform, including: The controller continuously monitors the task status in the task information; When the task status is empty, a computing task resource is created through the controller.

4. The method as described in claim 1, characterized in that, Obtain the topology of the middleware to be analyzed, and determine its configuration information based on the topology, including: Obtain the topology of the middleware to be analyzed running on the container orchestration platform; Based on the topology of the middleware to be analyzed, extract the IP address, port, and authentication account password of the middleware to be analyzed.

5. The method as described in claim 4, characterized in that, When the initial reasoning of the large model fails to identify the reasons affecting the performance of the middleware to be analyzed, the internal operating data of the middleware is obtained based on the configuration information, including: When the initial reasoning of the large model fails to identify the cause affecting the performance of the middleware to be analyzed, an executable read command is created within the middleware based on the IP address, port, and authentication account password in the middleware to be analyzed. Based on the executable read commands within the created middleware, return the internal running data of the middleware with read-only permissions.

6. The method as described in claim 1, characterized in that, The middleware includes a CPU and memory; Based on monitoring metrics and runtime logs, a preliminary inference is made using a large model to determine the factors affecting the performance of the middleware under analysis, including: Based on monitoring metrics and operation logs, assess CPU utilization health, throttling health, and trend health. Calculate the CPU health score based on CPU utilization health, throttling health, and trend health. Based on monitoring metrics and operational logs, preliminary reasoning using a large model examines the factors affecting the performance of the middleware under analysis, including: Based on monitoring metrics and runtime logs, assess the health of memory usage, upper limit, and trend. Calculate the memory health score based on memory usage health, upper limit health, and trend health.

7. The method as described in claim 1, characterized in that, Also includes: After identifying the cause affecting the performance of the middleware to be analyzed, set the task status of the performance analysis task to a success status. The reasons affecting the performance of the middleware being analyzed are rendered into a visual interface for users to view.

8. The method as described in claim 1, characterized in that, Also includes: After identifying the causes affecting the performance of the middleware to be analyzed, obtain the intermediate data and the corresponding inference results during the inference process; Based on the intermediate data and the corresponding reasoning results in the reasoning process, the knowledge base of the large model is updated. The knowledge base is constructed through text preprocessing and embedding model vectorization to build a retrieval foundation for enhancing the large model generation process.

9. A cloud-native middleware performance analysis device based on a large model, characterized in that, include: The task acquisition module is used to receive a performance analysis task created by the user for cloud-native middleware, and then create task information based on the performance analysis task, including the task status. The task monitoring module is used to monitor the task status of performance analysis tasks. When the task status is empty, task resources are configured through the container orchestration platform. The topology analysis module is used to obtain the topology of the middleware to be analyzed and determine the configuration information of the middleware to be analyzed based on the topology. The initial reasoning module is used to generate large model prompts based on task information and the topology of the middleware to be analyzed. After inputting the large model prompts into a preset large model, the module obtains the monitoring indicators and operation logs of the middleware to be analyzed within a preset time period according to the configured task resources. Based on the monitoring indicators and operation logs, the module uses the large model to initially infer the reasons affecting the performance of the middleware to be analyzed. The large model prompts are used to guide the large model in analyzing problems. The large model is used to infer the reasons affecting the performance of the middleware to be analyzed by calculating the health score of the middleware according to the prompts, monitoring indicators, and operation logs. The health score is used to quantify the performance of the middleware. The re-inference module is used when the initial inference of the large model fails to find the cause affecting the performance of the middleware to be analyzed. Based on the configuration information, it obtains the internal operating data of the middleware, and re-infers the cause affecting the performance of the middleware to be analyzed through the large model based on the internal operating data, monitoring indicators and operation logs.

10. A computer device, comprising a memory, a processor, and a computer program stored in the memory and executable on the processor, characterized in that, When the processor executes the computer program, it implements the method of any one of claims 1 to 8.

11. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, implements the method of any one of claims 1 to 8.

12. A computer program product, characterized in that, The computer program product includes a computer program that, when executed by a processor, implements the method of any one of claims 1 to 8.

Images