Methods, apparatuses, devices, and media for managing faults in application systems

Abstract

Methods, apparatuses, devices, and media for managing faults in an application system are provided. In one method, in response to receiving log data associated with a fault, a fault description is determined based on the log data, the fault description representing at least one characteristic of the application system associated with the fault. At least one keyword is extracted from the fault description. A knowledge graph is retrieved to obtain a retrieval result matching the at least one keyword, the knowledge graph including knowledge associated with faults in the application system. Based on the retrieval result, a fault report associated with the fault is generated. With embodiments of the present disclosure, faults can be identified and handled in a more efficient and accurate manner.

Description

Technical Field

[0001] Embodiments of this disclosure generally relate to the field of computers, and in particular to methods, apparatus, devices, and computer-readable storage media for managing faults in application systems. Background Technology

[0002] Application systems with multiple functions have been developed. The increasing complexity of these systems makes fault management during their research, development, production, testing, and maintenance increasingly difficult. Existing technical solutions for assisting application system fault management often struggle to analyze and handle faults in a timely and accurate manner, thus their effectiveness in practical applications needs improvement. Summary of the Invention

[0003] In a first aspect of this disclosure, a method for managing faults in an application system is provided. The method includes: in response to receiving log data associated with a fault, determining a fault description based on the log data, the fault description representing at least one feature of the application system associated with the fault; extracting at least one keyword from the fault description; retrieving a knowledge graph to obtain search results matching the at least one keyword, the knowledge graph including knowledge associated with faults in the application system; and generating a fault report associated with the fault based on the search results.

[0004] In a second aspect of this disclosure, an apparatus for managing faults in an application system is provided. The apparatus includes: a determination module configured to, in response to receiving log data associated with a fault, determine a fault description based on the log data, the fault description representing at least one feature of the application system associated with the fault; an extraction module configured to extract at least one keyword from the fault description; a retrieval module configured to retrieve a knowledge graph to obtain retrieval results matching the at least one keyword, the knowledge graph including knowledge associated with faults in the application system; and a generation module configured to generate a fault report associated with the fault based on the retrieval results.

[0005] In a third aspect of this disclosure, an electronic device is provided. The electronic device includes: at least one processor; and at least one memory coupled to the at least one processor and storing instructions for execution by the at least one processor, the instructions causing the electronic device to perform the method according to a first aspect of this disclosure when executed by the at least one processor.

[0006] In a fourth aspect of this disclosure, a computer-readable storage medium is provided having a computer program stored thereon, which, when executed by a processor, causes the processor to implement the method according to a first aspect of this disclosure.

[0007] In a fifth aspect of this disclosure, a computer program product is provided, comprising a computer program that, when executed by a processor, implements the method according to a first aspect of this disclosure.

[0008] It should be understood that the content described in this content section is not intended to limit the key or essential features of the embodiments of this disclosure, nor is it intended to limit the scope of this disclosure. Other features of this disclosure will become readily apparent from the following description. Attached Figure Description

[0009] In the following detailed description, in conjunction with the accompanying drawings, the above and other features, advantages, and aspects of the embodiments of this disclosure will become more apparent. In the drawings, the same or similar reference numerals denote the same or similar elements, wherein:

[0010] Figure 1 A block diagram illustrating the application environment of this disclosure is shown; Figure 2 A block diagram illustrating a method for managing faults in an application system according to some embodiments of the present disclosure is shown. Figure 3 A block diagram of a system architecture according to some embodiments of the present disclosure is shown; Figure 4 A block diagram illustrating the operation of a preprocessing module according to some embodiments of the present disclosure is shown; Figure 5 A block diagram illustrating the operation of a post-processing module according to some embodiments of the present disclosure is shown; Figure 6 A block diagram of a knowledge graph according to some embodiments of the present disclosure is shown; Figure 7 A flowchart is shown illustrating a method for managing faults in an application system according to some embodiments of the present disclosure; and Figure 8 A block diagram of an apparatus capable of implementing various embodiments of the present disclosure is shown. Detailed Implementation

[0011] Embodiments of this disclosure will now be described in more detail with reference to the accompanying drawings. While some embodiments of this disclosure are shown in the drawings, it should be understood that this disclosure can be implemented in various forms and should not be construed as limited to the embodiments set forth herein. Rather, these embodiments are provided to provide a more thorough and complete understanding of this disclosure. It should be understood that the accompanying drawings and embodiments of this disclosure are for illustrative purposes only and are not intended to limit the scope of protection of this disclosure.

[0012] In the description of embodiments of this disclosure, the term "comprising" and similar terms should be understood as open-ended inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "one embodiment" or "the embodiment" should be understood as "at least one embodiment". The term "some embodiments" should be understood as "at least some embodiments". Other explicit and implicit definitions may also be included below. As used herein, the term "model" can represent a relationship between various data. For example, the above-mentioned relationships can be obtained based on various technical solutions that are currently known and / or will be developed in the future.

[0013] Application systems capable of performing various tasks have been developed. The increasing complexity of these systems makes fault management during their development, production, testing, and maintenance phases increasingly difficult. Existing technical solutions for assisting application system fault management often struggle to analyze and handle faults in a timely and accurate manner, thus their effectiveness in practical applications needs improvement.

[0014] For ease of description, in the context of this disclosure, only the vehicle system is used as an example of an application system to describe the specific process of fault management. Alternatively and / or additionally, the application system may be a system for performing other functions, such as communication applications, video applications, audio applications, etc.

