Exception handling method and device, equipment, storage medium and program product

Abstract

The invention provides an exception handling method and device, equipment, a storage medium and a program product, and relates to the technical field of computers. The method comprises the steps of executing an assembly line task, and obtaining an execution result of the assembly line task; if the sub-execution result of any sub-task indicates that the sub-task is executed abnormally, a log of the sub-task is obtained, and whether a target log field matched with a first log field of the log exists in a knowledge base corresponding to the sub-task or not is determined; if the target log field exists, determining a first exception handling strategy corresponding to the target log field in the knowledge base; and executing the first exception handling strategy. According to the method, the exception handling efficiency is effectively improved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to an exception handling method, device, equipment, storage medium and program product. Background Art

[0002] With the development of software development technology, the functional types of application software have increased, and the speed of application version iteration and update has continued to increase. The workload of application development and deployment for new functions or new versions has also continued to increase. In order to simplify the application development and deployment process in the existing technology and improve the application deployment and development efficiency, the existing technology uses a variety of continuous integration and continuous delivery platforms to achieve automated application construction and deployment.

[0003] In the prior art, when a continuous integration or continuous delivery platform executes an application deployment task or a build task, a large amount of log data is generated; these log data can be used to analyze the anomalies that exist during the task execution process, and output corresponding solutions for these anomalies, thereby continuously optimizing the task execution process.

[0004] However, when the existing technology performs exception handling through log data, the location of the exception cannot be accurately located to the specific task execution node, and detailed exception analysis and exception handling are still required manually, resulting in low exception handling efficiency. Summary of the invention

[0005] The present application provides an exception handling method, apparatus, device, storage medium and program product to solve the technical problem of low exception handling efficiency in the prior art.

[0006] In a first aspect, the present application provides an exception handling method, comprising:

[0007] Execute the pipeline task and obtain the execution result of the pipeline task; wherein the pipeline task includes multiple subtasks, the pipeline task is pre-configured to monitor each subtask separately to obtain processing data of each subtask, and the execution result of the pipeline task includes the sub-execution result of each subtask;

[0008] If the sub-execution result of any sub-task indicates that the sub-task execution is abnormal, obtain the log of the sub-task;

[0009] Determine whether there is a target log field that matches the first log field of the log in the knowledge base corresponding to the subtask, and the knowledge base stores exception handling strategies corresponding to different exceptions;

[0010] If the target log field exists, determining a first exception handling strategy corresponding to the target log field in the knowledge base;

[0011] The first exception handling strategy is executed.

[0012] In a possible design, determining whether there is a target log field matching the first log field of the log in the knowledge base corresponding to the subtask includes:

[0013] Determine a log field of a preset type in the log as a first log field;

[0014] The first log field is matched with the second log field included in the knowledge base to determine whether the target log field exists in the knowledge base.

[0015] In a possible design, determining whether there is a target log field matching the first log field of the log in the knowledge base corresponding to the subtask includes:

[0016] It is determined whether there is a target log field identical to the first log field in the knowledge base.

[0017] In one possible design, the method further includes:

[0018] If there is no target log field identical to the first log field in the knowledge base, determining a similar log field corresponding to each second log field contained in the knowledge base;

[0019] If there is a target similar log field identical to the first log field among the multiple similar log fields, the second log field corresponding to the target similar log field is determined as the target log field.

[0020] In a possible design, before executing a pipeline task and obtaining an execution result of the pipeline task, the method includes:

[0021] According to the task functions, the subtasks contained in the pipeline task are classified to obtain multiple types of subtasks;

[0022] Create a corresponding knowledge base based on each type of subtask;

[0023] Each subtask is configured to monitor the sub-execution results of each subtask.

[0024] In a possible design, if there is no target log field matching the first log field of the log in the knowledge base corresponding to the subtask, a prompt word is generated according to the subtask and the log;

[0025] Input the prompt word into the large model to obtain the second exception handling strategy output by the large model;

[0026] The second exception handling strategy is executed.

[0027] In a second aspect, the present application provides an exception handling device, comprising:

[0028] A first acquisition module, used to execute a pipeline task and acquire an execution result of the pipeline task; wherein the pipeline task includes a plurality of subtasks, the pipeline task is pre-configured to monitor each subtask separately to acquire processing data of each subtask, and the execution result of the pipeline task includes a sub-execution result of each subtask;

[0029] A second acquisition module is used to acquire the log of a subtask when the sub-execution result of any subtask indicates that the task execution is abnormal;

[0030] A first processing module is used to determine whether there is a target log field matching the first log field of the log in the knowledge base corresponding to the subtask;

[0031] A second processing module is used to determine a first exception handling strategy corresponding to the target log field in a knowledge base when the target log field exists, and the knowledge base stores exception handling strategies corresponding to different exceptions;

[0032] The third processing module is used to execute the first exception handling strategy.

[0033] In a possible design, the first processing module is further used for:

[0034] Determine a log field of a preset type in the log as a first log field;

[0035] The first log field is matched with the second log field included in the knowledge base to determine whether the target log field exists in the knowledge base.

