Cloud-native application operation and troubleshooting method and device, and computer readable storage medium

Abstract

The application discloses a cloud-native application operation and maintenance troubleshooting method and device and a storage medium, and the method comprises the following steps: sending alarm information; acquiring topology information of a Pod instance corresponding to the alarm information; acquiring a near-time period alarm list and a near-time period index monitoring graph of an associated resource object from the topology information; determining an abnormal resource object based on a large language model and a multi-modal image model inference; extracting a feature vector of a current fault from the alarm information, near-time period log information and the near-time period index monitoring graph of the abnormal resource object, and screening a similar historical fault according to the similarity between the feature vector of the current fault and the feature vector of the historical fault; and performing root cause analysis based on the similar historical fault and technical document information of the abnormal resource object to determine a fault root cause. The above technical solution can at least accurately determine the fault root cause, improve the fault troubleshooting efficiency, and reduce the risk of business interruption caused by inaccurate or delayed manual judgment.

Description

Technical Field

[0001] This invention relates to the field of computer technology, and more specifically, to a method, apparatus, and computer-readable storage medium for troubleshooting and maintenance of cloud-native applications. Background Technology

[0002] In a Kubernetes environment, the general process for handling alarms is as follows: abnormal operation monitoring metrics of cloud-native application instances trigger preset alarm rules, and operations and maintenance personnel receive alarm information and discover the event; subsequently, by manually querying information such as Kubernetes, servers, applications, monitoring graphs, application logs, and system logs, the fault point is located and analyzed to determine the scope of impact, and the handling solution is retrieved from the knowledge base and system information documents.

[0003] However, the above process has the following problems.

[0004] (1) Risk of response delay: Too many manual intervention steps, from receiving alarm information and querying information to fault location, take a long time. Especially in distributed architecture, cross-service / cross-component failures may lead to a cascading effect, which in turn affects business continuity. For example, when a Pod restarts frequently due to OOM (Out-of-Memory), the process of manually checking CPU, memory and storage indicators layer by layer may miss the best time for intervention.

[0005] (2) Inaccurate impact assessment: When manually judging the scope of a fault, the impact of Kubernetes objects such as label selectors and network policies may be overlooked. In addition, there is a lack of similar fault matching based on knowledge base. Summary of the Invention

[0006] To address the aforementioned problems in related technologies, this invention proposes a cloud-native application operation and maintenance troubleshooting method and device, which can accurately determine the root cause of faults, improve fault diagnosis efficiency, and reduce the risk of business interruption caused by inaccurate or delayed manual judgment.

[0007] According to one aspect of the present invention, a method for troubleshooting and maintenance of cloud-native applications is provided, comprising the following steps: sending alarm information when the container group of a Pod instance of a cloud-native application is in an abnormal running state; obtaining topology information of the Pod instance corresponding to the alarm information, the topology information including associated resource objects of the Pod instance; obtaining a list of alarms and a monitoring graph of indicators for the associated resource objects in the near-term period from the topology information; analyzing the topology information, the list of alarms and the monitoring graph of indicators in the near-term period based on a large language model and a multimodal image model to infer and determine the abnormal resource objects; extracting the feature vector of the current fault from the alarm information, the log information of the abnormal resource objects in the near-term period, and the monitoring graph of indicators for the abnormal resource objects in the near-term period, and filtering out similar historical faults with a similarity higher than a preset threshold based on the similarity between the feature vector of the current fault and the feature vector of historical faults; and performing root cause analysis based on the technical documentation information of the similar historical faults and the abnormal resource objects to determine the root cause of the fault.

[0008] In some embodiments, the cloud-native application operation and maintenance troubleshooting method further includes: querying a knowledge base that matches the root cause of the fault, wherein the knowledge base includes technical documentation information of historical faults.

[0009] In some embodiments, the cloud-native application operation and maintenance troubleshooting method further includes: assessing the impact range of the root cause of the fault; and generating a repair plan by combining the root cause of the fault, the impact range, and the fault solution using a large language model and supporting retrieval technology.