[0015] Figure 1 A block diagram 100 illustrating the application environment of this disclosure is shown. For example... Figure 1 As shown, user 140 can use application system 110. Application system 110 may malfunction; in this case, fault data 112 can be sent to fault management system 120 so that fault management system 120 can output fault report 122. In existing fault handling processes, although machine learning model 130 has been used to assist in fault handling, the time from problem discovery to final repair can still be considerable. Furthermore, complex problems rely on manual handling by experts 142, and problems may circulate among multiple experts and / or engineers and stagnate, leading to a significant reduction in the timeliness of analysis. Therefore, a more efficient way to manage faults is desired.

[0016] To at least partially address the shortcomings of the prior art, according to one embodiment of this disclosure, a method for managing faults in an application system is proposed. See also Figure 2 A summary of one embodiment according to this disclosure is described. Figure 2 A block diagram 200 for managing faults in an application system according to some embodiments of the present disclosure is shown. Figure 2The fault management system 210 shown can perform intelligent diagnostics. Specifically, faults may occur in the application system 110, and the fault management system 210 can perform intelligent diagnostics. As shown by arrow 222, feedback, such as fault reports and / or work orders, can be automatically output. At this time, the work order management system 230 can automatically notify the engineer 240 or the expert 250 to perform follow-up processing.

[0017] Specifically, the fault management system 210 can receive log data 212, and optionally and / or additionally, can further receive manual feedback 214 from users. Here, users may include, for example, ordinary users of the application system, development engineers, test engineers, etc. In response to receiving the fault-related log data 212, a fault description can be determined based on the log data 212, the fault description representing at least one characteristic of the application system associated with the fault. At least one keyword 221 can be extracted from the fault description. A knowledge graph 220 is retrieved to obtain search results matching at least one keyword; the knowledge graph 220 includes knowledge associated with faults in the application system 110; and based on the search results, a fault report associated with the fault is generated.

[0018] In this way, faults in the application system can be intelligently identified and analyzed, directly generating a comprehensive fault analysis report. Engineers can quickly locate the fault, identify its cause, and develop a repair plan based on the fault report. Optionally and / or additionally, the fault management system 210 can also intelligently dispatch problems based on the fault report.

[0019] Specifically, the proposed technical solution can address numerous problems in real-world scenarios, such as insufficient analytical depth and weak correlation capabilities for complex, multi-factor, and cross-module related faults. Through comprehensive retrieval of domain knowledge, the analytical capabilities of domain experts can be obtained. Furthermore, the proposed technical solution addresses the issue of low analytical reliability and susceptibility to "illusions" caused by directly using models to analyze logs due to a lack of factual evidence. Retrieval provides more relevant domain knowledge, ensuring that conclusions are based on solid evidence. In addition, it further addresses the problems of opaque analytical processes and untraceable conclusions in existing technical solutions, leading to poor reliability and hindering problem reproduction and experience transfer.

[0020] In summary, the proposed fault log analysis method aims to construct a closed-loop system of "perception-reasoning-reverse verification." Specifically, it provides two deeply coupled stages: "preprocessing" and "postprocessing," employing customized knowledge graph retrieval technology and iteratively calling plugins as needed. This approach breaks the rigid mechanism of linear analysis. Furthermore, by evaluating fault reports, the knowledge graph can be dynamically updated, forming a closed-loop system.

[0021] See Figure 3 Describe an overview of fault management. Figure 3 A block diagram 300 illustrating a system architecture according to some embodiments of the present disclosure is shown. For example... Figure 3 As shown, a preprocessing module 310 and a postprocessing module 320 may be provided; alternatively and / or additionally, a post-processing module 330 may be provided. Here, the preprocessing module 310 may perform preprocessing on the received log data 212 and feedback data 214. For example, fragment identification may be performed at block 311 to identify data fragments in the log data corresponding to different component types based on the types of components in the application system. Log normalization may be performed at block 312 to read the logs. Plugin scheduling may be performed at block 313 to convert the logs into an understandable format. Result output may be performed at block 314, that is, outputting a fault description in a predefined format, which represents at least one characteristic of the application system associated with a fault.

[0022] In some implementations, the fault description represents at least one feature associated with the fault in various readable formats. This at least one feature may include, but is not limited to, the fault's timestamp, type, components involved in the fault, name, content, details, status, location, tracking, etc. For example, the fault description can be represented in text format, which may include the names of each feature and the specific content of each feature. For example, "Timestamp: Times1; Type: Event,...". Another example is that the fault data can be represented in tabular format, where the first column may represent the feature name and the second column may represent the specific content of the feature, and so on. Yet another example is that the fault data can be represented in other structured formats, such as JavaScript Object Notation (JSON). It should be understood that the specific storage format of the fault description is not limited here; rather, it can be stored in any custom format, as long as the post-processing module 320 can understand the format of the fault description and can read the features associated with the fault included therein.

[0023] The post-processing module 320 can receive the output from the pre-processing module 310. At box 321, data processing can be performed, such as extracting keywords. Here, keywords can include text, such as "application unresponsive," "system crash," etc. Alternatively and / or additionally, keywords can include other strings, such as fault code "001," etc. At box 322, comprehensive retrieval can be performed, such as retrieving knowledge graph 322-1, network knowledge 322-2, similar cases 322-3, and historical cases 322-4, etc. At box 323, information assembly can be performed, such as combining fault descriptions, search results, etc., so that a machine learning model can be invoked to perform inference at box 324. At box 325, a fault report can be generated. Alternatively and / or additionally, the post-processing module 330 can perform subsequent processing. For example, at box 331, the generated fault report can be stored in a specified database. At box 332, subsequent operations can be performed, such as sending the fault report to designated personnel, etc.

