Method and device for diagnosing abnormal restart of application, electronic equipment and medium

Abstract

The invention provides a method and device for diagnosing abnormal restart of an application, electronic equipment and a medium, and the method comprises the steps: determining the type and diagnosis information of a restart event for the Pod restart event monitored by an abnormal monitoring component; obtaining a first target diagnosis process matched with an application Pod restart event from a pre-configured target knowledge base through an RAG technology, and generating a target prompt word of a target diagnosis model matched with the application Pod restart event; sending a target prompt word of the application Pod restart event, the first target diagnosis process and diagnosis information to a target diagnosis model, and determining a tool subset and a second target diagnosis process which are recommended to be used for the application Pod restart event; according to the tool subset recommended to be used and the second target diagnosis process, arranging and calling multiple analysis tools, and determining a diagnosis result, so that the diagnosis efficiency is improved, the root cause is quickly positioned, and the fault recovery time is shortened.

Description

TECHNICAL FIELD

[0001] The present application relates to the technical field of microservices, in particular to a method and device for diagnosing application abnormal restart, an electronic device and a medium. BACKGROUND

[0002] With the wide application of microservice architecture, cloud computing and containerization technology, in the cloud native scenario, the abnormal restart of application containers is a common problem in the operation and maintenance process. Abnormal restart may be caused by various factors, such as insufficient resources, code defects, dependent service failures, configuration errors or platform underlying problems, etc. The traditional abnormal diagnosis method usually relies on the experience of operation and maintenance personnel, combined with log analysis, monitoring indicators and link tracking tools for manual troubleshooting. However, with the expansion of system scale and the increase of architecture complexity, manual diagnosis is inefficient and difficult to quickly locate the root cause, resulting in prolonged fault recovery time and affecting business stability. SUMMARY

[0003] Therefore, the purpose of the present application is to provide a method and device for diagnosing application abnormal restart, an electronic device and a medium, which can improve the diagnosis efficiency, quickly locate the root cause and reduce the fault recovery time.

[0004] The method for diagnosing application abnormal restart provided by the present application comprises the following steps: For the application Pod restart event monitored by the abnormal monitoring component, the category and diagnosis information of the application Pod restart event are determined; Based on the category and diagnosis information of the application Pod restart event, a first target diagnosis process matching the application Pod restart event is obtained from a pre-configured target knowledge base through RAG technology; Based on the target template matched with the category of the application Pod restart event, a target prompt word matching the target diagnosis model of the application Pod restart event is generated; The target prompt word of the application Pod restart event, the first target diagnosis process and the diagnosis information are sent to the target diagnosis model, and the target prompt word, the first target diagnosis process and the diagnosis information are processed by the target diagnosis model to determine the tool subset and the second target diagnosis process recommended for the application Pod restart event; the tool subset includes multiple analysis tools in the tool set; According to the recommended tool subset and the second target diagnosis process, the arrangement and calling of multiple analysis tools are performed to determine the diagnosis result of the application Pod restart event.

[0005] In some embodiments, the method for diagnosing application abnormal restart further comprises the following steps after determining the category and diagnosis information of the application Pod restart event: According to the cluster to which the application pod belongs, a plurality of types of target clients required for initializing an exception analysis agent.

[0006] In some embodiments, in the method for diagnosing abnormal restart of an application, the processing of the target prompt word, the first target diagnosis process and diagnosis information by the target diagnosis model includes: The target diagnosis model is pre-trained and performs process optimization on the first target diagnosis process by reasoning to determine a tool set and a second target diagnosis process recommended for use in the application pod restart event. The process optimization includes tool screening, diagnosis step screening, and sorting of tools and diagnosis steps.

[0007] In some embodiments, in the method for diagnosing abnormal restart of an application, after determining the diagnosis result of the application pod restart event, the method further includes: Receiving a score value and / or evaluation text for the diagnosis result of the application pod restart event.

[0008] In some embodiments, the method for diagnosing abnormal restart of an application further includes: Based on the score value and / or evaluation text for the diagnosis result of the application pod restart event, adjusting the existing diagnosis process and / or adding a new diagnosis process to obtain an updated diagnosis process. The knowledge base vectorizes the updated diagnosis process and stores the vectorized diagnosis process.

[0009] In some embodiments, the method for diagnosing abnormal restart of an application further includes: In response to receiving an adjustment operation for an analysis tool, generating an adjustment instruction; the adjustment operation includes adding a tool, deleting a tool, and modifying a tool. Processing the previously generated plurality of tool sets and the adjustment instruction by the target diagnosis model to generate a pre-validation result of the adjustment instruction; the pre-validation result represents the impact of the adjustment instruction on the diagnosis process. Based on the pre-validation result, secondly confirming the adjustment operation, and adjusting the analysis tools in the tool set based on the second confirmation result.

[0010] In some embodiments, in the method for diagnosing abnormal restart of an application, the arrangement and calling of a plurality of analysis tools according to the recommended tool set and the second target diagnosis process to determine the diagnosis result of the application pod restart event include: perform orchestration calling of the plurality of analysis tools according to the recommended tool subset and the second target diagnosis process, and obtain return results of the plurality of analysis tools; send the return results of the plurality of analysis tools to a target diagnosis model, analyze and summarize the return results of the plurality of analysis tools by the target diagnosis model, and determine a diagnosis result of the application Pod restart event.