[0010] In some embodiments, the feature vector of the current fault includes: the number of Pod restarts, CPU utilization, and memory utilization obtained from alarm information; error logs and warning logs obtained from near-period log information of the abnormal resource object; and CPU monitoring metrics, memory monitoring metrics, and network I / O monitoring metrics obtained from near-period metric monitoring graphs of the abnormal resource object.

[0011] In some embodiments, technical documentation information of the abnormal resource object is obtained from a knowledge base, wherein the technical documentation information of the abnormal resource object includes application development design documents, deployment architecture documents, and Kubernetes technical documents.

[0012] In some embodiments, sending alarm information includes: periodically collecting the running status of Pod instance container groups through a monitoring system; and sending alarm information when the running status of the Pod instance container group is abnormal and triggers a preset alarm rule of the monitoring system.

[0013] According to another aspect of the present invention, a cloud-native application operation and maintenance troubleshooting device is provided, characterized in that it includes: an information receiving module, used to receive alarm information sent when the running status of a Pod instance container group of a cloud-native application is abnormal; an information acquisition module, used to acquire topology information of the Pod instance corresponding to the alarm information, the topology information including the associated resource objects of the Pod instance, and used to acquire a near-time period alarm list and a near-time period indicator monitoring chart of the associated resource objects from the topology information; an analysis module, used to analyze the topology information, the near-time period alarm list, and the near-time period indicator monitoring chart using a large language model and a multimodal image model to infer and determine the abnormal resource objects; a fault matching module, used to extract the feature vector of the current fault from the alarm information, the near-time period log information of the abnormal resource objects, and the near-time period indicator monitoring chart of the abnormal resource objects, and to filter out similar historical faults with a similarity higher than a preset threshold based on the similarity between the feature vector of the current fault and the feature vector of historical faults; and a root cause determination module, used to perform root cause analysis based on the technical documentation information of similar historical faults and abnormal resource objects to determine the root cause of the fault.

[0014] In some embodiments, the cloud-native application operation and maintenance troubleshooting device further includes a solution matching module for querying fault solutions that match the root cause of the fault from a knowledge base, which includes technical documentation information of historical faults.

[0015] In some embodiments, the root cause determination module is also used to assess the impact range of the root cause of the fault; the cloud-native application operation and maintenance troubleshooting device also includes: a suggestion generation module, which is used to generate a repair plan by utilizing a large language model and supporting retrieval components and combining the root cause of the fault, the impact range and the fault solution.

[0016] According to another aspect of the present invention, a computer-readable storage medium is provided, characterized in that the computer-readable storage medium stores at least one instruction, which is executed by a processor in a computer device to implement the above-described cloud-native application operation and maintenance troubleshooting method.

[0017] The technical solution of this invention integrates various information sources, such as Pod instance topology information, near-period alarm lists, near-period metric monitoring charts, and near-period log information, to construct an automatic root cause localization mechanism based on correlation analysis. This mechanism automatically analyzes the potential root causes of faults, reducing the delays and errors associated with manual intervention. Furthermore, by leveraging the powerful emergent capabilities of large language models and combining them with similar fault matching, the root cause of faults can be accurately determined, significantly improving fault diagnosis efficiency and reducing the risk of business interruption due to inaccurate or delayed manual judgment. Attached Figure Description

[0018] To more clearly illustrate the technical solutions in the embodiments of the present invention or the prior art, the drawings used in the embodiments 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.

[0019] Figure 1 This is a flowchart of a cloud-native application operation and maintenance troubleshooting method according to an embodiment of this application.

[0020] Figure 2 This is a flowchart of a cloud-native application operation and maintenance troubleshooting method according to an embodiment of this application.

[0021] Figure 3 This is a block diagram of a cloud-native application operation and maintenance troubleshooting device according to an embodiment of this application.

[0022] Figure 4 This is a flowchart of a cloud-native application operation and maintenance troubleshooting method according to a specific embodiment of this application. Detailed Implementation