[0024] See Figure 4 Further details about the preprocessing module 310 are described below. Figure 4 A block diagram 400 illustrating the operation of a preprocessing module 310 according to some embodiments of the present disclosure is shown. In some embodiments of the present disclosure, the preprocessing module 310 may, in response to receiving log data 212 associated with a fault, determine a fault description based on the log data 212, the fault description representing at least one characteristic of the application system associated with a fault. Here, the log data may be automatically collected by the application system's fault detection system. Alternatively and / or additionally, the user may specify log data to be submitted from a large amount of log data. Alternatively and / or additionally, the user may submit user feedback data describing the fault; for example, the user may describe the fault phenomenon using text (e.g., lag, screen flickering, overheating, etc.), the user may take screenshots or photos of the application system's display page, or describe the fault in other ways. In this way, comprehensive information related to the fault can be collected, thereby improving the accuracy of fault management.

[0025] In some embodiments of this disclosure, during the process of determining a fault description based on log data, data fragments in the log data can be determined based on the type of components in the application system; and at least one feature can be extracted from the data fragments based on the plugins corresponding to the component types. Specifically, the log data may involve multiple components in the application system (e.g., hardware, software, various modules within the software, etc.), and fragment identification 311 can be performed to determine the various data fragments in the log data corresponding to each component type. For example, at block 410, scheduling monitoring can be performed to monitor various resources involved in the preprocessing stage. At block 412, plugin monitoring can be performed to manage various plugins involved in the preprocessing stage. At block 413, tracing can be performed to obtain the status of various events related to the fault from the log data. For example, the response time, workload, etc. of a specified component can be continuously obtained.

[0026] It should be understood that log data is typically stored in binary format and has a compressed format. In this case, log normalization can be performed at box 312. Log normalization provides a unified abstract representation of different types of logs, facilitating specific analysis by different plugins and avoiding repeated execution of the identification, decompression, and retrieval processes by different plugins. In some embodiments of this disclosure, during the extraction of at least one feature from various data segments in the log, the data segments in the log data can be parsed based on their format to obtain the parsed data segments. Alternatively and / or additionally, to improve access efficiency, an index can be created for the parsed data segments; and based on the index, at least one feature can be extracted from the parsed data segments.

[0027] Specifically, the data segments in log data 420 can be parsed according to a predefined format, that is, the binary format can be converted into a understandable text format. An index 421 can be created to facilitate searching for the desired data within a large amount of data. Furthermore, an iterator 422 can be created, which serves as an interface for accessing the log data. In other words, access requests can be submitted to iterator 422, and the output from iterator 422 can be received. In this way, the required data can be obtained without knowing the internal format of the log data.

[0028] At box 313, plugin scheduling can be performed on one or more plugins based on the components involved in the fault, or global analysis scheduling can be selected. Dependency management between plugins can be implemented (e.g., defined through configuration) so that each plugin can extract fault clues related to the component and provide preliminary analysis of component-related issues. Specifically, plugin scheduling may involve dependency resolution 430, dynamic loading 431, and cooperative scheduling 432. Dependency resolution 430 can determine the dependencies between different parts of the log, thereby determining which / which plugins to call to analyze the data. Dynamic loading 431 can automatically load the plugins to be used (e.g., based on dynamic link libraries, etc.). Furthermore, cooperative scheduling 432 can be performed based on the already loaded plugins to extract the required multifaceted information from the log data.

[0029] At box 314, result output can be performed. Specifically, preprocessing results can be collected and organized, and data can be persisted. The persisted data can serve as input for subsequent inference and analysis. Optionally and / or additionally, the post-processing process can be triggered again when needed; for example, more log data can be received in real time, and plugins can be invoked for further analysis. Here, formatted result 440 can be output in a predefined manner. This formatted result 440 supports subsequent parsing of fault information, facilitates storage in a database, and is easy to filter. Furthermore, at box 450, automated management can automatically invoke the above-mentioned processes to form a unified automated processing pipeline.

[0030] In some embodiments of this disclosure, fault-related components can be identified from log data and / or feedback data, thereby obtaining at least one feature represented in a predetermined format. Features may include, for example, at least one of the following: fault timestamp, type, components involved in the fault, name, content, details, status, location, tracing, etc. For example, a fault description may be represented in the following format.

[0031] Table 1 Examples of Fault Descriptions

[0032] It should be understood that a fault description may include one or more characteristics of the fault, and for some complex faults, it may include nested characteristics. For example, the details of a fault may involve other faults with dependencies; in this case, the details may include other fault characteristics. For example, the "application unresponsive" fault in the example above may involve poor performance, main thread blocking, and so on. It should be understood that the above is merely illustrative, and other formats can be used to store fault descriptions. For example, for ease of analysis and understanding, JavaScript format can be used to store fault descriptions.

[0033] The details of the preprocessing process have been described below, see below. Figure 5 Describe more details about the post-processing procedure. Figure 5 A block diagram 500 illustrates the operation of a post-processing module 320 according to some embodiments of the present disclosure. Here, the post-processing module 310 is responsible for converting the domain-related core fault clue data determined by the pre-processing module 310 into accurate and readable fault reports. In this way, accurate fault location and fault cause reasoning can be achieved, thereby facilitating subsequent fault handling and repair. Specifically, at block 510, the results of pre-processing, such as fault descriptions represented in JSON or other formats, can be received.