[0011] In some embodiments, a device for diagnosing application abnormal restart is also provided, and the device comprises: a first determination module configured to determine a category and diagnosis information of an application Pod restart event listened to by an abnormal monitoring component; an acquisition module configured to acquire, based on the category and diagnosis information of the application Pod restart event, a first target diagnosis process matching the application Pod restart event from a pre-configured target knowledge base by RAG technology; a generation module configured to generate, based on a target template matched with the category of the application Pod restart event, a target prompt word of the application Pod restart event matched with a target diagnosis model; a processing module configured to send the target prompt word of the application Pod restart event, the first target diagnosis process, and the diagnosis information to a target diagnosis model, process the target prompt word, the first target diagnosis process, and the diagnosis information by the target diagnosis model, and determine a tool subset and a second target diagnosis process recommended to be used for the application Pod restart event; the tool subset comprises a plurality of analysis tools in a tool set; a second determination module configured to perform orchestration calling of the plurality of analysis tools according to the recommended tool subset and the second target diagnosis process, and determine a diagnosis result of the application Pod restart event.

[0012] In some embodiments, an electronic device is also provided, which comprises a processor, a memory, and a bus, the memory stores machine readable instructions executable by the processor, when the electronic device is running, the processor and the memory communicate through the bus, and the machine readable instructions are executed by the processor to perform the steps of the method for diagnosing application abnormal restart.

[0013] In some embodiments, a computer readable storage medium is also provided, and the computer readable storage medium stores a computer program, when the computer program is executed by a processor, the steps of the method for diagnosing application abnormal restart are performed.

[0014] In the embodiments of the present application, a method for diagnosing abnormal restart of an application is provided. The method determines the category and diagnosis information of an application Pod restart event monitored by an abnormal monitoring component. Based on the category and diagnosis information of the application Pod restart event, a first target diagnosis process that matches the application Pod restart event is obtained from a pre-configured target knowledge base through RAG technology. Based on the target template matched with the category of the application Pod restart event, a target prompt word of the application Pod restart event that matches the target diagnosis model is generated. The target prompt word of the application Pod restart event, the first target diagnosis process and the diagnosis information are sent to the target diagnosis model. The target prompt word, the first target diagnosis process and the diagnosis information are processed by the target diagnosis model to determine a tool subset and a second target diagnosis process recommended for the application Pod restart event. The tool subset includes multiple analysis tools in the tool set. The recommended tool set and the second target diagnosis process are used to arrange and call the multiple analysis tools to determine the diagnosis result of the application Pod restart event. Thus, the analysis capability of the large model and the multi-Agent cooperation technology are combined to improve the diagnosis efficiency and accuracy of the application container abnormal restart, provide reliable support for operation and maintenance decision, shorten the abnormal diagnosis time and improve the operation and maintenance efficiency. BRIEF DESCRIPTION OF DRAWINGS

[0015] In order to more clearly illustrate the technical solutions of the embodiments of the present application, the drawings needed in the embodiments will be briefly introduced below. It should be understood that the following drawings only show some embodiments of the present application, and therefore should not be regarded as a limitation on the scope. For those skilled in the art, other related drawings can also be obtained without creative labor on the basis of these drawings.

[0016] Figure 1 A flowchart of the method for diagnosing abnormal restart of an application according to the embodiments of the present application is shown. Figure 2 A component architecture diagram of the system for diagnosing abnormal restart of an application according to the embodiments of the present application is shown. Figure 3 A step schematic diagram of the method for diagnosing abnormal restart of an application according to the embodiments of the present application is shown. Figure 4 A flowchart of the method for determining the diagnosis result of the application Pod restart event according to the embodiments of the present application is shown. Figure 5 An optimized step schematic diagram of the method for diagnosing abnormal restart of an application according to the embodiments of the present application is shown. Figure 6A structural schematic diagram of the device for diagnosing abnormal restarts is shown. Figure 7 A structural schematic diagram of the electronic device is shown. DETAILED DESCRIPTION

[0017] To make the objectives, technical solutions, and advantages of the embodiments of the present application clearer, the following will clearly and completely describe the technical solutions in the embodiments of the present application with reference to the drawings in the embodiments of the present application. It should be understood that the drawings in the present application only serve the purpose of description and illustration, and are not used to limit the scope of protection of the present application. In addition, it should be understood that the schematic drawings are not drawn to scale. The flowcharts show the operations implemented according to some embodiments of the present application. It should be understood that the operations of the flowcharts can not be implemented in sequence, and the steps without logical context relationship can be reversed in sequence or implemented simultaneously. In addition, one or more other operations can be added to the flowcharts or one or more operations can be removed from the flowcharts under the guidance of the content of the present application.

[0018] In addition, the described embodiments are only some of the embodiments of the present application, not all the embodiments. The components of the embodiments of the present application described and shown in the drawings herein can be arranged and designed in various different configurations. Therefore, the following detailed description of the embodiments of the present application provided in the drawings is not intended to limit the scope of the claimed present application, but only represents selected embodiments of the present application. Based on the embodiments of the present application, all other embodiments obtained by those skilled in the art without creative labor fall within the scope of protection of the present application.

[0019] It should be noted that the term “comprising” will be used in the embodiments of the present application to indicate the presence of the features declared thereafter, but does not exclude the addition of other features.