[0036] In a possible design, the first processing module is further used for:

[0037] It is determined whether there is a target log field identical to the first log field in the knowledge base.

[0038] In a possible design, the first processing module is further used for:

[0039] If there is no target log field identical to the first log field in the knowledge base, determining a similar log field corresponding to each second log field contained in the knowledge base;

[0040] If there is a target similar log field identical to the first log field among the multiple similar log fields, the second log field corresponding to the target similar log field is determined as the target log field.

[0041] In a possible design, the first acquisition module is further used for:

[0042] According to the task functions, the subtasks contained in the pipeline task are classified to obtain multiple types of subtasks;

[0043] Create a corresponding knowledge base based on each type of subtask;

[0044] Each subtask is configured to monitor the sub-execution results of each subtask.

[0045] In a possible design, the second processing module is further used for:

[0046] When there is no target log field matching the first log field of the log in the knowledge base corresponding to the subtask, generating a prompt word according to the subtask and the log;

[0047] Input the prompt word into the large model to obtain the second exception handling strategy output by the large model;

[0048] The third processing module is also used to: execute the second exception handling strategy.

[0049] In a third aspect, an embodiment of the present application provides an exception handling device, comprising: at least one processor and a memory; the memory stores computer execution instructions; at least one processor executes the computer execution instructions stored in the memory, so that at least one processor executes the exception handling method as described in the first aspect above and various possible designs of the first aspect.

[0050] In a fourth aspect, an embodiment of the present application provides a computer-readable storage medium, in which computer execution instructions are stored. When a processor executes the computer execution instructions, the exception handling method as described in the first aspect and various possible designs of the first aspect are implemented.

[0051] In a fifth aspect, an embodiment of the present application provides a computer program product, including a computer program. When the computer program is executed by a processor, it implements the exception handling method as described in the first aspect and various possible designs of the first aspect.

[0052] The exception handling method, device, equipment, storage medium and program product provided by the present application, by executing the pipeline task and obtaining the execution result of the pipeline task, when the sub-execution result of any subtask indicates that the subtask has an exception, obtain the log of the subtask corresponding to the exception; based on the log and the knowledge base corresponding to the subtask, match the first day value field in the log, determine whether there is a matching target log field in the knowledge base, and determine the first exception handling strategy for solving the subtask exception based on the knowledge base when the target log field exists. Determine the subtask that specifically corresponds to the exception by dividing the subtask, and use the log of the subtask to match the corresponding knowledge base, and achieve matching and processing of the exception when only the log of the subtask needs to be analyzed. Compared with the method of analyzing the full log in the prior art, the log data that needs to be analyzed is reduced, and the corresponding exception handling strategy is efficiently obtained based on the knowledge base matching method, thereby improving the efficiency of exception handling. BRIEF DESCRIPTION OF THE DRAWINGS

[0053] The accompanying drawings, which are incorporated in and constitute a part of this specification, illustrate embodiments consistent with the present application and, together with the description, serve to explain the principles of the present application.

[0054] Figure 1 The process of the exception handling method provided in the embodiment of the present application Figure 1 ;

[0055] Figure 2 The process of the exception handling method provided in the embodiment of the present application Figure 2 ;

[0056] Figure 3 A schematic diagram of the structure of an exception handling device provided in an embodiment of the present application;

[0057] Figure 4 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application.

[0058] The above drawings have shown clear embodiments of the present application, which will be described in more detail later. These drawings and text descriptions are not intended to limit the scope of the present application in any way, but to illustrate the concept of the present application to those skilled in the art by referring to specific embodiments. DETAILED DESCRIPTION

[0059] Exemplary embodiments will be described in detail herein, examples of which are shown in the accompanying drawings. When the following description refers to the drawings, the same numbers in different drawings represent the same or similar elements unless otherwise indicated. The implementations described in the following exemplary embodiments do not represent all implementations consistent with the present application. Instead, they are merely examples of devices and methods consistent with some aspects of the present application as detailed in the appended claims.

[0060] In the technical solution of this application, the collection, storage, use, processing, transmission, provision and disclosure of information such as financial data or user data involved shall comply with the provisions of relevant laws and regulations and shall not violate public order and good morals.

[0061] It should be noted that in the embodiments of the present application, certain software, components, models and other existing solutions in the industry may be mentioned, and they should be regarded as exemplary. Their purpose is only to illustrate the feasibility of implementing the technical solution of the present application, but it does not mean that the applicant has or will necessarily use the solution.

[0062] In the prior art, when users use continuous integration tools or continuous delivery tools, the tasks they perform are called pipeline tasks. Continuous integration tools and continuous delivery tools can be called pipeline tools, which will generate a large amount of log data according to the specific tasks performed. The log data records the specific execution steps or execution status in each execution stage. By performing a detailed analysis of the log data, when there are abnormalities in the execution of the pipeline task, the specific abnormal type or the log data corresponding to the abnormality can be determined. Based on the log data with abnormalities, the abnormality solution can be determined through abnormal data analysis, thereby optimizing the task execution process.

