Microservice performance problem diagnosis and repair method and system
By combining large models and reinforcement learning, we acquire and process data from microservice systems, identify root causes, and perform adaptive repairs. This solves the problem of difficult diagnosis in existing technologies and improves the stability and operational efficiency of microservice systems.
Patent Information
- Application Number
- CN202511209862.X
- Authority / Receiving Office
- CN · China
- Patent Type
- Applications(China)
- Current Assignee / Owner
- Filing Date
- 2025-08-27
- Publication Date
- 2025-11-28
AI Technical Summary
Diagnosing performance problems in microservice systems is difficult, especially due to complex dependencies and dynamic changes leading to abnormal propagation of causal relationships. Solving performance problems in large-scale systems is also challenging. Existing technologies struggle to accurately reveal the underlying causes and causal relationships of problems, leading to an expansion of the scope of failures.
A method combining large-scale modeling and reinforcement learning is adopted to acquire data from microservice systems, perform preprocessing and feature extraction, use the trained large-scale model to identify root causes, and use a reinforcement learning agent to make repair action decisions. The reward function is used to guide the agent to learn the optimal strategy, and training and optimization are carried out in a simulation environment.
It enables accurate location and adaptive repair of performance issues in microservice systems, improving operational efficiency and system stability, and reducing misjudgments and the escalation of faults.
Smart Images