[0020] With the wide application of micro-service architecture, cloud computing and containerization technology, in the cloud-native scenario, the abnormal restart of the application container is a common problem in the operation and maintenance process. Abnormal restarts can be caused by various factors, such as insufficient resources, code defects, dependent service failures, configuration errors, or platform underlying problems. Traditional abnormal diagnosis methods usually rely on the experience of operation and maintenance personnel, combined with log analysis, monitoring indicators, and link tracking tools for manual troubleshooting. However, with the expansion of system size and the increase of architecture complexity, manual diagnosis is inefficient, and it is difficult to quickly locate the root cause, resulting in prolonged fault recovery time and affecting business stability.

[0021] The reasons for the low efficiency of existing application diagnosis are related to the following defects of the prior art.

[0022] Dependence on human experience, low efficiency: Traditional operation and maintenance relies on expert experience to manually analyze logs and monitoring data, and the troubleshooting process is time-consuming, with low operation and maintenance efficiency.

[0023] Data island problem: Logs, monitoring, links, application configuration, and other data are scattered in different systems, lack effective integration, and manual correlation analysis is difficult, making it difficult to form a global perspective.

[0024] Inaccurate root cause positioning: Existing methods can only provide surface error information (such as OOM, CrashLoopBackOff, etc.), and cannot analyze the root cause of the abnormality, making it difficult to analyze the root cause.

[0025] Lack of troubleshooting dimensions: Existing solutions often focus on explicit errors (such as error logs, CPU / Memory indicators), but ignore key implicit factors.

[0026] Weakness in time series analysis: Lack of multi-dimensional data correlation analysis of key time windows before and after abnormal events (such as 5 minutes before restart).

[0027] Configuration change blind spot: Existing tools cannot effectively correlate, such as restarts caused by image updates, scaling strategies, etc.

[0028] Based on this, in the embodiments of the present application, a method for diagnosing application abnormal restart is provided. The method determines the category and diagnosis information of the application Pod restart event listened to by the abnormal monitoring component; based on the category and diagnosis information of the application Pod restart event, a first target diagnosis process that matches the application Pod restart event is obtained from a pre-configured target knowledge base through RAG technology; based on the target template matched with the category of the application Pod restart event, a target prompt word that matches the target diagnosis model of the application Pod restart event is generated; the target prompt word of the application Pod restart event, the first target diagnosis process, and the diagnosis information are sent to the target diagnosis model, and the target prompt word, the first target diagnosis process, and the diagnosis information are processed through the target diagnosis model to determine the tool subset and the second target diagnosis process recommended for the application Pod restart event; the tool subset includes multiple analysis tools in the tool set; the recommended tool set and the second target diagnosis process are used to arrange and call multiple analysis tools, and the diagnosis result of the application Pod restart event is determined, thereby combining the analysis capability of the large model and the multi-Agent collaboration technology, RAG (Retrieval-Augmented Generation) retrieval-enhanced generation technology, improving the diagnosis efficiency and accuracy of application container abnormal restart, providing reliable support for operation and maintenance decision-making, shortening the abnormal diagnosis time, and improving the operation and maintenance efficiency.

[0029] Please refer toFigure 1 , Figure 1 A flowchart of the method for diagnosing abnormal restart of an application is shown. As shown in Figure 1 , the method comprises the following steps S101-S105: S101, for the application Pod restart event monitored by the abnormal monitoring component, determining the category and diagnosis information of the application Pod restart event; S102, based on the category and diagnosis information of the application Pod restart event, acquiring a first target diagnosis process matching the application Pod restart event from a pre-configured target knowledge base through RAG technology; S103, based on the target template matching the category of the application Pod restart event, generating a target prompt word of the target diagnosis model matching the application Pod restart event; S104, sending the target prompt word of the application Pod restart event, the first target diagnosis process and the diagnosis information to the target diagnosis model, processing the target prompt word, the first target diagnosis process and the diagnosis information through the target diagnosis model, and determining a tool subset and a second target diagnosis process recommended for the application Pod restart event; the tool subset comprises a plurality of analysis tools in the tool set; S105, performing arrangement and calling of the plurality of analysis tools according to the recommended tool set and the second target diagnosis process, and determining the diagnosis result of the application Pod restart event.

[0030] The method for diagnosing abnormal restart of an application is applied to a system for diagnosing abnormal restart of an application. Please refer to Figure 2 , Figure 2 A component architecture diagram of the system for diagnosing abnormal restart of an application is shown.

[0031] As shown in Figure 2 , the system is used for intelligent diagnosis of abnormal restart of an application based on a large model, and comprises two components of an abnormal monitoring and analysis framework; the abnormal monitoring component is deployed on a Kubernetes cluster where the application runs, and the analysis framework component is deployed on a management and control cluster.

[0032] The abnormal monitoring component mainly listens to the restart event of the application Pod by means of the list-watch mechanism of K8S; at the same time, it also classifies the abnormal scenarios of the Pod, such as OOM, normal exit, abnormal exit, node eviction, etc. In addition, it also saves information required for subsequent analysis and diagnosis processes, such as exit code, restart time, K8S event description information, namespace, pod name, etc. In addition, a RESTful API interface is provided for the analysis framework component to query.

[0033] The analysis framework component mainly includes the following modules: exception analysis agent, tool management, environment management, model management, knowledge management, and analysis management.

[0034] Exception analysis agent: used for analyzing and processing the abnormal restart of application Pods.

[0035] Tool management: used for managing the tool set required by the analysis process. The analysis tools can be added, deleted, modified, and inquired, and various tool states can be tested.