[0063] However, in actual log data anomaly analysis, the analysis of abnormal data cannot efficiently perform anomaly analysis and determine corresponding solutions. For example, a user uses pipeline tool A to implement the construction of pipeline task B. When there is an exception in the execution process, it is necessary to collect all log data in the execution process, and determine the anomaly and the corresponding solution by matching the log data and the exception library. If the corresponding anomaly cannot be found, it is necessary to determine which execution stages have anomalies through task search and matching, and determine the corresponding anomaly type or anomaly data, conduct further anomaly analysis, and provide corresponding anomaly solutions. Due to the huge amount of log data in the prior art, a lot of time cost is consumed when performing log data analysis, and when the anomaly search is inaccurate, manual intervention is still required for anomaly analysis, which leads to the technical problem of low efficiency of exception handling in the prior art.

[0064] In response to the above technical problems, the present application proposes the following technical concept: the analysis of log data in the prior art is used to realize the location of exceptions and the determination of exception solutions. In actual applications, the log data contains log data of multiple execution stages, and the overall abnormal data analysis cannot achieve accurate positioning, and the analysis of a large amount of data will lead to low efficiency in the analysis of exceptions. Therefore, it is possible to perform exception analysis on the exceptions corresponding to each execution stage, locate the exception handling in the subtasks of the pipeline task, and classify the subtasks to create an exception matching knowledge base corresponding to each classification, thereby avoiding the situation of matching a large amount of data and achieving rapid exception matching and positioning. Based on the exception matching, the corresponding solution strategy is determined, and the exceptions existing in the execution of the pipeline task are quickly handled by executing the exception solution strategy, thereby improving the efficiency of exception handling.

[0065] The technical solution of the present application and how the technical solution of the present application solves the above-mentioned technical problems are described in detail below with specific embodiments. The following specific embodiments can be combined with each other, and the same or similar concepts or processes may not be repeated in some embodiments. The embodiments of the present application will be described below in conjunction with the accompanying drawings.

[0066] Figure 1 The process of the exception handling method provided in the embodiment of the present application Figure 1 .like Figure 1 As shown, the exception handling method includes:

[0067] S101, execute the pipeline task and obtain the execution result of the pipeline task.

[0068] In this step, the pipeline task is executed by accepting the pipeline task based on the pipeline server or pipeline processing platform, and executing the pipeline task based on the pipeline tool.

[0069] Among them, pipeline tasks refer to the work tasks performed by using pipeline tools to optimize the working method during the software development process.

[0070] In this step, the pipeline task includes multiple subtasks, and the pipeline task is pre-configured to monitor each subtask separately to obtain processing data of each subtask. The execution result of the pipeline task includes the sub-execution result of each subtask.

[0071] Pipeline tools refer to tools used to automate, manage, and optimize various stages of the software development process. They mainly include continuous integration tools and continuous delivery tools. Pipeline tools can help users automatically build, test, and deploy applications after code submission, thereby improving development efficiency and quality. This application does not limit pipeline tools. In specific applications, pipeline tools can be either existing in the prior art or undisclosed tools developed and designed by users themselves.

[0072] The execution result of a pipeline task refers to the specific output and status generated after each step is completed when the pipeline task is executed. For example, these results may include: build success and failure information, test reports, deployment status, and code quality analysis reports. Optionally, before executing the pipeline task, the subtasks need to be classified, specifically:

[0073] A1. According to the task functions, the subtasks contained in the pipeline task are classified to obtain multiple types of subtasks.

[0074] In this step, the pipeline subtasks can include the following categories: code building, unit testing, integration testing, code static analysis, security scanning, automatic deployment, and monitoring and feedback. Among them, code building refers to automatically compiling source code and generating executable files or deployment packages; unit testing refers to automatically running unit tests to verify the functional correctness of the code; integration testing refers to integration testing between multiple components or modules to ensure that they can work together; code static analysis refers to statically checking the code to find potential errors and non-compliance with coding standards; security scanning refers to scanning dependencies and codes for security vulnerabilities; automatic deployment refers to automatically deploying tested code to production environments or other environments; monitoring and feedback refers to monitoring application performance and collecting user feedback for subsequent improvements. The subtasks of the pipeline are not limited in this application. In actual applications, the subtasks in each pipeline task can be personalized and orchestrated in a customized way.

[0075] For example, if the pipeline tool used is the open source tool Jenkins, then the tool used to plan the pipeline is Jenkinsfile. The subtasks can be classified according to the task function. The security scan classification includes multiple subtasks, which can be: scanning tasks for checking code quality and security, scanning tasks for dynamic security testing, open source vulnerability scanning tasks for scanning known vulnerabilities of open source components, and garbage scanning tasks for garbage collection.

[0076] A2. Create a corresponding knowledge base based on each type of subtask.

[0077] In this step, the knowledge base corresponding to the subtask refers to the knowledge base that stores the possible exceptions that may exist in the subtasks of this category and the corresponding processing strategies for the exceptions.

[0078] Among them, a possible implementation method of creating a knowledge base is:

[0079] a1. Collect historical exception information corresponding to the subtask.

[0080] In this step, the method for collecting historical abnormal information may be: using an automated collection tool to extract the abnormal information corresponding to the subtask from the execution platform or execution software of the pipeline subtask.

[0081] a2. Classify and archive the data, classify the collected abnormal information according to the category of subtask, and grade the abnormal information according to the degree of its impact on the execution results of the subtask.

[0082] a3. Conduct in-depth analysis of the collected abnormal information and calculate the frequency of occurrence of various types of abnormalities.

[0083] a4. Enter the corresponding exception handling strategy according to different exception information.

[0084] The exception handling strategy can be obtained by: inputting the exception handling strategy manually; performing exception analysis through a large model and generating a corresponding exception handling strategy.

[0085] a5. Create different categories of knowledge bases based on exception information and exception handling strategies.

[0086] A3. Configure each subtask to monitor the sub-execution results of each subtask.

[0087] In this step, configuring each subtask refers to configuring the sub-execution result monitoring strategy of the subtask in the pipeline configuration file, so that the sub-execution result of the subtask will be output in the background or stored in the execution result file after the task execution is completed.

[0088] S102: If the sub-execution result of any sub-task indicates that the sub-task execution is abnormal, obtain the log of the sub-task.

[0089] In this step, a possible implementation method for obtaining the log of the subtask with execution exception is:

[0090] b1. Before the pipeline task is executed, the logic of sub-task execution result monitoring and sub-task execution log generation is configured into the specific pipeline tool or platform through the pipeline file configuration method.

[0091] b2. Collect the sub-execution results of each subtask based on the pipeline tool, and check the execution results through the built-in steps in the pipeline tool or the user-defined step model.

[0092] b3. When an exception is detected in the execution of a subtask, the log corresponding to the subtask is obtained by accessing a specific file path, or the log of the corresponding subtask is directly obtained based on the pipeline tool.

[0093] b4. Print the log information to the console, or save it in a program used to implement exception analysis, log viewing and exception handling.

[0094] Among them, the log of the subtask contains at least one of the following data: the timestamp corresponding to the time of event occurrence, the level of the event in the log, the event source of the event, the message content corresponding to the event, additional data related to the event, the error information corresponding to the abnormal event, the network address where the log was generated, the platform information corresponding to the log generation, and the software information.

[0095] S103: Determine whether there is a target log field matching the first log field of the log in the knowledge base corresponding to the subtask.

[0096] In this step, the knowledge base stores exception handling strategies corresponding to different exceptions.

[0097] Optionally, a possible implementation method of determining whether a target log field exists is:

[0098] B1. determining a log field of a preset type in the log as a first log field;

[0099] In this step, the log field of the preset type is a log field for recording exception information. Exemplarily, the log field of the preset type can be divided into two types: one is a field for indicating the log level, including: DEBUG, INFO, WARN, ERROR, FATAL and CRITICAL; the other is a field for indicating the exception type, including: NullPointerException for indicating a null object exception and SQLException for indicating a database exception.

[0100] Among them, the DEBUG field is used to output detailed debugging information, which is generally related to the abnormal information of task execution; the INFO field is used to record informational messages and indicates the normal running status of the program. It can also be used to identify the occurrence of important events and has a certain correlation with the abnormal information; the WARN field indicates potential problems or unusual situations; the ERROR field indicates that an error has occurred in the program, causing a certain function to fail to run normally; the FATAL field is used to record fatal errors; and the CRITICAL field is used to record important issues that require immediate attention.

[0101] It should be noted that the field used to indicate the exception type is related to the code architecture and operating environment corresponding to the execution tool of the pipeline task. For example, if the original coding language used is Java, the exception type can be: NullPointerException, ArrayIndexOutOfBoundsException, ClassCastException, IllegalArgumentException, SQLException, IOException, FileNotFoundException, and NumberFormatException.

[0102] B2. Match the first log field with the second log field included in the knowledge base to determine whether the target log field exists in the knowledge base.

[0103] In this step, the first log field and the second log field can be matched in a manner based on keyword query or regular expression matching. Among them, the keyword query-based method is to match the second log field and the first log field in the knowledge base one by one in a polling manner until a second log field that matches each other is found, and the second log field is determined as the target log field. The regular expression-based matching method is to generate a regular expression corresponding to the first log field based on the first log field and the regular expression generation rules, and use the regular expression to filter the second log field in the knowledge base to obtain a matching target log field.

[0104] It should be noted that the regular expression generation rule can be an exact match rule or a fuzzy match rule. For example, when the generation rule is an exact match, if the first log field is string one, the regular expression determined based on the generation rule can be \string one\b, so that the second log field that is completely consistent with string one can be intelligently matched.

[0105] Optionally, another possible implementation manner of determining whether a target log field exists is:

[0106] C1. Determine whether there is a target log field identical to the first log field in the knowledge base.