[0034] At box 511, at least one keyword can be extracted from the fault description. This paper does not limit the specific algorithm used for keyword extraction; rather, various text processing algorithms or machine learning models can be used to extract keywords. Continuing the example above, the following keywords can be identified: Table 2 Examples of Keywords

[0035] As shown in Table 2, a basic fault can represent the core issue related to the fault, a fault subject can represent the subject that may experience a fault, and a combination item can represent various possible combinations of the basic fault and the fault subject. In this way, keywords can describe the core information related to the fault in a more concise manner, thereby facilitating the search for various fault-related knowledge. At box 512, feature information can be obtained based on keywords. Furthermore, a predefined knowledge graph (defined using entity lists and relation lists) can be obtained to perform a retrieval. In some embodiments of this disclosure, the knowledge graph can be predefined and includes knowledge associated with faults in the application system.

[0036] In some embodiments of this disclosure, knowledge graphs can be constructed in various ways. The core of constructing a knowledge graph is to transform fragmented information into a structured network of "entity-relationship-attribute," that is, to establish semantic relationships for data and enable computers to retrieve it more accurately. Knowledge graphs can be built based on domain-related fault knowledge. For example, various data sources such as development documents, user documents, code, and fault handling cases from the vehicle domain can be obtained, and a knowledge graph can be constructed according to the structure of nodes and edges.

[0037] A knowledge graph can include: multiple nodes, each representing a different entity associated with a fault in the application system; and edges between nodes, representing relationships between the entities. For example, Table 3 shows examples of multiple entities in a knowledge graph. Specifically, all entity nodes can include a source field to trace the original source (document, location within a document, link, fragment from log data, etc.) from which the entity was extracted.

[0038] Table 3 Examples of entities in knowledge pictures

[0039] Table 4 illustrates examples of multiple relationships in a knowledge graph, where edges can be used to represent the relationships between entities. Alternatively and / or additionally, edges may have a source, indicating which original material the relationship was extracted from. In some embodiments of this disclosure, edges may have weights representing the confidence level of the relationship; for example, edges of the report and trigger types have a weight of 1, representing a confidence level of 100%. As another example, the weights of edges of the performance, matching, causal, and link types can be between 0 and 1, representing the confidence level that the aforementioned relationship is true. This confidence level can be determined based on historical data during the construction of the knowledge graph.

[0040] Table 4 Examples of Relationships

[0041] It should be understood that the examples of entities and relationships shown above are merely illustrative; knowledge graphs can contain more, fewer, or different types of entities and relationships. See also Figure 6 Describes a knowledge graph represented graphically. Figure 6 A block diagram 600 of a knowledge graph according to some embodiments of the present disclosure is shown. For example... Figure 6 As shown, node 610 represents the event type, specifically, application unresponsiveness. Node 620 represents the vehicle type, node 630 represents the software type, node 640 represents the component type, node 650 represents the symptom type, node 660 represents the log type, node 670 represents the root cause type, and so on. Furthermore, edges 611 and 612 represent the report type, edge 613 represents the trigger type, edge 614 represents the manifestation type, edge 615 represents the matching type, and edge 616 represents the causal relationship type, and so on.

[0042] Given the relevant summary information (e.g., features, entities, relationships), an enhanced knowledge graph retrieval can be performed based on this summary information to obtain entities and relationships (corresponding to some fault analysis knowledge and analysis weights). In some embodiments of this disclosure, a weighted enhanced knowledge graph is provided. The construction process is described below, which involves segmenting knowledge from various domains, for example, identifying entity relationships in each database, constructing a knowledge graph, and storing the data. This knowledge graph can be used in the retrieval phase of the reasoning analysis.

[0043] return Figure 5 Continuing the description of the retrieval process, at box 513, an enhanced knowledge graph retrieval can be performed to obtain retrieval results matching at least one keyword. For example, keywords determined according to the process described above can be input into the knowledge graph. In some embodiments of this disclosure, during the process of retrieving the knowledge graph to determine retrieval results matching at least one keyword, multiple nodes of the knowledge graph can be retrieved to determine nodes matching at least one keyword; and retrieval results can be determined based on nodes. Here, point-based retrieval can find nodes corresponding to a certain keyword. In this case, the input keyword can involve the type, description, key attributes, etc. of the node, and the retrieval output can be a list of nodes matching the keyword. At this time, the relationship between nodes is not considered; rather, each node matching the keyword can be accurately found. For example, based on the keywords described above, from Figure 6 The knowledge graph shown contains nodes 610, 640, 650, and so on. Furthermore, search results can be determined based on relevant information about each node in the node list (e.g., description, attributes, source, etc.).

[0044] In some embodiments of this disclosure, during the process of retrieving a knowledge graph to determine search results matching at least one keyword, edges of the knowledge graph can be retrieved to determine edges matching at least one keyword; and search results can be determined based on at least one node associated with the edge. Here, the input keyword can represent the type, direction (e.g., source node -> destination node), description, and other conditions of the relationship, and the output can include the relationship itself or node pairs connecting the relationships. In this case, the core of the search is the relationship between two nodes. For example, based on the keywords described above, one can retrieve results from... Figure 6 The knowledge graph shown shows edges 615 and 616, and so on. Subsequently, nodes 660 and 670 can be found.