[0023] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. All other embodiments obtained by those skilled in the art based on the embodiments of the present invention are within the scope of protection of the present invention.

[0024] This application provides a method and apparatus for troubleshooting and maintaining cloud-native applications. The embodiments of this application are described below with reference to the accompanying drawings.

[0025] Figure 1 This is a flowchart of a cloud-native application operation and maintenance troubleshooting method according to an embodiment of this application. See also... Figure 1 As shown, the method 100 includes steps S102-S112.

[0026] In step S102, an alarm message is sent when the Pod instance container group of the cloud-native application is in an abnormal running state.

[0027] Step S102 may specifically include: periodically collecting the running status of Pod instance container groups through the monitoring system; and sending alarm information when the running status of the Pod instance container group is abnormal and triggers the preset alarm rules of the monitoring system.

[0028] Pod instance container groups can be included in a Kubernetes (also known as k8s) cluster. It should be understood that Kubernetes is an open-source container cluster management system from Google, providing a complete set of functions for containerized applications, including resource scheduling, deployment, service discovery, scaling, and more. Kubernetes is a brand-new distributed architecture solution based on container technology, and a one-stop, complete platform for distributed system development and support. A Pod is the smallest deployable computing unit that can be created and managed in Kubernetes. A Pod is a package of containers that share storage and network. Containers within a Pod are equal and scheduled together, running in a shared context.

[0029] It should also be understood that a Node is a worker node in Kubernetes, that is, a host server that hosts Pods. A Node typically contains multiple Pods, which are dynamically scheduled to that Node by the Kubernetes scheduling system based on cluster resources and scheduling policies. Node resources include CPU, memory, disk space, etc., which provide the computing resources required for Pods to run.

[0030] In step S104, the topology information of the Pod instance corresponding to the alarm information is obtained. This topology information includes the associated resource objects of the Pod instance. Associated resource objects may include other Pod instances, the Kubernetes node where the Pod resides, and other Pods on the same host. The topology information may also include the relationships and attributes between resource objects.

[0031] In step S106, the near-time period alarm list and near-time period indicator monitoring chart of the associated resource objects are obtained from the topology information obtained in step S104.

[0032] Then, in step S108, the topology information, the alarm list for the near-term period, and the monitoring chart of the near-term period indicators are analyzed based on Large Language Models (LLM) and multimodal image models to infer and determine the abnormal resource objects. At the same time, information such as the time of occurrence of the anomaly can also be inferred and determined.

[0033] A large language model is a language model constructed from deep neural networks containing hundreds of billions of parameters, typically trained using self-supervised learning methods on a large amount of unlabeled text. In one embodiment, the large language model is the Qwen2.5 model, but other suitable large language models may also be used; this application does not limit the specific type of the large language model. In one embodiment, the multimodal image model is the Qwen2.5-VL model, but other suitable multimodal image models may also be used; this application does not limit the specific type of the multimodal image model.

[0034] In step S110, the feature vector of the current fault is extracted from the alarm information, the near-time period log information of the abnormal resource object, and the near-time period indicator monitoring chart of the abnormal resource object. Based on the similarity between the feature vector of the current fault and the feature vector of the historical fault, similar historical faults with a similarity higher than a preset threshold are selected.

[0035] In step S112, root cause analysis is performed based on the technical document information of the selected similar historical faults and abnormal resource objects to determine and locate the root cause of the fault.

[0036] In some embodiments, technical documentation information for abnormal resource objects can be obtained from a knowledge base. The knowledge base may store various technical documentation information for various resource objects. This technical documentation information for the abnormal resource object may include application development design documents, deployment architecture documents, and Kubernetes technical documentation. The knowledge base may store technical documentation information for all resource objects (such as development design documents, deployment architecture documents, Kubernetes technical documentation, etc.).