[0107] In this step, determining whether there is a target log field in the knowledge base that is the same as the first log field refers to whether there is a field in the knowledge base that has the same field value as the first log field. The field value represents the numerical value of each character in the field in the computer language, and it is necessary to ensure that the lengths of the two fields and the characters in each corresponding position are the same to determine that the two fields are the same.

[0108] It should be noted that in order to avoid errors in field consistency determination caused by character case, it is necessary to synchronize the character case formats of the two fields before comparing the first log field with the field in the knowledge base.

[0109] C2. If there is no target log field identical to the first log field in the knowledge base, determine a similar log field corresponding to each second log field contained in the knowledge base.

[0110] In this step, similar log fields may be determined by:

[0111] The determination of similar log fields is realized by using a regular expression based on the fuzzy matching principle, specifically: the first log field is segmented, and a continuous string in the field is extracted as the key field; a corresponding regular expression is generated based on the key field, and a wildcard is used in the regular expression to remove the key field; when matching based on the regular expression, as long as there is a continuous string of the same length as the key field in a certain field in the knowledge base, the field can be determined as a similar log field.

[0112] Alternatively, based on a similarity calculation algorithm, the similarity between each second log field and the first log field in the knowledge base is calculated respectively, and the second log field whose similarity is greater than a preset similarity threshold is determined as a similar log field. Exemplarily, the vector values ​​of the second log field and the first log field are calculated respectively using a one-hot encoding method; the similarity between the two vector values ​​is calculated based on a cosine similarity algorithm; when the similarity exceeds a preset similarity threshold, the corresponding second log field is determined as a similar log field.

[0113] C3. If there is a target similar log field identical to the first log field among the multiple similar log fields, the second log field corresponding to the target similar log field is determined as the target log field.

[0114] In this step, the target similar log field that is the same as the first log field refers to a field with the same semantics but different expressions. The method for determining the same semantics can be: obtaining the word vector of the first log field and the word vector of the second log field based on the word vector method; then judging whether the semantics expressed by the two fields are the same based on the word vector. Or, based on a specific vocabulary, a list of semantically identical words corresponding to the vocabulary is created, and other words with the same semantics as the first log field are determined by searching the list, and then the other words are matched with the second log field respectively, so as to judge whether the second log field is semantically consistent with the first log field.

[0115] For example, if the first log field is "ERR", its semantic meaning is ERROR. By judging whether the semantics are the same, the first log field can be matched with the second log field "ERROR", thereby obtaining a target similar log field and obtaining the target log field.

[0116] S104: If the target log field exists, determine a first exception handling strategy corresponding to the target log field in the knowledge base.

[0117] In this step, the information stored in the knowledge base includes the second log field corresponding to the exception information and the exception handling strategy. Exemplarily, the data storage structure in the knowledge base can be a dictionary structure, with the second log field as the keyword of the dictionary and the corresponding exception handling strategy as the value of the keyword. After determining the target log field, the corresponding exception handling strategy can be quickly obtained based on the form of a key-value pair.

[0118] S105: Execute a first exception handling strategy.

[0119] In this step, the first exception handling strategy is used to resolve the exceptions existing in the subtask, and the first exception handling strategy is related to the type of exception generated and the subtask where the exception is generated. The log corresponding to the subtask records the exception generation event, the external conditions when the exception occurs, and the frequency of the exception. For different types of exceptions, corresponding processing strategies need to be specified. The types of exception handling strategies mainly include: retry mechanism, fallback strategy, notification mechanism, and downgrade processing. Among them, the retry mechanism is mainly used for temporary network-related exceptions; the fallback strategy is mainly used in the business logic field, and the exception can be resolved by returning to the default value or prompting the user; the notification mechanism is mainly used for key exceptions that affect the core business, and it is necessary to notify the operation and maintenance team to update and maintain the corresponding functions; downgrade processing is mainly used for partial functional exceptions. When the function cannot be used normally, the corresponding backup solution of the function is adopted for replacement.

[0120] The exception handling method provided in the embodiment of the present application executes the pipeline task and obtains the sub-execution result of each sub-task in the pipeline task. When the sub-execution result indicates that there is a sub-task exception, the log of the sub-task corresponding to the exception is obtained; based on the log and the knowledge base corresponding to the sub-task, the first day value field in the log is matched to determine whether there is a matching target log field in the knowledge base, and when the target log field exists, the first exception handling strategy for solving the sub-task exception is determined based on the knowledge base. The sub-task that specifically corresponds to the exception is determined by the division method in the sub-task, and the corresponding knowledge base is matched using the log of the sub-task. When only the log of the sub-task needs to be analyzed, the matching and processing of the exception is achieved. Compared with the method of analyzing the entire log in the prior art, the log data that needs to be analyzed is reduced, and the corresponding exception handling strategy is efficiently obtained based on the knowledge base matching method, thereby improving the efficiency of exception handling.

[0121] Figure 2 The process of the exception handling method provided in the embodiment of the present application Figure 2 .exist Figure 1 Based on the embodiment shown, further explanation is given on how to implement exception handling, such as Figure 2 As shown, the method comprises the following steps:

[0122] S201: If there is no target log field matching the first log field of the log in the knowledge base corresponding to the subtask, a prompt word is generated according to the subtask and the log.

[0123] In this step, if there is no matching target log field, it means that the exception in the subtask is not included in the corresponding knowledge base.

[0124] A specific implementation method of generating prompt words may be:

[0125] D1. Log information processing: Standardize the logs corresponding to the subtasks, convert them into easy-to-read data structures, and determine them as standard log data.

[0126] D2. Extract key information from standard log data, including timestamp, exception type, user input, and system status, which are related to exceptions.

[0127] D3. Classify and mark the extracted key information, define the keywords and keyword extraction rules.

[0128] D4. Generate corresponding prompt words according to the extracted classified information and the category to which the log belongs. The prompt words have a guiding role and can be used to guide users or language models to provide reasonable feedback.

[0129] S202: Input the prompt word into the large model to obtain the second exception handling strategy output by the large model.

[0130] The large model used in this step needs to be adjusted or trained accordingly based on the specific field of application of this application before use. Exemplarily, the large model used in this step is a language large model. In order to ensure that the output result of the language large model meets the exception handling standards in this field, it is necessary to perform model tuning or model training based on the existing exception handling data. Among them, one possible implementation method of model tuning is to create a prompt project for the language large model based on historically collected exception handling data, and to achieve rapid model tuning based on the prompt project. In this step, the second exception handling strategy generated based on the large model includes the type of the first exception handling strategy in the above-mentioned embodiment, and also includes a program improvement plan for subtask-related exceptions;

[0131] S203: Execute the second exception handling strategy.

[0132] In this step, the specific information of the second exception handling strategy may refer to the first exception handling strategy in S105 in the above embodiment.

[0133] The second exception handling strategy can be executed in the following way: if the second exception handling strategy is related to the code, the code is repaired based on the repaired code or code repair suggestion provided by the second exception handling strategy. After the code is repaired, regression testing is performed to ensure that the new changes do not introduce other exception problems. The repaired subtask is redeployed and released.

[0134] Optionally, after executing the second exception handling strategy, the second exception handling strategy and the corresponding prompt words need to be entered into the knowledge base of the subtask to update the knowledge base.

[0135] In this embodiment, the situation where the first log field of the log does not exist in the knowledge base corresponding to the subtask is processed, and the prompt word corresponding to the exception of the current subtask is generated by extracting key information from the log and combining it with the subtask, and the prompt word is processed based on the large model to generate the corresponding second exception handling strategy. The training large model is used to generate the processing strategy, which reduces the labor cost of exception handling and improves the efficiency of exception handling.

[0136] Figure 3 This is a schematic diagram of the structure of the exception handling device provided in the embodiment of the present application. Figure 3 As shown, the exception handling device 30 includes: a first acquisition module 301, a second acquisition module 302, a first processing module 303, a second processing module 304 and a third processing module 305;

[0137] The first acquisition module 301 is used to execute the pipeline task and obtain the execution result of the pipeline task; wherein the pipeline task includes multiple subtasks, and the pipeline task is pre-configured to monitor each subtask separately to obtain the processing data of each subtask, and the execution result of the pipeline task includes the sub-execution result of each subtask;

[0138] The second acquisition module 302 is used to acquire the log of the subtask when the sub-execution result of any subtask indicates that the subtask is executed abnormally;

[0139] The first processing module 303 is used to determine whether there is a target log field matching the first log field of the log in the knowledge base corresponding to the subtask;

[0140] The second processing module 304 is used to determine a first exception handling strategy corresponding to the target log field in a knowledge base when the target log field exists, and the knowledge base stores exception handling strategies corresponding to different exceptions;

[0141] The third processing module 305 is used to execute the first exception handling strategy.

[0142] In some embodiments, the first processing module is further configured to:

[0143] Determine a log field of a preset type in the log as a first log field;

[0144] The first log field is matched with the second log field included in the knowledge base to determine whether the target log field exists in the knowledge base.

[0145] In some embodiments, the first processing module 303 is further configured to:

[0146] It is determined whether there is a target log field identical to the first log field in the knowledge base.

[0147] In some embodiments, the first processing module 303 is further configured to:

[0148] If there is no target log field identical to the first log field in the knowledge base, determining a similar log field corresponding to each second log field contained in the knowledge base;

[0149] If there is a target similar log field identical to the first log field among the multiple similar log fields, the second log field corresponding to the target similar log field is determined as the target log field.

[0150] In some embodiments, the first acquisition module 301 is further used to:

[0151] According to the task functions, the subtasks contained in the pipeline task are classified to obtain multiple types of subtasks;

[0152] Create a corresponding knowledge base based on each type of subtask;

[0153] Each subtask is configured to monitor the sub-execution results of each subtask.

[0154] In some embodiments, the second processing module 304 is further configured to:

[0155] When there is no target log field matching the first log field of the log in the knowledge base corresponding to the subtask, generating a prompt word according to the subtask and the log;

[0156] Input the prompt word into the large model to obtain the second exception handling strategy output by the large model;