[0045] In some embodiments of this disclosure, during the process of retrieving edges from a knowledge graph to determine edges matching at least one keyword, edges with weights greater than a preset threshold can be filtered based on a comparison of the weights with that threshold. Here, the preset threshold could be, for example, 0.7 (or other values). In other words, edges with higher weights (i.e., more reliable) can be given priority, thereby finding more relevant information that matches the fault in a more accurate manner. Assuming... Figure 6 This includes another node (not shown) that has a causal relationship with node 650 and a weight of 0.5 (significantly lower than the weight of 0.85 for causal relationship 616). In this case, node 670, which has a higher weight, can be retrieved preferentially.

[0046] In some embodiments of this disclosure, retrieval can be performed based on both nodes and edges. Specifically, the combined use of node-based and edge-based retrieval can fully leverage the structured advantages of knowledge graphs. Node-based retrieval allows for rapid entity location and attribute filtering, achieving accurate and efficient positioning. Edge-based retrieval can uncover relationships, path dependencies, and deep connections between entities, providing the semantic logic behind the data. The combination of both ensures both the accuracy and coverage of the retrieval, while also enhancing the relevance and interpretability of the information. The retrieval results are no longer isolated information but form a traceable and reasonable knowledge network, thereby significantly improving the depth of analysis and the reliability of subsequent fault handling.

[0047] Alternate and / or additional locations allow for various types of searches. Return Figure 5 ,like Figure 5 As shown in box 514, probability statistics and case association can be performed by combining a classic case library. In this way, a topological connection of global knowledge can be constructed, facilitating cross-domain expert analysis. Alternative and / or additional methods can be used to search the internal case library to find similar or related problems. Alternative and / or additional methods, such as... Figure 5 As shown in box 515, further web retrieval can be performed based on the summary information. After obtaining key information from the web retrieval, the information is reordered to obtain the most relevant solution information.

[0048] like Figure 5As shown, in box 516, auxiliary information obtained through various methods can be summarized. In box 517, comprehensive analysis can be performed on the auxiliary information. The retrieved information can be provided to a language model, alternatively and / or additionally, for comprehensive analysis using an internal general model. If a conclusion can be directly obtained, a fault report is generated, providing the analysis chain and citation sources. In some embodiments of this disclosure, prompt words can be constructed using the obtained fault description and retrieval structure, and a machine learning model (e.g., a language model) can be used to generate a fault report. The prompt words, for example, can instruct the machine learning model to generate a fault report based on the fault description and various retrieved fault-related knowledge. For example, the prompt words can specify the main content of the fault report: overview, analysis, causal relationships, handling suggestions, summary, basis for analysis, etc.

[0049] At box 518, a fault report can be output. Table 5 below schematically shows an example of a fault report. It should be understood that the fault report in Table 5 is merely illustrative, and alternatively and / or additionally, fault reports may include other formats and / or content.

[0050] Table 5 Examples of Fault Reports

[0051] At box 519, the user can read the fault report and confirm whether the current fault can be ruled out based on the report. If the generated fault report does not meet expectations, incremental analysis can be initiated at box 520. Specifically, in response to determining that the search results do not meet predetermined conditions, the fault description can be further determined based on log data. Predetermined conditions can specify at least one of the following: the number of data records in the search results, the type of data records, or the number of data record types. Here, the predetermined conditions can, for example, indicate the number of data records that should be included in the search results, and log data can be reread if this number is less than a predetermined threshold (e.g., 10 or other values). Alternatively and / or additionally, the predetermined conditions can, for example, indicate the number of types of data records that should be involved in the search results, etc. If the number of data record types in the search results is less than a predetermined threshold (e.g., 5 or other values), log data is reread. Alternatively and / or additionally, the predetermined conditions can specify that the search results should include relevant data for nodes of the "root cause" type or relevant data for nodes of the "symptom" type. If the search results do not include the above data, log data can be reread, etc.

[0052] Alternatively and / or additionally, based on the analysis conclusions, it can be determined whether to initiate incremental analysis. If more detailed data is needed, the preprocessing component can be invoked again at box 522 to obtain more fault-related information from the raw log data. Alternatively and / or additionally, more information can be collected from new log data received in real time. Furthermore, the process at boxes 511 to 518 can be repeated to complete further retrieval. Iterative analysis can be performed based on the retrieved data, forming a step-by-step inference loop mechanism. In this way, potential evidence related to the fault can be continuously sought, thereby improving the accuracy of fault management.

[0053] In some embodiments of this disclosure, a fault report can be sent to the application system administrator. This allows for a more accurate identification of the fault and the personnel associated with it. For example, the fault report can be sent to the person who submitted the fault request. Alternatively and / or additionally, the developer of the relevant code can be identified based on the fault location, and the fault report can be sent to that developer, and so on. This approach improves troubleshooting efficiency without requiring manual intervention from technical experts.

[0054] In some embodiments of this disclosure, the knowledge graph can be updated based on fault reports. Specifically, if the analysis in the fault report is confirmed to be accurate, reliable, and / or typical, the knowledge graph can be updated based on the fault report. For example, new entities and edges can be identified based on the fault report and added to the knowledge graph. Specifically, in the example above, it is assumed that the engineer has verified the accuracy and reliability of the fault report and has successfully repaired the fault according to the handling recommendations. A node representing a new log can be added to the knowledge graph. The description of the log node can include relevant log data of the current fault, and a new edge (e.g., representing a matching relationship) can be added between the log node and the existing node 650 in the knowledge graph. Alternatively and / or additionally, the weights of the edges in the knowledge graph can be updated. Specifically, since the engineer has successfully confirmed that the root cause of the current fault is "wireless service not responding," the weight of edge 616 can be increased (e.g., w=0.86).