[0037] Method 100 integrates various information sources, such as Pod instance topology information, near-period alarm lists, near-period metric monitoring graphs, and near-period log information, to construct an automated root cause localization mechanism based on correlation analysis. This mechanism automatically analyzes potential root causes of faults, reducing delays and errors associated with manual intervention. Furthermore, leveraging the powerful emergent capabilities of large language models and combining them with similar fault matching, the root cause of faults can be accurately determined, significantly improving troubleshooting efficiency and reducing the risk of business interruption due to inaccurate or delayed manual judgment.

[0038] In some embodiments, the feature vector of the current fault in step S110 may include: the number of Pod restarts, CPU utilization, and memory utilization obtained from alarm information; error logs and warning logs obtained from the near-term period log information of the abnormal resource object; and CPU monitoring metrics, memory monitoring metrics, and network I / O monitoring metrics obtained from the near-term period indicator monitoring graph of the abnormal resource object. In this embodiment, method 100 integrates multi-source monitoring data (such as cluster status, server performance indicators, application logs, system logs, etc.) to locate the root cause of the fault, which can further improve the accuracy of locating the root cause of the fault.

[0039] Specifically, the feature vector of the current fault is represented as: This includes alert information (such as Pod restart count, CPU utilization, memory utilization, etc.), monitoring metrics (such as CPU, memory, network I / O, etc.), and log information (such as error logs, warning logs, etc.). Feature vectors of historical faults can be extracted from the knowledge base. Calculate the feature vector F of the current fault. c The feature vector F of historical faults h cosine similarity : A similarity threshold can be preset, and historical faults with similarity higher than the threshold can be filtered out. Then, in step S112, in some embodiments, based on the matched similar faults, RAG (Retrieval-augmented Generation) technology can be used, combined with the contextual information of technical document information in the knowledge base, to match the root cause of the fault; if no match can be found in the technical document information of the knowledge base, the capabilities of the large model itself can be used to determine the root cause of the fault.

[0040] Figure 2 This is a flowchart of a cloud-native application operation and maintenance troubleshooting method according to an embodiment of this application. See also... Figure 2 As shown, the method 200 includes steps S102-S112 and steps S114 and S116. Figure 2 Steps S102-S112 in the illustrated embodiment can be the same as those above. Figure 1 Steps S102-S112 in the illustrated embodiment are the same, and are mainly described below. Figure 2 Steps S114-S118 in the illustrated embodiment.

[0041] In some embodiments, step S114 may be included after step S112, querying a fault solution matching the root cause of the fault from a knowledge base. The knowledge base may include technical documentation information about historical faults, and fault solutions matching the root cause of the fault can be queried from this information, such as maintenance manuals, emergency manuals, etc. This further integrates information from the knowledge base to automatically query fault solutions.

[0042] In step S116, the scope of impact of the root cause of the failure is assessed. Step S116 can be performed simultaneously with step S112. In some embodiments, the scope of impact can be accurately assessed by combining the application system access relationship topology, the faulty Pod instance, and the root cause of the failure.

[0043] Step S118 involves generating a repair plan by combining the root cause of the fault, the scope of impact, and the fault solution using a large language model and supporting retrieval technologies. These supporting retrieval technologies may include RAG and DeepResearch. The large language model and its supporting retrieval components can be collectively referred to as large model technology. Therefore, intelligent recommendation of the optimal repair plan is achieved, thus realizing full automation and standardization of the entire process from problem discovery to determining the repair plan. Through automation and intelligence, the delay and error of manual intervention are reduced, significantly improving fault diagnosis efficiency.

[0044] An embodiment of this application also provides a cloud-native application operation and maintenance troubleshooting device. Figure 3 This is a block diagram of a cloud-native application operation and maintenance troubleshooting device according to an embodiment of this application. (Reference) Figure 3 As shown, the cloud-native application operation and maintenance troubleshooting device 300 (hereinafter referred to as device 300) may include an information receiving module 310, an information acquisition module 320, an analysis module 330, a fault matching module 340, and a root cause determination module 350.

[0045] The information receiving module 310 can be used to receive alarm information sent when the running status of the Pod instance container group of a cloud-native application is abnormal, such as the alarm information sent in step S102 above.