[0157] The third processing module 305 is further used to: execute the second exception handling strategy.

[0158] The exception handling device provided in the embodiment of the present application can be used to execute the technical solution of the exception handling method in the above embodiment. Its implementation principle and technical effect are similar and will not be repeated here.

[0159] It should be noted that it should be understood that the division of the various modules of the above device is only a division of logical functions. In actual implementation, they can be fully or partially integrated into one physical entity, or they can be physically separated. And these modules can all be implemented in the form of software calling through processing elements; they can also be all implemented in the form of hardware; some modules can also be implemented in the form of software calling through processing elements, and some modules can be implemented in the form of hardware. For example, the first processing module 303 can be a separately established processing element, or it can be integrated in a chip of the above device. In addition, it can also be stored in the memory of the above device in the form of program code, and called and executed by a processing element of the above device. The function of the first processing module 303. The implementation of other modules is similar. In addition, all or part of these modules can be integrated together, or they can be implemented independently. The processing element here can be an integrated circuit with signal processing capabilities. In the implementation process, each step of the above method or each module above can be completed by an integrated logic circuit of hardware in the processor element or instructions in the form of software.

[0160] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of the present application. Figure 4 As shown, the electronic device 40 may include: a transceiver 401 , a processor 402 , and a memory 403 .

[0161] The processor 402 executes the computer-executable instructions stored in the memory, so that the processor 402 executes the solution in the above embodiment. The processor 402 can be a general-purpose processor, including a central processing unit CPU, a network processor (NP), etc.; it can also be a digital signal processor DSP, an application-specific integrated circuit ASIC, a field programmable gate array FPGA or other programmable logic devices, discrete gates or transistor logic devices, and discrete hardware components.

[0162] The memory 403 is connected to the processor 402 via a system bus and completes communication between them. The memory 403 is used to store computer program instructions.

[0163] The transceiver 401 may be used to obtain tasks to be executed and configuration information of the tasks to be executed.

[0164] The system bus can be a peripheral component interconnect (PCI) bus or an extended industry standard architecture (EISA) bus, etc. The system bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, only one thick line is used in the figure, but it does not mean that there is only one bus or one type of bus. The transceiver is used to realize the communication between the database access device and other computers (such as clients, read-write libraries, and read-only libraries). The memory may include random access memory (RAM) and may also include non-volatile memory.

[0165] The exception handling device provided in the embodiment of the present application may be the processing terminal of the above-mentioned embodiment.

[0166] An embodiment of the present application also provides a chip for executing instructions, which is used to execute the technical solution of the exception handling method in the above embodiment.

[0167] An embodiment of the present application further provides a computer-readable storage medium, in which computer instructions are stored. When the computer instructions are executed on a computer, the computer executes the technical solution of the exception handling method of the above embodiment.

[0168] An embodiment of the present application also provides a computer program product, which includes a computer program stored in a computer-readable storage medium. At least one processor can read the computer program from the computer-readable storage medium. When at least one processor executes the computer program, the technical solution of the exception handling method in the above embodiment can be implemented.

[0169] In the several embodiments provided in the present application, it should be understood that the disclosed devices and methods can be implemented in other ways. For example, the device embodiments described above are only schematic, for example, the division of modules is only a logical function division, and there may be other division methods in actual implementation, such as multiple modules can be combined or integrated into another system, or some features can be ignored or not executed. Another point is that the mutual coupling or direct coupling or communication connection shown or discussed can be an indirect coupling or communication connection through some interfaces, devices or modules, which can be electrical, mechanical or other forms.

[0170] The modules described as separate components may or may not be physically separated, and the components shown as modules may or may not be physical units, that is, they may be located in one place or distributed on multiple network units. Some or all of the modules may be selected according to actual needs to implement the solution of this embodiment.

[0171] In addition, each functional module in each embodiment of the present application can be integrated into one processing unit, or each module can exist physically separately, or two or more modules can be integrated into one unit. The above-mentioned module-composed unit can be implemented in the form of hardware or in the form of hardware plus software functional units.

[0172] The above-mentioned integrated module implemented in the form of a software function module can be stored in a computer-readable storage medium. The above-mentioned software function module is stored in a storage medium, including a number of instructions for enabling a computer device (which can be a personal computer, a server, or a network device, etc.) or a processor to perform some steps of the methods of various embodiments of the present application.

[0173] It should be understood that the above processor can be a central processing unit (CPU), or other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor can be a microprocessor or any conventional processor. The steps of the method disclosed in the invention can be directly embodied as being executed by a hardware processor, or can be executed by a combination of hardware and software modules in the processor.

[0174] The memory may include a high-speed RAM memory, and may also include a non-volatile storage NVM, such as at least one disk memory, and may also be a USB flash drive, a mobile hard disk, a read-only memory, a magnetic disk or an optical disk, etc.

[0175] The bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus, etc. The bus can be divided into an address bus, a data bus, a control bus, etc. For ease of representation, the bus in the drawings of this application is not limited to only one bus or one type of bus.