[0055] In this way, the knowledge graph can be continuously updated as the fault management system operates, allowing it to include richer and more comprehensive knowledge. For example, the knowledge graph can be updated in real time. Alternatively and / or additionally, to improve update efficiency, fault reports can be collected and processed centrally at predetermined time points to update the knowledge graph.

[0056] It should be understood that the accuracy of ordinary machine learning models relies on static knowledge in the training data, which can lead to problems such as knowledge lag, factual errors, and the generation of illusions. Unlike existing technical solutions, the proposed retrieval and generation technology addresses the issues of outdated knowledge, susceptibility to illusions, and lack of traceability in models, while simultaneously ensuring both generation capability and the accuracy of the technical basis. This approach significantly improves the reliability and practicality of the output results. Specifically, it allows for real-time retrieval of the latest relevant reference information from external knowledge bases (e.g., knowledge graphs, case libraries, and online knowledge bases), using the retrieval results as the basis for generation, thereby greatly reducing illusions and enhancing factual consistency. Furthermore, the generated fault reports possess the characteristics of knowledge traceability, updability, and controllability, allowing for the integration of new data without retraining, reducing maintenance costs, and improving system controllability and security. This is particularly suitable for fault management scenarios with high requirements for accuracy and feedback speed.

[0057] By constructing a knowledge graph related to faults in application systems, the proposed solution effectively expands the application scenarios of fault management and improves its accuracy without requiring the training of dedicated models for each application system. Specifically, the solution significantly enhances the accuracy and reliability of fault analysis. Through a customized augmented knowledge graph and hybrid retrieval of other databases, rich factual evidence can be provided to machine learning models. This approach greatly reduces "illusions" and makes analytical conclusions more accurate and reliable.

[0058] The proposed technical solution possesses the capability to analyze deeply complex faults. For example, it can establish fault clues across multiple modules within an application system and across different time points during application operation, discovering hidden dependencies between various features through knowledge graphs. The proposed technical solution can combine the reasoning capabilities of a language model to effectively identify and eliminate complex faults. If necessary, the model analysis process can again invoke the preprocessing module to obtain more fault descriptions, thereby achieving deep retrieval and reasoning. In this way, on-demand loading and continuous exploration are possible, and the problem of context space explosion is avoided to some extent.

[0059] Furthermore, the proposed technical solution enables knowledge accumulation and efficient consolidation. By transforming expert experience and historical cases into digital assets (knowledge bases and knowledge graphs), knowledge barriers can be broken down, allowing engineers without extensive experience to obtain expert-level analysis reports, thereby accelerating user experience accumulation. Moreover, it achieves high efficiency and automation, automating the entire process from log input to report generation, completely freeing engineers from tedious log screening. It can significantly reduce fault handling time delays, for example, reducing waiting time from hours to minutes.

[0060] Figure 7 A flowchart of a method 700 for managing faults in an application system according to some embodiments of the present disclosure is shown. At block 710, in response to receiving log data associated with a fault, a fault description is determined based on the log data, the fault description representing at least one characteristic of the application system associated with the fault. At block 720, at least one keyword is extracted from the fault description. At block 730, a knowledge graph is retrieved to obtain search results matching the at least one keyword, the knowledge graph including knowledge associated with faults in the application system. At block 740, a fault report associated with the fault is generated based on the search results.

[0061] In some embodiments of this disclosure, determining a fault description based on log data includes: determining data segments in the log data based on the type of components in the application system; and extracting at least one feature from the data segments based on plugins corresponding to the type of components.

[0062] In some embodiments of this disclosure, extracting at least one feature from a data segment includes: parsing the data segment based on its format; creating an index for the parsed data segment; and locating and extracting at least one feature from the parsed data segment based on the index.

[0063] In some embodiments of this disclosure, the knowledge graph includes: multiple nodes, each node representing a multiple entity associated with a fault in the application system; and edges between the nodes, each edge representing a relationship between the multiple entities.

[0064] In some embodiments of this disclosure, retrieving a knowledge graph to determine search results matching at least one keyword includes: retrieving multiple nodes of the knowledge graph to determine nodes matching at least one keyword; and determining search results based on the nodes.

[0065] In some embodiments of this disclosure, retrieving a knowledge graph to determine search results matching at least one keyword includes: retrieving edges of the knowledge graph to determine edges matching at least one keyword; and determining search results based on at least one node associated with the edge.

[0066] In some embodiments of this disclosure, edges have weights, where the weights represent the confidence level of a relation, and retrieving edges from a knowledge graph to determine edges that match at least one keyword includes: filtering edges whose weights are greater than the preset threshold based on a comparison of the weights with the preset threshold.

[0067] In some embodiments of this disclosure, the method further includes: in response to determining that the search results do not meet the conditions, further determining a fault description based on log data, wherein a predetermined condition specifies at least one of the following: the number of data records in the search results, the type of data records, or the number of types of data records.

[0068] In some embodiments of this disclosure, the method further includes: determining a fault description based on user feedback data describing the fault.

[0069] In some embodiments of this disclosure, the method further includes updating at least one of the following in the knowledge graph based on fault reports: multiple nodes, edges, or weights.

[0070] This disclosure proposes an apparatus for managing faults in an application system. The apparatus includes: a determination module configured to, in response to receiving log data associated with a fault, determine a fault description based on the log data, the fault description representing at least one feature of the application system associated with the fault; an extraction module configured to extract at least one keyword from the fault description; a retrieval module configured to retrieve a knowledge graph to obtain retrieval results matching the at least one keyword, the knowledge graph including knowledge associated with faults in the application system; and a generation module configured to generate a fault report associated with the fault based on the retrieval results.