[0046] The information acquisition module 320 can be used to acquire the topology information of the Pod instance corresponding to the alarm information. The topology information includes the associated resource objects of the Pod instance, and is used to acquire the alarm list and monitoring graph of the associated resource objects in the near time period from the topology information. The information acquisition module 320 can be used to execute the above steps S104 and S106.

[0047] The analysis module 330 can be used to analyze topology information, near-time period alarm lists, and near-time period indicator monitoring charts using large language models and multimodal image models to infer and determine abnormal resource objects. In some embodiments, the use of large language models and multimodal image models can be part of the analysis module 330, or it can be independent of the analysis module 330. The analysis module 330 can be used to perform the above-described step S108.

[0048] The fault matching module 340 can be used to extract the feature vector of the current fault from alarm information, near-time period log information of abnormal resource objects, and near-time period indicator monitoring charts of abnormal resource objects. Furthermore, the fault matching module 340 can also filter out similar historical faults with a similarity higher than a preset threshold based on the similarity between the feature vector of the current fault and the feature vector of historical faults. The fault matching module 340 can be used to perform the above step S110.

[0049] The root cause determination module 350 can be used to perform root cause analysis based on technical documentation information of similar historical faults and abnormal resource objects to determine the root cause of the fault. The root cause determination module 350 can be used to perform the above-described step S112. In some embodiments, the root cause determination module 350 can also be used to assess the scope of impact of the root cause of the fault.

[0050] The above-described method 100 can be implemented by means of device 300, and the advantages described above regarding method 100 can be achieved.

[0051] In some embodiments, the apparatus 300 may further include a solution query module for querying fault solutions that match the root cause of the fault from a knowledge base. This solution query module can be used to perform step S114 described above.

[0052] In some embodiments, the apparatus 300 may further include a suggestion generation module for generating a repair plan by utilizing a large language model and accompanying retrieval components, and combining the root cause of the fault, the scope of impact, and the fault solution.

[0053] In some embodiments, device 300 can be specifically implemented as an intelligent operation and maintenance troubleshooting Bot assistant. By leveraging the powerful emergent capabilities of large language models, an intelligent operation and maintenance troubleshooting Bot assistant can be developed that can parse alarm information in real time, automatically query relevant system status, logs, and monitoring data, and combine a knowledge base to match similar faults, accurately assessing the scope of fault impact. Through automation and intelligence, the efficiency of fault diagnosis is significantly improved, reducing the risk of business interruption caused by inaccurate or delayed human judgment.

[0054] Embodiments of this application also provide a computer-readable storage medium storing at least one instruction, which is executed by a processor in a computer device to implement the above-described cloud-native application operation and maintenance troubleshooting method.

[0055] Figure 4 This is a flowchart of a cloud-native application operation and maintenance troubleshooting method according to a specific embodiment of this application. Figure 4 In this context, cloud-native application operation and maintenance troubleshooting methods are executed through the aforementioned device 300. Furthermore... Figure 4 This example illustrates a fault scenario where the Pod instance container group in the model inference framework is running abnormally.

[0056] See Figure 4 As shown, the method begins with fault detection and pre-processing. Specifically, it includes: Step S411, the model inference framework Pod instance container group's running status is abnormal, for example, the App (application) Pod restarts multiple times consecutively; S412, the monitoring system periodically collects the Pod instance's running status; S413, the abnormal running status of the Pod instance container group triggers the monitoring system's preset alarm rules; S414, the monitoring system sends alarm information to device 300. Alarm information can also be sent to the operations and maintenance personnel (Engineer) at this point.

[0057] Step S420: Device 300 receives alarm information sent by the monitoring system and initiates the fault troubleshooting process.

[0058] Step S430: Obtain Pod topology information for the model inference framework. Device 300 obtains the topology information of Pod instances from the Kubernetes cluster. The topology information includes: resource objects associated with Pod instances (such as other Pod instances, the Kubernetes Node where the Pod resides, other Pods on the same host, etc.) and the relationships and attributes between resource objects.