[0176] The above storage medium can be implemented by any type of volatile or non-volatile storage device or a combination thereof, such as static random access memory (SRAM), electrically erasable programmable read-only memory (EEPROM), erasable programmable read-only memory (EPROM), programmable read-only memory (PROM), read-only memory (ROM), magnetic memory, flash memory, magnetic disk or optical disk. The storage medium can be any available medium that can be accessed by a general or special purpose computer.

[0177] An exemplary storage medium is coupled to a processor so that the processor can read information from the storage medium and write information to the storage medium. Of course, the storage medium can also be a component of the processor. The processor and the storage medium can be located in an application specific integrated circuit (ASIC). Of course, the processor and the storage medium can also exist as discrete components in an electronic control unit or a main control device.

[0178] Those skilled in the art can understand that all or part of the steps of implementing the above-mentioned method embodiments can be completed by hardware related to program instructions. The aforementioned program can be stored in a computer-readable storage medium. When the program is executed, the steps of the above-mentioned method embodiments are executed; and the aforementioned storage medium includes: ROM, RAM, disk or optical disk and other media that can store program codes.

[0179] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present application, rather than to limit it. Although the present application has been described in detail with reference to the aforementioned embodiments, those skilled in the art should understand that they can still modify the technical solutions described in the aforementioned embodiments, or replace some or all of the technical features therein with equivalents. However, these modifications or replacements do not cause the essence of the corresponding technical solutions to deviate from the scope of the technical solutions of the embodiments of the present application.

Claims

1. An exception handling method, characterized in that: include: Executing a pipeline task and obtaining an execution result of the pipeline task; wherein the pipeline task includes a plurality of subtasks, the pipeline task is pre-configured to monitor each subtask separately to obtain processing data of each subtask, and the execution result of the pipeline task includes a sub-execution result of each subtask; If the sub-execution result of any sub-task indicates that the sub-task is executed abnormally, obtaining the log of the sub-task; Determine whether there is a target log field matching the first log field of the log in a knowledge base corresponding to the subtask, wherein the knowledge base stores exception handling strategies corresponding to different exceptions; If the target log field exists, determining a first exception handling strategy corresponding to the target log field in the knowledge base; The first exception handling strategy is executed.

2. The method according to claim 1, characterized in that The determining whether there is a target log field matching the first log field of the log in the knowledge base corresponding to the subtask includes: Determine a log field of a preset type in the log as the first log field; The first log field is matched with a second log field included in the knowledge base to determine whether the target log field exists in the knowledge base.

3. The method according to claim 1 or 2, characterized in that: The determining whether there is a target log field matching the first log field of the log in the knowledge base corresponding to the subtask includes: It is determined whether the target log field identical to the first log field exists in the knowledge base.

4. The method according to claim 1 or 2, characterized in that: The method further comprises: If the target log field identical to the first log field does not exist in the knowledge base, determining a similar log field corresponding to each second log field contained in the knowledge base; If there is a target similar log field identical to the first log field among the multiple similar log fields, the second log field corresponding to the target similar log field is determined as the target log field.

5. The method according to claim 1 or 2, characterized in that: Before executing the pipeline task and obtaining the execution result of the pipeline task, the method includes: According to the task functions, the subtasks contained in the pipeline task are classified to obtain multiple types of subtasks; Create a corresponding knowledge base based on each type of subtask; Each subtask is configured to monitor the sub-execution results of each subtask.

6. The method according to claim 1, characterized in that The method further comprises: If the target log field matching the first log field of the log does not exist in the knowledge base corresponding to the subtask, generating a prompt word according to the subtask and the log; Input the prompt word into the large model to obtain a second exception handling strategy output by the large model; The second exception handling strategy is executed.

7. An exception handling device, characterized in that: include: A first acquisition module, used to execute a pipeline task and acquire an execution result of the pipeline task; wherein the pipeline task includes a plurality of subtasks, the pipeline task is pre-configured to monitor each subtask separately to acquire processing data of each subtask, and the execution result of the pipeline task includes a sub-execution result of each subtask; A second acquisition module, configured to acquire a log of any subtask when a sub-execution result of any subtask indicates that the subtask is executed abnormally; A first processing module, used to determine whether there is a target log field matching the first log field of the log in the knowledge base corresponding to the subtask; A second processing module is used to determine, when the target log field exists, a first exception handling strategy corresponding to the target log field in the knowledge base, wherein the knowledge base stores exception handling strategies corresponding to different exceptions; The third processing module is used to execute the first exception handling strategy.

8. An electronic device, characterized in that: include: A processor, and a memory communicatively connected to the processor; The memory stores computer-executable instructions; The processor executes the computer-executable instructions stored in the memory to implement the method according to any one of claims 1 to 6.

9. A computer-readable storage medium, characterized in that: The computer-readable storage medium stores computer-executable instructions, which are used to implement the method according to any one of claims 1 to 6 when executed by a processor.

10. A computer program product, characterized in that The invention comprises a computer program, which implements the method according to any one of claims 1 to 6 when being executed by a processor.

Images