[0036] Environment management: used for managing multi-center and multi-cluster information.

[0037] Model management: used for managing large models used in the analysis and diagnosis process, which can be local large models or commercial large models.

[0038] Knowledge management: includes local knowledge base, knowledge retrieval, and knowledge update functions. It is used to save the analysis and diagnosis process of Pod abnormal restart, and can update the existing analysis process.

[0039] Analysis management: includes analysis scoring, analysis process saving, and analysis process querying functions. The operation and maintenance personnel can score the analysis process of Pod abnormal restart, then update the knowledge base, and optimize the subsequent analysis process.

[0040] Please refer to Figure 3 , Figure 3 The steps of the method for diagnosing application abnormal restart according to the embodiments of the present application are shown in the schematic diagram. In step S101, for the application Pod restart event monitored by the exception monitoring component, the category and diagnosis information of the application Pod restart event are determined.

[0041] Please refer to step 1 in Figure 3 The exception monitoring component listens to the restart event of the application Pod by means of the list-watch mechanism of K8S, and preliminarily classifies the abnormal restart of the Pod, determines and saves the diagnosis information of the application Pod restart event.

[0042] The category of the application Pod restart event includes OOM, normal exit, abnormal exit, node eviction, and the like.

[0043] The diagnosis information of the application Pod restart event is the information required in the subsequent analysis and diagnosis process, such as exit code, restart time, K8S event description information, namespace, pod name, and pod belonging cluster information.

[0044] The embodiment of the application utilizes a self-developed abnormality monitoring component to listen to the restart event of the application Pod by means of the list-watch mechanism of K8S. At the same time, the abnormal restart event of the Pod is preliminarily classified, and the information required for subsequent analysis and diagnosis is saved. In this way, the subsequent diagnosis and analysis process selection is facilitated, and the problem analysis time is saved.

[0045] Compared with directly using a large model for abnormality analysis, by classifying the abnormal event first, the analysis efficiency of the large model can be significantly improved, and the accuracy of locating the root cause of the abnormality can be improved. At the same time, the self-developed abnormality monitoring component also collects multi-dimensional information, including but not limited to: program exit code, program exit time, application pod name, Pod IP, Pod namespace to which the Pod belongs, and the like. These information provides accurate basis for subsequent analysis, and improves the accuracy of large model analysis.

[0046] When the application Pod restart event monitored by the abnormality monitoring component meets the preset diagnosis condition, the diagnosis process of steps S102-S105 is triggered.

[0047] Please refer to step 2 in Figure 3 The preset diagnosis condition can be that the analysis framework component obtains the restart event of the Pod at a regular time, or the user actively triggers the obtaining of the restart event of the Pod.

[0048] After the step S101, that is, after determining the category of the application Pod restart event and the diagnosis information, the method further comprises: According to the cluster to which the application Pod belongs, various types of target clients required by the abnormality analysis Agent are initialized.

[0049] Specifically, please refer to step 3 in Figure 3 According to the cluster to which the Pod belongs, various client clients required by the abnormality analysis Agent are initialized, such as K8S client, Promethues client, and the like.

[0050] The abnormality analysis Agent is specially used for automatically diagnosing the application Pod restart event and determining the diagnosis result. Specifically, the abnormality analysis Agent performs tool scheduling, executes log query, index analysis and the like according to the diagnosis scheme (that is, the tool subset and the second target diagnosis process recommended by the application Pod restart event) given by the target diagnosis model, and outputs a root cause analysis report. The client client is used for accessing the data source. Various types of target clients are used for accessing various types of data sources, such as accessing CPU / memory index, container error log, and the like, so as to solve the data island problem caused by the dispersion of logs, monitoring, links and the like in different systems.

[0051] According to the cluster to which the application pod belongs, various types of target clients required for initializing the exception analysis agent are initialized, so that the exception analysis agent can access various types of data sources to perform diagnosis according to the diagnosis scheme given by the target diagnosis model.

[0052] In the step S102, based on the category and diagnosis information of the application Pod restart event, the first target diagnosis process matching the application Pod restart event is obtained from the pre-configured target knowledge base through the RAG technology.

[0053] When the Kubernetes Pod abnormally restarts, the knowledge management component of the system needs to retrieve the matching first target diagnosis process from the target knowledge base according to the event category (such as CrashLoopBackOff, OOMKilled) and diagnosis information (such as log fragments, event records).

[0054] The target knowledge base includes a local knowledge base, a knowledge retrieval engine, and a knowledge updating mechanism; the local knowledge base stores pre-defined diagnosis processes, exception categories, tool chain mappings, and other structured data; the knowledge retrieval engine quickly finds the most relevant diagnosis process based on vector similarity or rule matching; the knowledge updating mechanism supports dynamically adding new exception patterns or optimizing existing processes (such as manual annotation by operation and maintenance experts or AI automatic sedimentation).

[0055] Specifically, please refer to step 6 in Figure 3 Determine the first target diagnosis process based on knowledge management. Specifically, use the classification and information obtained by the above-mentioned exception monitoring component, and at the same time, based on the RAG technology, the large model can quickly match the relevant diagnosis process of the Pod abnormal restart. Further, according to the RAG retrieval result, automatically arrange and call the troubleshooting tool.

[0056] In the step S103, based on the target template matching the category of the application Pod restart event, the target prompt word matching the target diagnosis model of the application Pod restart event is generated.