[0071] In some embodiments of this disclosure, the determining module is further configured to: determine data fragments in log data based on the type of components in the application system; and extract at least one feature from the data fragments based on a plugin corresponding to the type of the component.

[0072] In some embodiments of this disclosure, the determining module is further configured to: parse the data fragment based on its format; create an index for the parsed data fragment; and extract at least one feature from the parsed data fragment based on the index.

[0073] In some embodiments of this disclosure, the knowledge graph includes: multiple nodes, each node representing a multiple entity associated with a fault in the application system; and edges between the nodes, each edge representing a relationship between the multiple entities.

[0074] In some embodiments of this disclosure, the retrieval module is further configured to: retrieve multiple nodes of the knowledge graph to identify nodes that match at least one keyword; and determine retrieval results based on the nodes.

[0075] In some embodiments of this disclosure, the retrieval module is further configured to: retrieve edges of the knowledge graph to determine edges that match at least one keyword; and determine retrieval results based on at least one node associated with the edge.

[0076] In some embodiments of this disclosure, edges have weights, where the weights represent the confidence level of a relation, and retrieving edges from a knowledge graph to determine edges that match at least one keyword includes: filtering edges whose weights are greater than the preset threshold based on a comparison of the weights with the preset threshold.

[0077] In some embodiments of this disclosure, the determining module is further configured to: in response to determining that the search results do not meet the conditions, further determine a fault description based on log data, wherein the predetermined conditions specify at least one of the following: the number of data records in the search results, the type of data records, or the number of types of data records.

[0078] In some embodiments of this disclosure, the apparatus further includes a processing module configured to determine a fault description based on user feedback data describing the fault.

[0079] In some embodiments of this disclosure, the processing module is further configured to update at least one of the following in the knowledge graph based on the fault report: multiple nodes, edges, or weights.

[0080] Figure 8 A block diagram of an apparatus 800 capable of implementing various embodiments of the present disclosure is shown. It should be understood that... Figure 8 The computing device 800 shown is merely exemplary and should not be construed as limiting the functionality and scope of the embodiments described herein. Figure 8 The computing device 800 shown can be used to implement the method described above.

[0081] like Figure 8 As shown, computing device 800 is in the form of a general-purpose computing device. Components of computing device 800 may include, but are not limited to, one or more processors 810, memory 820, storage device 830, one or more communication units 840, one or more input devices 850, and one or more output devices 860. Processor 810 may be a physical or virtual processor and is capable of performing various processes based on programs stored in memory 820. In a multiprocessor system, multiple processors execute computer-executable instructions in parallel to improve the parallel processing capability of computing device 800.

[0082] Computing device 800 typically includes multiple computer storage media. Such media can be any available media accessible to computing device 800, including but not limited to volatile and non-volatile media, removable and non-removable media. Memory 820 can be volatile memory (e.g., registers, cache, random access memory (RAM)), non-volatile memory (e.g., read-only memory (ROM), electrically erasable programmable read-only memory (EEPROM), flash memory), or some combination thereof. Storage device 830 can be removable or non-removable media and can include machine-readable media, such as flash drives, disks, or any other media that can be used to store information and / or data (e.g., training data for training) and can be accessed within computing device 800.

[0083] The computing device 800 may further include additional removable / non-removable, volatile / non-volatile storage media. Although not explicitly stated... Figure 8 As shown, disk drives for reading from or writing to removable, non-volatile disks (e.g., "floppy disks") and optical disk drives for reading from or writing to removable, non-volatile optical disks can be provided. In these cases, each drive can be connected to a bus (not shown) via one or more data media interfaces. Memory 820 may include computer program product 825 having one or more program modules configured to perform various methods or actions of various embodiments of this disclosure.

[0084] The communication unit 840 enables communication with other computing devices via a communication medium. Additionally, the functionality of the components of the computing device 800 can be implemented as a single computing cluster or multiple computing machines capable of communicating via communication connections. Therefore, the computing device 800 can operate in a networked environment using logical connections to one or more other servers, network personal computers (PCs), or another network node.

[0085] Input device 850 can be one or more input devices, such as a mouse, keyboard, trackball, etc. Output device 860 can be one or more output devices, such as a monitor, speaker, printer, etc. Computing device 800 can also communicate as needed with one or more external devices (not shown) via communication unit 840. These external devices include storage devices, display devices, etc., and can communicate with one or more devices that enable user interaction with computing device 800, or with any device that enables computing device 800 to communicate with one or more other computing devices (e.g., network card, modem, etc.). Such communication can be performed via input / output (I / O) interfaces (not shown).

[0086] According to embodiments of the present disclosure, a computer-readable storage medium is provided that stores computer-executable instructions thereon, wherein the computer-executable instructions are executed by a processor to implement the methods described above. According to embodiments of the present disclosure, a computer program product is also provided, which is tangibly stored on a non-transitory computer-readable medium and includes computer-executable instructions, which are executed by a processor to implement the methods described above. According to embodiments of the present disclosure, a computer program product is provided that stores a computer program thereon, which, when executed by a processor, implements the methods described above.

[0087] Various aspects of this disclosure are described herein with reference to flowchart illustrations and / or block diagrams of methods, apparatuses, devices, and computer program products implemented according to this disclosure. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer-readable program instructions.