Figure CN121029569A_ABST
Abstract
Description
TECHNICAL FIELD
[0001] The present application belongs to the field of microservice performance, and particularly relates to a microservice performance problem diagnosis and repair method and system. BACKGROUND
[0002] The statements in this section merely provide background information related to the present application and do not necessarily constitute the prior art.
[0003] The stability of the enterprise microservice system is crucial, but in actual use, performance problems such as high latency and low availability often occur. The performance problems of the microservice system can be caused by many different factors, involving hardware resources, network communication, configuration management, and code implementation, etc. Moreover, due to the large number of services, dynamic changes, complex relationships, abnormal propagation along the call chain, and the existence of non-causal relationships in the call chain, it is very time-consuming and laborious to diagnose the root cause of the performance problem of the large-scale microservice system, and even the fault range may be expanded due to misjudgment.
[0004] The traditional diagnosis method mainly relies on threshold alarms, manual rules, expert experience, or considers the call relationship between services as the causal relationship of abnormal propagation, but this method needs to be simplified too much and cannot accurately reveal the deep reasons and causal relationships of the problem occurrence, and lacks self-adaptive decision-making ability. SUMMARY
[0005] In order to solve the above problems, the present application provides a microservice performance problem diagnosis and repair method and system, which can guarantee the availability of the microservice system and the stable operation of the business.
[0006] According to some embodiments, the present application adopts the following technical scheme: A microservice performance problem diagnosis and repair method, comprising the following steps: Obtaining various data of the microservice system running, specifically including performance indicators, logs, traces, events, topology and configuration data; Pretreating the obtained various data, extracting features, and performing preliminary anomaly detection; Using the trained large model to identify the root cause of the microservice performance problem, and converting the various data into a state representation that can be understood by the agent in reinforcement learning; According to the preliminary anomaly detection result, triggering the reinforcement learning process, and deciding the repair action according to the current state representation. In the decision-making process, the target of the reward function guides the agent to learn a strategy that can effectively repair the problem and minimize the negative impact; Converting the repair action obtained by decision-making into actual operation, obtaining the various data of the microservice system running after the actual operation, calculating the reward value of this action according to the reward function, and optimizing the large model; The data obtained after the repair is re-input into the optimized large model for the next round of decision-making.
[0007] As an optional implementation, the following steps are also included: The data obtained after the repair is re-input into the optimized large model for the next round of decision-making. In response to a manual trigger instruction or a disabled agent automatic repair instruction, the reinforcement learning process is exited.
[0008] As an optional implementation, the performance indicators include CPU usage, memory usage, network delay, throughput, error rate, response time, GC time, thread pool state, database connection number, and several of QPS. The logs include several of error logs, alarm logs, request logs, and slow query logs. The tracking includes the request call chain between services and the time consumption of each service. The events include several of alarm information, deployment events, configuration change events, and scaling events. The topology includes several of the call relationship between services, the dependency relationship, and the deployment structure. The configuration data includes several of application configuration, infrastructure configuration, and JVM parameters.
[0009] As an optional implementation, the process of pre-processing the obtained data, extracting features, and performing preliminary anomaly detection includes: unifying data of different sources and formats, and ensuring that all data are aligned by timestamp. Calculate the moving average, standard deviation, and growth rate to obtain feature data. Use threshold alarm or trained machine learning model for preliminary anomaly detection, and use the result as the trigger signal of reinforcement learning.
[0010] As an optional implementation, the process of identifying the microservice performance problem root cause using the trained large model and converting the data into a state representation that the agent can understand in reinforcement learning includes: the large model converts the data into semantic and structured state features, including problem summary vector, abnormal indicator vector, related service and resource state vector, preliminary root cause probability vector, and topology context encoding. The large model learns the service performance history baseline, deployment information, and recent change record from the historical data, which is also part of the state vector of reinforcement learning.
[0011] As an alternative implementation, according to the preliminary anomaly detection result, the process of triggering the reinforcement learning process according to the current state representation to decide the repair action includes: the environment of reinforcement learning is the microservice system, the state space is the semanticized and structured state vector generated by the large model, and the action space includes scaling, configuration adjustment, restart, traffic control, database optimization suggestion and code suggestion. The action granularity is for a single service, a service group or an infrastructure level. When the large model identifies a certain root cause, a series of related repair actions are provided to form a subset, and the agent selects a corresponding action in the subset.
[0012] As an alternative implementation, the reward function includes positive rewards and negative rewards, the positive rewards include: the performance index returns to the baseline level, and the time for the system to run stably after repair meets the requirements. The negative rewards include further performance degradation after repair, resource waste, introduction of new faults or unstable factors, repair time exceeding the set value, and still requiring manual intervention.
[0013] As an alternative implementation, during the process of optimizing the large model, a rollback mechanism is provided, and if the repair action causes performance degradation or introduces new problems, the system is rolled back to the previous state.
[0014] A microservice performance problem diagnosis and repair system includes: A data acquisition module configured to acquire various data of a microservice system running, including performance indicators, logs, traces, events, topology and configuration data; A preprocessing module configured to preprocess the acquired various data, extract features, and perform preliminary anomaly detection; A root cause identification and state encoding module configured to identify the root cause of the microservice performance problem using the trained large model, and convert various data into a state representation that can be understood by the agent in reinforcement learning; A reinforcement learning decision module configured to trigger the reinforcement learning process according to the preliminary anomaly detection result, and decide the repair action according to the current state representation. During the decision process, the target of the reward function is to guide the agent to learn a strategy that can effectively repair the problem and minimize negative impact. An execution and feedback module configured to convert the repair action decided by the decision into actual operation, acquire various data of the microservice system running after the actual operation, calculate the reward value of the action according to the reward function, and optimize the large model; re-input the various data acquired after repair into the optimized large model to make the next round of decision.
[0015] A computer readable storage medium for storing computer instructions, which, when executed by a processor, complete the steps in the above method.
[0016] An electronic device comprising a memory and a processor and computer instructions stored on the memory and running on the processor, which, when executed by the processor, complete the steps in the above method.
[0017] Compared with the prior art, the beneficial effects of the present application are: The present application takes response time, error rate, number of timeout calls, distributed tracking, system and application logs, and topology data of inter-service dependencies as input, uses the natural language understanding and causal reasoning capabilities of large models, and uniformly analyzes multi-modal data such as logs (such as unstructured text) and indicators (such as numerical sequences) scattered in different services and different components, to achieve comprehensive perception of complex context; at the same time, the large model can refine the input raw data into a state vector rich in semantics, high-dimensional but more representative, thereby greatly improving the understanding ability of the reinforcement learning agent to microservice performance problem scenarios.
[0018] The present application can fine-tune the model using existing microservice performance problems, root cause data and repair solutions, collect a batch of known microservice performance problem related data, initialize the model, customize the data set, and set the training parameters to train the model. Based on general knowledge and fine-tuned domain knowledge, the model can discover hidden correlations from seemingly unrelated data and infer problem root causes, such as code defects, configuration errors, resource bottlenecks or external dependencies, etc. This model not only identifies root causes, but also provides potential repair action suggestions for specific root causes to the reinforcement learning agent, or assists in filtering out a more reasonable action subset, thereby reducing the exploration space of reinforcement learning and improving learning efficiency.
[0019] The present application uses reinforcement learning to regard root cause analysis and repair as a unified decision-making process. A suitable reward function is designed, which can quantify the repair effect, such as performance improvement, stability, etc., and punish negative effects, such as resource waste, introduction of faults, to guide the agent to learn the optimal repair strategy, such as maximizing performance while minimizing resource consumption. In addition, the agent balances exploration (i.e. trying new actions) and utilization (i.e. selecting known best actions) to discover new and better repair strategies through continuous interaction with the environment, rather than being limited to known solutions; after sufficient training, the agent can provide robust repair solutions based on the general patterns it has learned when faced with unknown or variant performance problems. In summary, the system can adaptively adjust the repair strategy based on real-time environmental feedback, so that it can cope with complex and dynamically changing microservice environments.
[0020] The present application aims at the high risk of reinforcement learning training in a production environment, and constructs a simulation environment capable of simulating the behavior, traffic pattern and fault injection of a microservice system, so that the agent can be trained and policy verified in a safe and controllable environment. The agent of reinforcement learning is fully trained offline in the simulation environment to obtain a relatively stable initial policy, and the policy can be fine-tuned online to further optimize the performance of the agent by using real data.
[0021] The present application uses causal reasoning to locate the possible root cause of performance problems in a large-scale microservice system, and the introduction of reinforcement learning enables the system to learn from experience and adjust the repair strategy according to the real-time system state, realizing adaptive repair instead of simple rule matching, which can significantly improve the operation and maintenance efficiency and the overall resilience and stability of large-scale microservice systems. The system continuously learns and accumulates knowledge during operation, including knowledge extracted by large models and strategies optimized by reinforcement learning agents, forming an enterprise-specific intelligent operation and maintenance brain, providing valuable tests for future system design and optimization.
[0022] In order to make the above-mentioned objects, features and advantages of the present application more apparent, the following preferred embodiments are described in detail below, and the accompanying drawings are used for explanation. BRIEF DESCRIPTION OF DRAWINGS
[0023] The drawings constituting a part of the specification of the present application are used to provide a further understanding of the present application, and the schematic embodiments of the present application and their descriptions are used to explain the present application, and do not constitute an improper limitation on the present application.
[0024] Figure 1 It is a flowchart of a microservice performance problem diagnosis and repair method of an embodiment. DETAILED DESCRIPTION
[0025] The present application will be further described below in combination with the drawings and embodiments.
[0026] It should be pointed out that the following detailed description is exemplary and is intended to provide further explanation of the present application. Unless otherwise specified, all technical and scientific terms used herein have the same meaning as generally understood by those skilled in the art to which the present application belongs.
[0027] It should be noted that the terms used herein are only for the purpose of describing specific embodiments, and are not intended to limit the exemplary embodiments according to the present application. As used herein, unless the context clearly indicates otherwise, the singular form is intended to include the plural form, and in addition, it should be understood that when the terms "comprise" and / or "include" are used in the specification, they indicate the presence of a feature, step, operation, device, component and / or their combination.
[0028] Where there is no conflict, the embodiments and features described in this application may be combined with each other.
[0029] Example 1 A method for diagnosing and repairing microservice performance issues includes the following steps: Acquire various data related to the operation of the microservice system, including performance metrics, logs, traces, events, topology, and configuration data. The acquired data are preprocessed, features are extracted, and preliminary anomaly detection is performed. The trained large model is used to identify the root causes of microservice performance problems, and the data is converted into state representations that can be understood by the agent in reinforcement learning. Based on the initial anomaly detection results, a reinforcement learning process is triggered. The agent makes a decision on the corrective action based on the current state. During the decision-making process, the target bit of the reward function guides the agent to learn a strategy that can effectively correct the problem and minimize the negative impact. The repair actions obtained from the decision are converted into actual operations, and various data of the microservice system operation after the actual operation are obtained. The reward value of this action is calculated according to the reward function, and the large model is optimized. The data obtained after the repair are re-input into the optimized large model for the next round of decision-making.
[0030] In some embodiments, the following steps are also included: Record various data of the current operation and historical operation of the microservice system, record the current state of the agent, the root causes of the identified microservice performance problems, and the corrective actions and execution results of the decisions; And, in response to a manually triggered command or a command to disable the agent's automatic repair function, exit the reinforcement learning process.
[0031] The following is a detailed description of each step.
[0032] Firstly, during data collection and preprocessing, various data points are collected during the microservice system's runtime, specifically including: Metrics: such as CPU utilization, memory usage, network latency, throughput, error rate, response time, GC time, thread pool status, database connection count, and QPS collected by tools like Prometheus; Logs: error logs, alert logs, request logs, and slow query logs collected by tools like ELK Stack; Traces: distributed tracing data collected by tools like SkyWalking, showing the call chain between services and the execution time of each service; Events: alert information, deployment events, configuration change events, scaling events, etc.; Topology: call relationships, dependencies, and deployment structure (containers, virtual machines, physical machines) between services; and Configuration: application configuration, infrastructure configuration, and JVM parameters.
[0033] Of course, the above data is only an example. In different embodiments, a portion of the data may be selected or other data may be added, depending on the circumstances.
[0034] The next step is data preprocessing, which includes standardization and cleaning to unify data from different sources and formats.
[0035] And time series alignment: ensure all data is aligned by timestamp.
[0036] Extract features and calculate derived indicators such as moving average, standard deviation, and growth rate to form features.
[0037] Then, use threshold alerts or small machine learning models for preliminary anomaly detection. If an anomaly is found, it serves as a trigger signal to call the large model and enter reinforcement learning.
[0038] Next, a large model is used to initially identify the root causes of microservice performance problems, and the raw data is transformed into a state representation that can be understood by the reinforcement learning agent.
[0039] Large models are capable of integrating and understanding multimodal data. Based on pre-trained knowledge and domain knowledge, they can infer multiple possible root causes from massive amounts of data and provide confidence scores.
[0040] Large-scale models assist in generating more semantic and structured state features required for reinforcement learning training, including problem summary vectors (embedded representations of the text summary of the current performance problem by the large model), anomaly indicator vectors (encoding of the name, degree, and trend of the identified anomaly indicator), related service and resource state vectors (encoding of the service ID, health status, and resource utilization related to the anomaly), preliminary root cause probability vectors (probability distributions of various potential root causes inferred by the large model, such as network, database, JVM, code logic, and insufficient resources), and topological context encoding.
[0041] Similarly, the above state vectors can be added, subtracted, or changed as needed.
[0042] In addition, large models can provide other background knowledge, such as the service's historical performance baseline (learned from the system's historical metrics data, log data, and tracking data), deployment information (integration of deployment and release system data), and recent change records (integrated from the configuration center). This information, as part of the reinforcement learning state, helps the agent better understand the current situation.
[0043] In implementation, this embodiment selects a generalized large model, such as Qwen, and designs prompt words to guide the large model to extract relevant information from the original data and generate state features. Combined with CoT (Chain-of-Thought) technology, the large model can demonstrate its reasoning process when generating states, thereby improving interpretability.
[0044] In reinforcement learning decision-making, the appropriate corrective action is determined based on the current state. The core components include: the agent (the reinforcement learning model itself), which learns the optimal policy through interaction with the environment; and the environment, which is the microservice system.
[0045] The state space is a semantic and structured state feature vector generated by a large model, such as [problem_summary_embedding, top_k_abnormal_metrics_vector, root_cause_probabilities, impacted_service_health_vector].
[0046] Action space: Discrete actions include scaling up / down (increasing / decreasing the number of service instances, adjusting CPU and memory quotas), configuration adjustments (adjusting JVM parameters, thread pool size, database connection pool size, timeout, and cache expiration time), restarting (restarting specific service instances), traffic control (rate limiting, degradation, circuit breaking), database optimization suggestions (providing suggestions for slow SQL and index optimization), and code suggestions (providing possible code optimization directions for high CPU consumption, memory leaks, etc.). Action granularity: targeting a single service, service group, or infrastructure level. Large model-assisted action generation: when the large model identifies a root cause (such as frequent JVM GC), it provides a series of related repair actions (such as increasing heap memory and changing the GC algorithm), and the agent selects from this subset.
[0047] The core objective of the reward function is to guide the agent to learn strategies that can effectively fix problems and minimize negative impacts.
[0048] include: Positive rewards: Improved performance metrics (key performance metrics such as average response time, error rate, CPU utilization, and throughput are restored to baseline levels) and stability (the time it takes for the system to run stably after the repair). Negative rewards include: performance degradation (further performance decline after repair), resource waste (unnecessary over-expansion), side effects (introduction of new faults or instabilities), repair time (the longer the repair time, the greater the penalty), and manual intervention (requiring manual intervention with significant penalties).
[0049] Similarly, the above content is only an example and can be adjusted or added to according to specific circumstances.
[0050] In this embodiment, the specific reward function is designed as follows: The design principles include: (1) combining immediacy and latency, rewarding immediate performance improvements while penalizing potential negative impacts in the future; (2) multi-objective optimization: not just restoring a single metric, but balancing multiple interrelated metrics (such as response time, throughput, error rate, and resource utilization); (3) combining sparse and dense rewards: providing larger sparse rewards at certain critical moments (such as problem resolution); and providing dense, continuous reward signals at other times through continuous evaluation of performance metrics; (4) penalizing undesirable behaviors: explicitly penalizing ineffective operations, excessive intervention, resource waste, or the introduction of new faults; and (5) interpretability and adjustability: the weights and components of the reward function are clear and understandable, facilitating adjustments and optimizations by operations personnel based on actual business needs. The reward function is designed as a weighted sum, comprising the following parts:
[0051] in, Rewards for performance improvements: The main reward is to encourage agents to restore performance metrics to normal levels, and is calculated based on changes in key performance indicators (KPIs).
[0052] Metrics selection: Response time / latency (L), such as P99 latency and average latency, with the goal of reduction; Throughput (E): such as HTTP 5xx error rate and application internal anomaly rate, with the goal of reduction; Throughput (T): such as requests per second (QPS), with the goal of improvement; CPU utilization (C), memory utilization (M), etc.: If the root cause is a performance bottleneck, reducing these metrics will have a positive impact; if they are symptoms of performance degradation, they should be improved as the core problem is resolved.
[0053] Calculation method: Measure the change of the current indicator value from the baseline or ideal target value before the problem occurred, using percentage change or difference, and normalize it.
[0054] For metrics where smaller is better (such as latency and error rate):
[0055] For metrics where larger is always better (such as throughput):
[0056] Wherein, the index "baseline" represents the baseline value of the item, the index "before_action" represents the value before the corresponding item performs the action, and the index "after_action" represents the value after the corresponding item performs the action. These are all corresponding weight values.
[0057] Sparse reward for problem-solving: A large positive reward is given when all key problem KPIs return to below the normal threshold within a certain time window.
[0058]
[0059] Rewards for stability and robustness Agents are encouraged to choose fixes that provide long-term stability, avoiding jitter or the introduction of new instability factors.
[0060] Indicator volatility penalty: After the fix, if the short-term volatility of the relevant performance indicators (such as response time, throughput) increases, a negative reward is given, for example, by using the reciprocal of the standard deviation or the increment of the standard deviation as a penalty.
[0061]
[0062] New Fault Avoidance Rewards / Penalties: A positive reward is given if the repair operation does not introduce new alarms or errors; a larger negative reward is given if a new fault is introduced.
[0063]
[0064] Long-term stable operation reward: When the agent fixes the problem, the system maintains stable operation for a period of time (such as a few minutes or hours), and a continuous, small positive reward is given.
[0065] Penalty based on resource costs; Encourage agents to minimize resource consumption and costs while fixing issues.
[0066] Additional resource usage penalty: If the repair operation results in unnecessary expansion (increase in CPU, memory, number of instances), a negative reward will be given based on the amount of increased resources.
[0067] ; Repair operation complexity penalty: For operations that require more system privileges, have a wide impact, or take a long time to execute, a slight penalty is imposed to encourage agents to prioritize low-cost, low-risk repairs.
[0068]
[0069] Negative impact / risk penalty is used to directly punish unwanted behaviors, such as repair failures, human intervention, or operational risks.
[0070] Repair timeout penalty: If a problem is not resolved within a preset time window, a negative reward is given. The longer the repair time, the greater the penalty.
[0071]
[0072] Human intervention penalty: If human intervention is ultimately required to resolve the issue, a very large negative reward is given, indicating that the agent failed to complete the task independently.
[0073]
[0074] Invalid / Prohibited Operation Penalty: If the agent attempts to perform an operation that is configured to be invalid or prohibited, a large negative reward is immediately given.
[0075]
[0076] The chosen training algorithm is an Actor-Critic type reinforcement learning framework, such as A3C (Asynchronous Advantage Actor-Critic).
[0077] The weights for each item can be set as follows: ; in The weights are adjustable. In actual training, a large number of experiments and optimizations can be carried out according to business priorities and system characteristics. Generally, the rewards for solving problems and the penalties for manual intervention are set to be relatively large in order to strongly guide the agent to learn in the desired direction.
[0078] Training environment: Build a high-fidelity microservice system simulation environment to simulate various performance issues, train the agent in it, and then fine-tune it online in the production environment.
[0079] Next, the agent's decisions are translated into actual operations, and their effects are monitored. The executor integrates with existing operation and maintenance tools, calling interfaces provided by cloud platform APIs (such as the Kubernetes API), configuration management tools, service frameworks, etc.
[0080] During this process, strict control over executor permissions is necessary to ensure operational safety and rollback capability. After the repair action is executed, the system continues to monitor performance metrics, logs, and tracking data, calculating the reward value for this action based on a predefined reward function. New observation data is then input into the large model to generate new state representations for the agent to use in the next round of decision-making.
[0081] This embodiment is equipped with a rollback mechanism. If the repair action leads to performance degradation or introduces new problems, the system can roll back to the previous state.
[0082] In addition, this embodiment sets up an experience replay buffer: used to store the (State, Action, Reword, NextState, Done) quintuple. The agent randomly samples data from the buffer for training, improving learning efficiency and stability.
[0083] It also includes a large model knowledge base: storing root causes and repair knowledge pairs extracted from historical data by large models, common performance problem patterns, prior knowledge for agents, or for initializing reinforcement learning strategies.
[0084] It also includes an expert experience database: storing successful repair cases and best practices manually marked by operation and maintenance experts, which can be used to constrain the action space or as demonstration data for agent training.
[0085] Interactions (states, actions, rewards, new states) can be stored in an experience replay buffer. The agent can continue to make decisions based on the new state, or the model can be trained / updated after a fixed interval or when the experience replay buffer reaches a certain amount.
[0086] This embodiment utilizes a dashboard to display system performance indicators in real time. It also shows the agent's current status, predicted root causes, selected actions, and execution results, as well as historical repair records and effects.
[0087] Provides manual intervention points: Allows operations and maintenance personnel to manually trigger the repair process or disable agent-based automatic repair. Manual review is required before critical or high-risk repair operations. Experts are allowed to fine-tune the reward function and action space of reinforcement learning. Operations and maintenance personnel can provide feedback on the system's diagnostic and repair effectiveness for iterative model optimization, particularly fine-tuning the reward function and large models.
[0088] If the system cannot resolve the issue, or the risk is too high, manual intervention is triggered. Operations personnel can view the diagnostic results of the large model and the decision-making process of reinforcement learning, and manually repair or adjust the model.
[0089] Example 2 A microservice performance problem diagnosis and repair system, comprising: The data acquisition module is configured to acquire various data from the operation of the microservice system, including performance metrics, logs, traces, events, topology, and configuration data. The preprocessing module is configured to preprocess the acquired data, extract features, and perform preliminary anomaly detection. The root cause identification and state encoding module is configured to use the trained large model to identify the root causes of microservice performance problems and convert the data into state representations that the agent can understand in reinforcement learning. The reinforcement learning decision module is configured to trigger the reinforcement learning process based on the initial anomaly detection results, and decide on the corrective action to be taken based on the current state. During the decision-making process, the target bit of the reward function guides the agent to learn a strategy that can effectively correct the problem and minimize the negative impact. The execution and feedback module is configured to convert the repair actions obtained from the decision into actual operations, acquire various data of the microservice system operation after the actual operation, calculate the reward value of this action according to the reward function, optimize the large model, and re-input the various data obtained after the repair into the optimized large model for the next round of decision-making.
[0090] Example 3 A computer-readable storage medium for storing computer instructions, which, when executed by a processor, perform the steps in the method provided in Embodiment 1.
[0091] Example 4 An electronic device includes a memory and a processor, as well as computer instructions stored in the memory and running on the processor, wherein the computer instructions, when executed by the processor, perform the steps in the method provided in Embodiment 1.
[0092] 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 one or more computer-usable storage media (including, but not limited to, disk storage, etc.) containing computer-usable program code. CD - ROM It takes the form of a computer program product implemented on (such as optical memory, etc.).
[0093] 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.
[0094] 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.
[0095] 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.
[0096] The above description is merely a preferred embodiment of the present invention and is not intended to limit the invention. Various modifications and variations can be made to the present invention by those skilled in the art. Any modifications, equivalent substitutions, improvements, etc., made by those skilled in the art without creative effort within the spirit and principles of the present invention should be included within the scope of protection of the present invention.
Claims
1. A method for diagnosing and repairing microservice performance issues, characterized in that, Includes the following steps: Acquire various data related to the operation of the microservice system, including performance metrics, logs, traces, events, topology, and configuration data. The acquired data are preprocessed, features are extracted, and preliminary anomaly detection is performed. The trained large model is used to identify the root causes of microservice performance problems, and the data is converted into state representations that can be understood by the agent in reinforcement learning. Based on the initial anomaly detection results, a reinforcement learning process is triggered. The agent makes a decision on the corrective action based on the current state. During the decision-making process, the target bit of the reward function guides the agent to learn a strategy that can effectively correct the problem and minimize the negative impact. The repair actions obtained from the decision are converted into actual operations, and various data of the microservice system operation after the actual operation are obtained. The reward value of this action is calculated according to the reward function, and the large model is optimized. The data obtained after the repair are re-input into the optimized large model for the next round of decision-making.
2. The method for diagnosing and repairing microservice performance issues as described in claim 1, characterized in that, It also includes the following steps: Record various data of the current operation and historical operation of the microservice system, record the current state of the agent, the root causes of the identified microservice performance problems, and the corrective actions and execution results of the decisions; And, in response to a manually triggered command or a command to disable the agent's automatic repair function, exit the reinforcement learning process.
3. The method for diagnosing and repairing microservice performance issues as described in claim 1, characterized in that, The performance metrics include several of the following: CPU utilization, memory usage, network latency, throughput, error rate, response time, GC time, thread pool status, database connection count, and QPS. The logs include several of the following: error logs, alarm logs, request logs, and slow query logs. The tracing includes the call chain of requests between services and the time spent in each service; The events include several types of events such as alarm messages, deployment events, configuration change events, and scaling-up / scaling events; The topology includes several aspects of service call relationships, dependency relationships, and deployment structures; The configuration data includes several of the following: application configuration, infrastructure configuration, and JVM parameters.
4. The method for diagnosing and repairing microservice performance issues as described in claim 1, characterized in that, The process of preprocessing the acquired data, extracting features, and performing preliminary anomaly detection includes: standardizing data from different sources and formats, and ensuring that all data is aligned by timestamps; Calculate the moving average, standard deviation, and growth rate to obtain the characteristic data; Use threshold alerts or trained machine learning models for initial anomaly detection, and use the results as a trigger signal for reinforcement learning.
5. The method for diagnosing and repairing microservice performance problems as described in claim 1, characterized in that, The process of using a trained large model to identify the root causes of microservice performance problems and converting various data into state representations that can be understood by the agent in reinforcement learning includes: the large model converts various data into semantic and structured state features, including problem summary vectors, anomaly index vectors, related service and resource state vectors, preliminary root cause probability vectors, and topological context encoding; The large model learns historical baselines of service performance, deployment information, and recent change records from historical data, which are also used as part of the state vector in reinforcement learning.
6. The method for diagnosing and repairing microservice performance problems as described in claim 1, characterized in that, Based on the preliminary anomaly detection results, a reinforcement learning process is triggered. The process of deciding on the corrective actions based on the current state representation includes: if the preliminary anomaly detection results indicate the presence of an anomaly, a reinforcement learning process is triggered. The reinforcement learning environment is a microservice system, the state space is a semantic and structured state vector generated by a large model, and the action space includes scaling up / down, configuration adjustment, restart, traffic control, database optimization suggestions, and code suggestions. The action granularity is at the level of a single service, service group, or infrastructure. When the large model identifies a root cause, it provides a series of related remedial actions, forming a subset, from which the agent selects the appropriate action.
7. The method for diagnosing and repairing microservice performance problems as described in claim 1, characterized in that, The reward function includes positive rewards and negative rewards. The positive rewards include: performance indicators recovering to the baseline level and the system running stably for the required time after repair. Negative rewards include further performance degradation after repair, waste of resources, introduction of new faults or instabilities, repair time exceeding the set value, and still requiring manual intervention; It also has a rollback mechanism in place, so if the repair action causes performance degradation or introduces new problems, the system will roll back to the previous state.
8. A microservice performance problem diagnosis and repair system, characterized in that, include: The data acquisition module is configured to acquire various data from the operation of the microservice system, including performance metrics, logs, traces, events, topology, and configuration data. The preprocessing module is configured to preprocess the acquired data, extract features, and perform preliminary anomaly detection. The root cause identification and state encoding module is configured to use the trained large model to identify the root causes of microservice performance problems and convert the data into state representations that the agent can understand in reinforcement learning. The reinforcement learning decision module is configured to trigger the reinforcement learning process based on the initial anomaly detection results, and decide on the corrective action to be taken based on the current state. During the decision-making process, the target bit of the reward function guides the agent to learn a strategy that can effectively correct the problem and minimize the negative impact. The execution and feedback module is configured to convert the repair actions obtained from the decision into actual operations, acquire various data of the microservice system operation after the actual operation, calculate the reward value of this action according to the reward function, and optimize the large model. The data obtained after the repair are re-input into the optimized large model for the next round of decision-making.
9. A computer-readable storage medium, characterized in that, Used to store computer instructions, which, when executed by a processor, complete the steps of the method according to any one of claims 1-7.
10. An electronic device, characterized in that, It includes a memory and a processor, as well as computer instructions stored in the memory and running on the processor, which, when executed by the processor, perform the steps of the method according to any one of claims 1-7.
Citation Information
Cited By
Micro-service real-time performance monitoring and self-healing system, method and equipment based on C + + and medium
CN121364984A
A C++ based micro-service real-time performance monitoring and self-healing system, method, device and medium
CN121364984B