[0057] The target diagnosis model is a local large model or a commercial large model of the model management module; please refer to step 4 in Figure 3 When the Kubernetes Pod abnormally restarts, the system needs to dynamically generate a target prompt word according to the event category to guide the diagnosis model (large model) to perform accurate analysis.

[0058] For example, assuming the application Pod is A and the restart category is B, the generated target prompt is: As a Kubernetes diagnosis expert, please analyze the "B" exception of Pod "A", locate the root cause of the database connection problem, and provide an executable repair solution.

[0059] In the step S104, the target prompt of the application Pod restart event, the first target diagnosis process and diagnosis information are sent to a target diagnosis model, the target prompt, the first target diagnosis process and diagnosis information are processed by the target diagnosis model, and a tool subset and a second target diagnosis process recommended for the application Pod restart event are determined; the tool subset includes multiple analysis tools in the tool set.

[0060] The first target diagnosis process includes the operation and maintenance means retrieved by RAG, and the operation and maintenance means retrieved by RAG are added to the prompt of the large model call to call the large model for diagnosis of the Pod abnormal restart event, which plays a role in guiding the analysis of the large model and prevents the "hallucination" problem of the large model.

[0061] The target diagnosis model processes the target prompt, the first target diagnosis process and diagnosis information, and determines the tool subset and the second target diagnosis process recommended for the application Pod restart event, including the following steps: The target diagnosis model processes the target prompt, the first target diagnosis process and diagnosis information, and determines the tool subset and the second target diagnosis process recommended for the application Pod restart event by reasoning to optimize the first target diagnosis process; the target diagnosis model is pre-trained; The process optimization includes tool screening, diagnosis step screening, and sorting of tools and diagnosis steps.

[0062] The target diagnosis model processes the target prompt, the first target diagnosis process and diagnosis information, extracts features, processes them into feature vectors, and then performs tool screening, diagnosis step screening, tool and diagnosis step sorting, etc. based on the knowledge and constraint rules in the large model, verifies the reasoning result, and finally outputs the tool set and the second target diagnosis process recommended for the application Pod restart event.

[0063] The first target diagnosis process is a standardized process based on historical experience, covering more comprehensive scenarios and using more comprehensive analysis tools.

[0064] The second target diagnosis process is a customized path dynamically generated by the large model for the application Pod restart event, and the specific problem of the application Pod restart event.

[0065] Please refer to step 6 in Figure 3 According to the classification of Pod abnormal restart, use the prepared Prompt template and complete prompt, and combine the diagnosis process obtained from the local knowledge base to send to the local large model or commercial large model to obtain the recommended tool set and diagnosis process returned by the large model; that is, the target diagnosis model infers the recommended tool set and the second target diagnosis process suitable for the application Pod restart event based on the target prompt, the first target diagnosis process and diagnosis information; wherein, tool screening, diagnosis step screening, tool and diagnosis step sorting.

[0066] That is, the target diagnosis model can find the most relevant tool for the current abnormal restart, avoid invalid detection, delete redundant steps, focus on key diagnosis paths, and achieve optimal execution through tool and step sorting.

[0067] In the step S105, according to the recommended tool set and the second target diagnosis process, the arrangement calling of multiple analysis tools is performed to determine the diagnosis result of the application Pod restart event.

[0068] Please refer to steps 7 and 8 in Figure 3 According to the recommended tool set and the diagnosis process, the arrangement calling of various tools is performed.

[0069] Please refer to steps 9 and 10 in Figure 4 Step 9, send the return results of various tools to the local large model or commercial large model for analysis and summary; step 10: output and save the analysis results of Pod abnormal restart returned by the large model.

[0070] In some embodiments, please refer to Figure 5 According to the recommended tool subset and the second target diagnosis process, the arrangement calling of multiple analysis tools is performed to determine the diagnosis result of the application Pod restart event, including: S401, according to the recommended tool subset and the second target diagnosis process, the arrangement calling of multiple analysis tools is performed to obtain the return results of multiple analysis tools; S402, send the return results of the multiple analysis tools to the target diagnosis model, and analyze and summarize the return results of the multiple analysis tools through the target diagnosis model to determine the diagnosis result of the application Pod restart event.

[0071] Based on the recommended tool subset and the second target diagnostic process, the need for manual intervention and some redundant detection has been avoided, improving diagnostic efficiency; the model analyzes and summarizes the tool return results (such as database connection timeout + network policy block), further reducing the need for manual intervention and improving diagnostic efficiency.

[0072] Please refer to Figure 5 , Figure 5 The optimization steps of the method for diagnosing application abnormal restart according to the embodiments of the application are shown in the schematic diagram.

[0073] In some embodiments, after determining the diagnostic result of the application Pod restart event, the method further comprises: Receiving a score value and / or evaluation text for the diagnostic result of the application Pod restart event.

[0074] Please refer to Figure 5 Step 1, the operation and maintenance personnel can score the result of each intelligent analysis, or give suggestions.

[0075] At the same time, the diagnostic process can be modified and saved according to the score and the suggestion.

[0076] In some embodiments, the method further comprises: Based on the score value and / or evaluation text for the diagnostic result of the application Pod restart event, adjusting the existing diagnostic process and / or adding a new diagnostic process to obtain an updated diagnostic process; The knowledge base vectorizes the updated diagnostic process and stores the vectorized diagnostic process.