[0088] These computer-readable program instructions can be provided to a processor of a general-purpose computer, a special-purpose computer, or other programmable data processing apparatus to produce a machine such that, when executed by the processor of the computer or other programmable data processing apparatus, they create means for implementing the functions / actions specified in one or more blocks of the flowchart and / or block diagram. These computer-readable program instructions can also be stored in a computer-readable storage medium that causes a computer, programmable data processing apparatus, and / or other device to operate in a particular manner; thus, the computer-readable medium storing the instructions comprises an article of manufacture that includes instructions for implementing aspects of the functions / actions specified in one or more blocks of the flowchart and / or block diagram.

[0089] Computer-readable program instructions can be loaded onto a computer, other programmable data processing apparatus, or other device to cause a series of operational steps to be performed on the computer, other programmable data processing apparatus, or other device to produce a computer-implemented process, thereby causing the instructions that execute on the computer, other programmable data processing apparatus, or other device to perform the functions / actions specified in one or more boxes of a flowchart and / or block diagram.

[0090] The flowcharts and block diagrams in the accompanying drawings illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products according to various embodiments of this disclosure. In this regard, each block in a flowchart or block diagram may represent a module, segment, or portion of an instruction, which contains one or more executable instructions for implementing the specified logical function. In some alternative implementations, the functions indicated in the blocks may occur in a different order than those indicated in the drawings. For example, two consecutive blocks may actually be executed substantially in parallel, and they may sometimes be executed in reverse order, depending on the functions involved. It should also be noted that each block in the block diagrams and / or flowcharts, and combinations of blocks in the block diagrams and / or flowcharts, may be implemented using a dedicated hardware-based system that performs the specified function or action, or using a combination of dedicated hardware and computer instructions.

[0091] Various implementations of this disclosure have been described above. These descriptions are exemplary and not exhaustive, nor are they limited to the disclosed implementations. Many modifications and variations will be apparent to those skilled in the art without departing from the scope and spirit of the described implementations. The terminology used herein is chosen to best explain the principles, practical applications, or improvements to technology in the market, or to enable others skilled in the art to understand the various embodiments disclosed herein.

Claims

1. A method for managing faults in an application system, comprising: In response to receiving log data associated with the fault, a fault description is determined based on the log data, the fault description representing at least one characteristic of the application system associated with the fault; Extract at least one keyword from the fault description; Retrieve a knowledge graph to obtain search results matching the at least one keyword, the knowledge graph including knowledge associated with faults in the application system; as well as Based on the search results, a fault report associated with the fault is generated.

2. The method according to claim 1, wherein determining the fault description based on the log data includes: Based on the type of components in the application system, determine the data segments in the log data; as well as Based on the plugin of the type corresponding to the component, the at least one feature is extracted from the data fragment.

3. The method of claim 2, wherein extracting the at least one feature from the data fragment comprises: Based on the format of the data fragment, parse the data fragment; Create an index for the parsed data fragments; as well as Based on the index, the at least one feature is located and extracted from the parsed data fragment.

4. The method according to claim 1, wherein the knowledge graph comprises: Multiple nodes, each representing a multiple entity associated with a fault in the application system; as well as Edges between nodes, whereby the edges represent relationships between multiple entities.

5. The method of claim 4, wherein retrieving the knowledge graph to determine the search results matching the at least one keyword comprises: Retrieve the plurality of nodes in the knowledge graph to determine the node that matches the at least one keyword; as well as The search results are determined based on the node.

6. The method of claim 4, wherein retrieving the knowledge graph to determine the search results matching the at least one keyword comprises: Retrieve the edges of the knowledge graph to determine the edges that match the at least one keyword; as well as The retrieval result is determined based on at least one node associated with the edge.

7. The method of claim 6, wherein the edges have weights representing the confidence level of the relation, and retrieving the edges of the knowledge graph to determine the edges matching the at least one keyword comprises: Based on the comparison between the weight and the preset threshold, edges with weights greater than the preset threshold are filtered out.

8. The method of claim 1, wherein the method further comprises: In response to determining that the search results do not meet predetermined conditions, a fault description is further determined based on the log data, wherein the predetermined conditions specify at least one of the following: the number of data records in the search results, the type of the data records, or the number of types of the data records.

9. The method of claim 1, wherein the method further comprises: The fault description is determined based on user feedback data describing the fault.

10. The method of claim 7, wherein the method further comprises: Based on the fault report, update at least one of the following in the knowledge graph: the plurality of nodes, the edges, or the weights.

11. An apparatus for managing faults in an application system, comprising: A determination module is configured to, in response to receiving log data associated with the fault, determine a fault description based on the log data, the fault description representing at least one characteristic of the application system associated with the fault; The extraction module is configured to extract at least one keyword from the fault description; The retrieval module is configured to retrieve a knowledge graph to obtain retrieval results matching the at least one keyword, the knowledge graph including knowledge associated with faults in the application system; as well as The generation module is configured to generate a fault report associated with the fault based on the search results.

12. An electronic device, comprising: At least one processor; as well as At least one memory, coupled to the at least one processor and storing instructions for execution by the at least one processor, which, when executed by the at least one processor, cause the electronic device to perform the method according to any one of claims 1 to 10.

13. A computer-readable storage medium having stored thereon computer instructions that, when executed by a processor, cause the processor to perform the method according to any one of claims 1 to 10.

14. A computer program product comprising computer instructions, wherein the computer instructions, when executed by a processor, implement the method according to any one of claims 1 to 10.

Images