[0059] Then, the alarm list and indicator monitoring chart of the associated resource objects are obtained. Specifically, this includes: S441, the device 300 obtains the alarm list of the associated resource objects in the Pod topology information for the near time period from the monitoring system; S442, the device 300 obtains the indicator monitoring chart of the associated resource objects in the Pod topology information for the near time period from the monitoring system.

[0060] Step S450: Infer the abnormal resource objects and the time of occurrence. Based on the large language model and multimodal image model, the device 300 analyzes the acquired Pod topology information, the alarm list of associated resource objects, and the indicator monitoring chart to infer the abnormal resource objects and the time of occurrence.

[0061] Step S460: Device 300 obtains the near-term period log information of the relevant resource objects from the Logging System.

[0062] Step S470: Device 300 obtains technical documentation information of the abnormal resource object from the knowledge base, including application development design documents, deployment architecture documents, Kubernetes technical documents, etc.

[0063] Step S480: Perform root cause analysis and similar fault matching, as described above with reference to steps S110 and S112. Additionally, the scope of influence of the faulty resource object can be determined, as described above with reference to step S116.

[0064] Then, repair suggestions are generated. Specifically, this may include: Step S491, where the device 300 queries the knowledge base for fault solutions similar to the current root cause of the fault; and Step S492, where the device 300 combines the root cause of the fault, the scope of impact, and the solutions in the knowledge base, and uses large model technology to perform analysis and reasoning to generate repair suggestions / solutions.

[0065] Step S495: Device 300 sends the root cause of the fault, the scope of impact, and repair suggestions to the maintenance personnel. The maintenance personnel can then use these suggestions to repair the fault.

[0066] In summary, this invention introduces an intelligent operation and maintenance troubleshooting Bot assistant (device 300) based on a large language model. This Bot assistant can not only parse alarm information in real time, but also automatically query and analyze multi-source data such as Kubernetes cluster status, server performance metrics, application logs, and system logs through large model technology. By combining historical faults and solutions in a knowledge base, the Bot assistant can quickly locate the root cause of a fault and intelligently recommend the optimal repair solution. This significantly improves the efficiency and accuracy of fault diagnosis, reduces the need for manual intervention, and lowers the risk of business interruption due to response delays or misjudgments.

[0067] Furthermore, this invention introduces a knowledge-based, similar fault matching mechanism. This mechanism can automatically match the similarity of historical fault data with the current fault, thereby quickly locating the root cause and providing a repair solution. This not only improves the accuracy of fault diagnosis but also continuously optimizes the fault handling process through the accumulation and updating of the knowledge base, enhancing the system's intelligence level.

[0068] This invention also significantly reduces the time investment and technical learning costs for maintenance personnel through a standardized, low-cost intelligent operation and maintenance troubleshooting process. Through automation and intelligence, the system can quickly respond to faults and provide practical repair solutions, thereby significantly shortening fault handling time and ensuring business continuity and stability.

[0069] The technical solution of this invention effectively solves the problem of application service anomalies caused by untimely handling of cloud-native application instance node failures in Kubernetes environments. Through a standardized, low-cost intelligent operation and maintenance troubleshooting process, combined with large-scale model technology, it achieves rapid fault location and intelligent recommendation of repair solutions. This not only improves the timeliness of fault handling but also enhances the level of problem repair, providing strong support for the intelligent operation and maintenance of cloud-native applications and effectively ensuring the stable operation of business applications.

[0070] The above description is only a preferred embodiment of the present invention and is not intended to limit the present invention. Any modifications, equivalent substitutions, improvements, etc., made within the spirit and principles of the present invention should be included within the protection scope of the present invention.

Claims