[0077] That is, the operation and maintenance personnel can adjust the existing analysis process of Pod abnormal restart according to the score and the evaluation text. The operation and maintenance personnel can also modify and add the analysis process of Pod abnormal restart according to the operation and maintenance experience. The operation and maintenance knowledge base will analyze, fragment, and call the Embedding model for vectorization, and finally store it in the vector database.

[0078] At the same time, based on the RAG technology, the large model can quickly match the related diagnostic process of Pod abnormal restart. Then, the large model automatically arranges and calls the troubleshooting tool according to the RAG retrieval result. Finally, the large model analyzes and summarizes the return result of the troubleshooting tool. Thus, the analysis and diagnosis of application Pod abnormal restart are completed intelligently and automatically. This method can greatly reduce the "hallucination" of the large model and improve the accuracy of the analysis of the large model.

[0079] In some embodiments, the method further comprises: In response to receiving the adjustment operation for the analysis tool, generate an adjustment instruction; the adjustment operation includes: adding a tool, deleting a tool, modifying a tool; Generate a pre-validation result of the adjustment instruction by processing the previously generated multiple tool subsets and the adjustment instruction through the target diagnosis model; the pre-validation result represents the influence of the adjustment instruction on the diagnosis process; Based on the pre-validation result, secondly confirm the adjustment operation, and adjust the analysis tools in the tool set based on the second confirmation result.

[0080] Please refer to step 3 in Figure 5 , the operation and maintenance personnel can modify or add the analysis tool of the pod abnormal restart.

[0081] Please refer to steps 4 and 5 in Figure 6 : In the subsequent analysis process of the pod abnormal restart, the large model will call the new analysis tool according to the latest analysis process, arrange according to the optimized process, and summarize the analysis result, so as to optimize the analysis process.

[0082] That is, the method for diagnosing application abnormal restart described in the embodiments of the application constructs a modular and evolutionary intelligent diagnosis system; through the collaborative operation of the four modules of knowledge management, analysis management, tool management and model management, the continuous optimization of the pod abnormal restart diagnosis process is realized. Specifically, the existing analysis process can be optimized through the analysis management module, the new analysis tool can be accessed through the tool management module, and the appropriate large model can be selected through the working model management module; thus, the diagnosis process is continuously optimized from multiple aspects, and the accuracy of the application pod abnormal restart diagnosis is continuously improved. This closed-loop optimization mechanism realizes the continuous transformation of operation and maintenance experience into system knowledge, enables the diagnosis system to have self-evolution ability, and significantly improves the accuracy and adaptability of the pod abnormal restart diagnosis.

[0083] Based on the same inventive concept, the embodiments of the application also provide a device for diagnosing application abnormal restart corresponding to the method for diagnosing application abnormal restart. Since the principle of solving problems in the device of the embodiments of the application is similar to the method for diagnosing application abnormal restart described above, the implementation of the device can be referred to the implementation of the method for diagnosing application abnormal restart, and the repeated parts will not be described here.

[0084] Please refer to Figure 6 , Figure 6 shows the structure schematic diagram of the device for diagnosing application abnormal restart described in the embodiments of the application, as shown in Figure 7 , the device comprises: A first determination module 601 is configured to determine the category and diagnosis information of the application pod restart event in response to the application pod restart event monitored by the abnormal monitoring component. The acquisition module 602 is configured to acquire, based on the category of the application Pod restart event and the diagnosis information, a first target diagnosis process matching the application Pod restart event from a pre-configured target knowledge base through an RAG technology. The generation module 603 is configured to generate a target prompt word of the application Pod restart event matching a target diagnosis model based on a target template matched with the category of the application Pod restart event. The processing module 604 is configured to send the target prompt word of the application Pod restart event, the first target diagnosis process, and the diagnosis information to the target diagnosis model, process the target prompt word, the first target diagnosis process, and the diagnosis information through the target diagnosis model, and determine a tool subset and a second target diagnosis process recommended for the application Pod restart event; the tool subset includes multiple analysis tools in a tool set. The second determination module 605 is configured to determine a diagnosis result of the application Pod restart event by performing orchestration calling of the multiple analysis tools according to the recommended tool subset and the second target diagnosis process.

[0085] In some embodiments, the device for diagnosing application abnormal restart further includes: The initialization module is configured to initialize multiple types of target clients required by an abnormal analysis Agent according to a cluster to which the application Pod belongs after determining the category of the application Pod restart event and the diagnosis information.

[0086] In some embodiments, in the device for diagnosing application abnormal restart, when the processing module determines the tool subset and the second target diagnosis process recommended for the application Pod restart event by processing the target prompt word, the first target diagnosis process, and the diagnosis information through the target diagnosis model, the processing module is specifically configured to: The target diagnosis model processes the target prompt word, the first target diagnosis process, and the diagnosis information by reasoning to realize process optimization of the first target diagnosis process, and determines the tool set and the second target diagnosis process recommended for the application Pod restart event; the target diagnosis model is pre-trained. The process optimization includes tool screening, diagnosis step screening, and sorting of tools and diagnosis steps.

[0087] In some embodiments, the device for diagnosing application abnormal restart further includes: The receiving module is configured to receive a score value and / or evaluation text of the diagnosis result of the application Pod restart event after determining the diagnosis result of the application Pod restart event.

[0088] In some embodiments, the device for diagnosing abnormal restart of an application further comprises: a first adjustment module configured to adjust an existing diagnosis process and / or add a diagnosis process based on a score value and / or evaluation text of the diagnosis result of the application Pod restart event, to obtain an updated diagnosis process. The knowledge base performs vectorization processing on the updated diagnosis process and stores the vectorized diagnosis process.

[0089] In some embodiments, the device for diagnosing abnormal restart of an application further comprises: a second adjustment module configured to generate an adjustment instruction in response to receiving an adjustment operation on the analysis tool; the adjustment operation includes adding a tool, deleting a tool, and modifying a tool. The target diagnosis model processes the previously generated plurality of tool subsets and the adjustment instruction to generate a pre-validation result of the adjustment instruction; the pre-validation result represents the influence of the adjustment instruction on the diagnosis process. Based on the pre-validation result, the adjustment operation is confirmed again, and the analysis tool in the tool set is adjusted based on the secondary confirmation result.

[0090] When a user request to add / delete / modify a tool is received, the large model predicts the influence on the diagnosis process in combination with the tools used in the recently output diagnosis process, and displays the prediction result to the user to determine whether to adjust the tool set, preventing the user from making mistakes or causing unexpected effects.

[0091] The target diagnosis model processes the previously generated plurality of tool subsets and the adjustment instruction to generate a pre-validation result of the adjustment instruction, for example, when a thread analysis tool is deleted, it is detected whether the tool is dependent on the tool in the tool subset of the second target diagnosis process recently output; it is detected whether the newly added tool is redundant with the existing tool function, etc.

[0092] If it is detected that the tool is dependent on the tool in the tool subset of the second target diagnosis process recently output, the user is informed; if it is detected that there is no diagnosis process dependent on the tool in the tool subset of the second target diagnosis process recently output, it means that the tool has not been used for a long time, and the user is also informed; the user confirms again whether to delete the tool.

[0093] In some embodiments, the second determination module in the device for diagnosing abnormal restart of an application, when performing arrangement and calling of a plurality of analysis tools according to the recommended tool subset and the second target diagnosis process, is specifically configured to: According to the recommended tool subset and the second target diagnosis process, a plurality of analysis tools are called and arranged to obtain return results of the plurality of analysis tools; The return results of the plurality of analysis tools are sent to a target diagnosis model, and the return results of the plurality of analysis tools are analyzed and summarized by the target diagnosis model to determine a diagnosis result of the application Pod restart event.

[0094] Based on the same inventive concept, the embodiments of the present application also provide an electronic device corresponding to the method of diagnosing application abnormal restart. Since the principle of solving problems of the electronic device in the embodiments of the present application is similar to the method of diagnosing application abnormal restart, the implementation of the electronic device can be referred to the implementation of the method of diagnosing application abnormal restart, and the repeated parts will not be described here.

[0095] Please refer to Figure 7 , ​ The structure schematic diagram of the electronic device is shown; the electronic device 700 includes a processor 702, a memory 701 and a bus, the memory 701 stores machine readable instructions executable by the processor 702, when the electronic device 700 runs, the processor 702 and the memory 701 communicate through the bus, and the machine readable instructions are executed by the processor 702 to execute the steps of the method of diagnosing application abnormal restart.

[0096] Based on the same inventive concept, the embodiments of the present application also provide a computer readable storage medium corresponding to the method of diagnosing application abnormal restart. Since the principle of solving problems of the computer readable storage medium in the embodiments of the present application is similar to the method of diagnosing application abnormal restart, the implementation of the computer readable storage medium can be referred to the implementation of the method of diagnosing application abnormal restart, and the repeated parts will not be described here.

[0097] A computer readable storage medium, the computer readable storage medium stores a computer program, the computer program is run by a processor to execute the steps of the method of diagnosing application abnormal restart.

[0098] Those skilled in the art can clearly understand that, for the convenience and brevity of the description, the specific working process of the system and the device described above can refer to the corresponding process in the method embodiment, and will not be repeated in the present application. In the several embodiments provided in the present application, it should be understood that the disclosed system, device and method can be implemented by other means. The above-described device embodiments are only schematic, for example, the division of the modules is only a logical function division, and the actual implementation can have another division manner, for example, a plurality of modules or components can be combined or integrated into another system, or some features can be ignored or not executed. In addition, the coupling or direct coupling or communication connection between the shown or discussed mutual elements can be indirect coupling or communication connection through some communication interface, device or module, which can be electrical, mechanical or other forms.

[0099] The modules described as separate components can or can not be physically separated, and the components shown as modules can or can not be physical units, i.e. can be located in one place or distributed to multiple network units. Part or all of the units can be selected according to actual needs to achieve the purpose of the embodiment.

[0100] In addition, the functional units in each embodiment of the present application can be integrated in one processing unit, or each unit can be physically present separately, or two or more units can be integrated in one unit.

[0101] If the functions are realized in the form of software function units and sold or used as independent products, they can be stored in a non-volatile computer readable storage medium executable by a processor. Based on this understanding, the technical solutions of the present application essentially or the part of the prior art or the part of the technical solutions can be embodied in the form of a software product, which is stored in a storage medium and includes a plurality of instructions for causing a computer device (which can be a personal computer, a platform server, or a network device, etc.) to execute all or part of the steps of the method described in each embodiment of the present application. The foregoing storage medium includes: U disk, mobile hard disk, ROM, RAM, magnetic disk or optical disk and various program code storage media.