1. A cloud-native application operation and troubleshooting method, characterized in that, Includes the following steps: When the Pod instance container group of a cloud-native application is in an abnormal running state, an alarm message is sent. Obtain the topology information of the Pod instance corresponding to the alarm information, wherein the topology information includes the associated resource objects of the Pod instance; Obtain the near-time period alarm list and near-time period indicator monitoring chart of the associated resource objects from the topology information; The topology information, the alarm list for the near time period, and the monitoring chart for the near time period indicators are analyzed based on the large language model and the multimodal image model to infer and determine the abnormal resource objects. The feature vector of the current fault is extracted from the alarm information, the near-time period log information of the abnormal resource object, and the near-time period indicator monitoring chart of the abnormal resource object. Based on the similarity between the feature vector of the current fault and the feature vector of historical faults, similar historical faults with a similarity higher than a preset threshold are selected. Root cause analysis is performed based on the technical documentation information of the similar historical faults and the abnormal resource objects to determine the root cause of the fault.

2. The cloud-native application operation troubleshooting method of claim 1, wherein, Also includes: The system retrieves fault solutions that match the root cause of the fault from a knowledge base, which includes technical documentation information on historical faults.

3. The cloud-native application operation troubleshooting method of claim 2, wherein, Also includes: Assess the scope of impact of the root cause of the failure; A repair plan is generated by combining the root cause of the fault, the scope of impact, and the fault solution using a large language model and supporting retrieval technology.

4. The cloud-native application operation and maintenance troubleshooting method as described in claim 1, characterized in that, The feature vector of the current fault includes: the number of Pod restarts, CPU utilization, and memory utilization obtained from the alarm information; error logs and warning logs obtained from the near-time period log information of the abnormal resource object; and CPU monitoring metrics, memory monitoring metrics, and network I / O monitoring metrics obtained from the near-time period indicator monitoring graph of the abnormal resource object.

5. The cloud-native application operation and maintenance troubleshooting method as described in claim 1, characterized in that, Retrieve the technical documentation information of the abnormal resource object from the knowledge base. The technical documentation information of the abnormal resource object includes the application's development and design documents, deployment architecture documents, and Kubernetes technical documents.

6. The cloud-native application operation troubleshooting method of claim 1, wherein, Sending the alarm information includes: The system periodically collects the running status of the Pod instance container group through a monitoring system. When the abnormal running status of the Pod instance container group triggers the preset alarm rules of the monitoring system, the alarm information is sent.

7. A cloud-native application operation and troubleshooting device, characterized in that, include: The information receiving module is used to receive alarm information sent when the Pod instance container group of a cloud-native application is in an abnormal running state; The information acquisition module is used to acquire the topology information of the Pod instance corresponding to the alarm information. The topology information includes the associated resource objects of the Pod instance. The module is also used to acquire the alarm list and the monitoring graph of the near time period of the associated resource objects from the topology information. The analysis module is used to analyze the topology information, the near-time period alarm list, and the near-time period indicator monitoring chart using a large language model and a multimodal image model in order to infer and determine abnormal resource objects. The fault matching module is used to extract the feature vector of the current fault from the alarm information, the near-time period log information of the abnormal resource object and the near-time period indicator monitoring chart of the abnormal resource object, and filter out similar historical faults with similarity higher than a preset threshold based on the similarity between the feature vector of the current fault and the feature vector of historical faults. The root cause determination module is used to perform root cause analysis based on the technical documentation information of the similar historical faults and the abnormal resource objects to determine the root cause of the fault.

8. The cloud-native application operation troubleshooting device according to claim 7, wherein, Also includes: The solution matching module is used to query a knowledge base that matches the root cause of the fault, the knowledge base including technical documentation information of historical faults.

9. The cloud-native application operation and maintenance troubleshooting device as described in claim 8, characterized in that, The root cause determination module is also used to assess the scope of the impact of the root cause of the failure. The cloud-native application operation and maintenance troubleshooting device also includes: It is recommended to generate a module that utilizes a large language model and supporting retrieval components, combined with the root cause of the fault, the scope of impact, and the fault solution, to generate a repair plan.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores at least one instruction, which is executed by a processor in a computer device to implement the cloud-native application operation and maintenance troubleshooting method as described in any one of claims 1 to 6.

Images