[0102] The above is only a specific embodiment of the present application, but the protection scope of the present application is not limited thereto, and any person skilled in the art can easily think of changes or replacements within the technical range disclosed in the present application, which should be covered within the protection scope of the present application. Therefore, the protection scope of the present application should be subject to the protection scope of the claims.

Claims

1. A method for diagnosing abnormal application restarts, characterized in that, The method includes: For application Pod restart events detected by the anomaly monitoring component, determine the category and diagnostic information of the application Pod restart event; Based on the category and diagnostic information of the application Pod restart event, the first target diagnostic process matching the application Pod restart event is obtained from a pre-configured target knowledge base using RAG technology; Based on the target template that matches the category of the application Pod restart event, generate target prompt words for the application Pod restart event matching target diagnostic model; The target prompt word for the application Pod restart event, the first target diagnostic process, and the diagnostic information are sent to the target diagnostic model. The target diagnostic model processes the target prompt word, the first target diagnostic process, and the diagnostic information to determine a subset of tools and a second target diagnostic process recommended for the application Pod restart event. The subset of tools includes various analysis tools in the toolset. By orchestrating and calling various analysis tools according to the recommended subset of tools and the second target diagnostic process, the diagnostic results of the application Pod restart event are determined.

2. The method for diagnosing abnormal application restarts according to claim 1, characterized in that, After determining the category and diagnostic information of the application Pod restart event, the method further includes: Based on the cluster to which the application pod belongs, initialize the various types of target clients required by the anomaly analysis agent.

3. The method for diagnosing abnormal application restarts according to claim 1, characterized in that, The step of processing the target prompt words, the first target diagnostic process, and diagnostic information through the target diagnostic model to determine the recommended subset of tools and the second target diagnostic process for the application Pod restart event includes: The target diagnostic model processes the target prompts, the first target diagnostic process, and the diagnostic information. The target diagnostic model optimizes the first target diagnostic process through reasoning, and determines the recommended toolset and the second target diagnostic process for the application Pod restart event. The target diagnostic model is pre-trained. The process optimization includes: tool selection, diagnostic step selection, and sorting of tools and diagnostic steps.

4. The method for diagnosing abnormal application restarts according to claim 1 or 3, characterized in that, After determining the diagnostic result of the application Pod restart event, the method further includes: Receive the diagnostic results of the application Pod restart event, including a score and / or evaluation text.

5. The method for diagnosing abnormal application restarts according to claim 1, characterized in that, The method further includes: Based on the score and / or evaluation text of the diagnostic results for the application Pod restart event, the existing diagnostic process and / or new diagnostic process are adjusted to obtain the updated diagnostic process. The knowledge base vectorizes the updated diagnostic process and stores the vectorized diagnostic process.

6. The method for diagnosing abnormal application restarts according to claim 1, characterized in that, The method further includes: In response to receiving an adjustment operation for the analysis tool, an adjustment instruction is generated; the adjustment operation includes: adding a tool, deleting a tool, and modifying a tool; multiple previously generated tool subsets and the adjustment instruction are processed by the target diagnostic model to generate a pre-validation result of the adjustment instruction; the pre-validation result characterizes the impact of the adjustment instruction on the diagnostic process; Based on the pre-verification results, the adjustment operation is confirmed a second time, and the analysis tools in the toolset are adjusted based on the second confirmation results.

7. The method for diagnosing abnormal application restarts according to claim 1, characterized in that, Following the recommended subset of tools and the second target diagnostic process, various analysis tools are orchestrated and invoked to determine the diagnostic results of the application Pod restart event, including: According to the recommended subset of tools and the second target diagnostic process, various analysis tools are orchestrated and invoked to obtain the return results of various analysis tools; The results returned by the various analysis tools are sent to the target diagnostic model, which analyzes and summarizes the results to determine the diagnostic result of the application Pod restart event.

8. A diagnostic application restart device, characterized in that, The device includes: The first determination module is used to determine the category and diagnostic information of the application Pod restart event detected by the anomaly monitoring component. The acquisition module is used to acquire the first target diagnostic process matching the application Pod restart event from a pre-configured target knowledge base based on the category and diagnostic information of the application Pod restart event using RAG technology; The generation module is used to generate target prompt words for the application Pod restart event matching target diagnostic model based on the target template that matches the category of the application Pod restart event; The processing module is used to send the target prompt word, the first target diagnostic process, and diagnostic information of the application Pod restart event to the target diagnostic model, and process the target prompt word, the first target diagnostic process, and diagnostic information through the target diagnostic model to determine the recommended tool subset and the second target diagnostic process for the application Pod restart event; the tool subset includes a variety of analysis tools in the toolset; The second determining module is used to orchestrate and invoke various analysis tools according to the recommended subset of tools and the second target diagnostic process to determine the diagnostic result of the application Pod restart event.

9. An electronic device, characterized in that, include: The device includes a processor, a memory, and a bus. The memory stores machine-readable instructions executable by the processor. When the electronic device is running, the processor communicates with the memory via the bus. When the machine-readable instructions are executed by the processor, the steps of the method for diagnosing application abnormal restart as described in any one of claims 1 to 7 are performed.

10. A computer-readable storage medium, characterized in that, The computer-readable storage medium stores a computer program that, when executed by a processor, performs the steps of the method for diagnosing abnormal application restarts as described in any one of claims 1 to 7.

Images