Method, apparatus, device, and storage medium for handling faults

Abstract

A method, apparatus, device and storage medium for handling a fault are provided. The method proposed herein includes: receiving a fault data item and a plurality of alarm data items in an application system; based on the fault data item, obtaining at least one alarm data item associated with the fault data item from the plurality of alarm data items according to a knowledge graph, the knowledge graph representing a propagation relationship between faults of a plurality of entities in the application system; and based on the fault data item and the at least one alarm data item, providing an analysis result of the fault in the application system according to a model. In this way, more knowledge about handling the fault in the application system can be provided without updating the model, thereby improving the accuracy and efficiency of handling.

Description

Technical Field

[0001] The examples in this paper generally relate to the field of computers, and in particular to methods, apparatus, devices, and computer-readable storage media for processing alarm data in computer application systems. Background Technology

[0002] Currently, various application systems have been developed, especially large-scale application systems that can provide a variety of services. During the operation of these systems, various faults may occur. Application system alarms can notify administrators of system anomalies, and administrators can use alarms to narrow down the diagnostic scope and quickly determine the root cause of the fault. However, application systems may generate a large number of alarms, and sometimes there may be a large number of noisy alarms. Furthermore, sometimes seemingly unrelated alarms may be closely related to faults, making it difficult to identify the alarms associated with the fault in a timely and accurate manner, and hindering effective fault handling. Therefore, there is a need for a more accurate and efficient way to identify alarm data associated with faults, thereby enabling timely handling of faults in the application system and ensuring its healthy operation. Summary of the Invention

[0003] In a first aspect, a method for handling faults is provided. The method includes: receiving fault data items and multiple alarm data items from an application system; based on the fault data items, retrieving at least one alarm data item associated with the fault data items from the multiple alarm data items according to a knowledge graph representing the propagation relationships between faults of multiple entities in the application system; and providing analysis results of the faults in the application system based on the fault data items and at least one alarm data item, according to a model.

[0004] In a second aspect, an apparatus for handling faults is provided. The apparatus includes: a receiving module configured to receive fault data items and multiple alarm data items from an application system; an acquiring module configured to, based on the fault data items, acquire at least one alarm data item associated with the fault data items from the multiple alarm data items according to a knowledge graph, the knowledge graph representing the propagation relationships between faults of multiple entities in the application system; and a providing module configured to, based on the fault data items and at least one alarm data item, provide analysis results of the faults in the application system according to a model.

[0005] In a third aspect, an electronic device is provided. The 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. When executed by the at least one processor, the instructions cause the device to perform the method of the first aspect.

[0006] In a fourth aspect, a computer-readable storage medium is provided. The computer-readable storage medium stores computer-executable instructions that can be executed by a processor to implement the method of the first aspect.

[0007] In a fifth aspect, a computer program product is provided, which is tangibly stored in a computer storage medium and includes computer-executable instructions that, when executed by a device, cause the device to perform the method of the first aspect.

[0008] In this way, more knowledge about handling faults in application systems can be provided without updating the model, thereby improving the accuracy and efficiency of the process.

[0009] It should be understood that the content described in this section is not intended to limit the key or important features of the examples in this article, nor is it intended to restrict the scope of the solution. Other features will become readily apparent from the following description. Attached Figure Description

[0010] The above and other features, advantages, and aspects of the various examples herein will become more apparent when taken in conjunction with the accompanying drawings and the following detailed description. In the accompanying drawings, the same or similar reference numerals denote the same or similar elements, wherein: Figure 1 A schematic diagram of the example environment is shown; Figure 2 Flowcharts of example procedures for handling faults in some scenarios are shown; Figure 3 Block diagrams for acquiring knowledge graphs in some scenarios are shown; Figure 4 A block diagram is shown illustrating several scenarios for determining multiple alarm data items based on time recall. Figure 5 A block diagram is shown illustrating several scenarios for identifying multiple alarm data items based on entity recall. Figure 6 The diagrams illustrate several scenarios where model-based analysis results are provided. Figure 7 Flowcharts of example methods for handling faults in some scenarios are shown; Figure 8 Block diagrams of example devices for handling faults in some scenarios are shown; and Figure 9 A block diagram of an electronic device capable of implementing multiple illustrative scenarios is shown. Detailed Implementation

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

[0012] It should be noted that the headings of any section / subsection provided herein are not restrictive. Various examples are described throughout this document, and examples of any type may be included under any section / subsection. Furthermore, examples described in any section / subsection may be combined in any way with any other examples described in the same section / subsection and / or different sections / subsections.

[0013] In the description of the examples in this document, the term "including" and similar terms should be understood as open inclusion, i.e., "including but not limited to". The term "based on" should be understood as "at least partially based on". The term "an example" or "the example" should be understood as "at least one example". The term "some examples" should be understood as "at least some examples". Other explicit and implicit definitions may also be included below. The terms "first", "second", etc., may refer to different or the same objects. Other explicit and implicit definitions may also be included below.

[0014] The examples in this document may involve user data, data acquisition, and / or use. All of these aspects comply with relevant laws, regulations, and provisions. In the examples presented herein, all data collection, acquisition, processing, manipulation, forwarding, and use are conducted with the user's knowledge and confirmation. Accordingly, when implementing each example, the type, scope of use, and usage scenarios of any data or information that may be involved should be communicated to the user and their authorization obtained through appropriate means, in accordance with relevant laws and regulations. The specific methods of notification and / or authorization can vary depending on the actual situation and application scenario; the scope of the solution is not limited in this regard.

[0015] In this manual and the sample solutions, any processing of personal information will be conducted only under legal grounds (such as obtaining the consent of the data subject or being necessary for the performance of a contract) and will only be carried out within the scope stipulated or agreed upon. A user's refusal to process personal information beyond what is necessary for basic functions will not affect the user's use of basic functions.

[0016] Example Environment Currently, various application systems have been developed, especially large-scale application systems that can provide a variety of services. During the operation of an application system, alarms can notify administrators of anomalies in the system, and administrators can use alarms to narrow down the diagnostic scope and determine the root cause of the fault. However, application systems may generate a large number of alarms, and sometimes there may be a large number of noisy alarms. In addition, sometimes seemingly unrelated alarms may be closely related to faults, and existing technical solutions are insufficient to identify alarms associated with faults in a timely manner, making it difficult to handle faults accurately. Therefore, there is a need for a more accurate and efficient way to identify alarm data associated with faults, thereby enabling timely handling of faults in the application system and ensuring its healthy operation. See also Figure 1 Examples describing the application environment.

[0017] Figure 1 A schematic diagram of example environment 100 is shown. (e.g.) Figure 1 As shown, example environment 100 may include electronic device 110. In this example environment 100, electronic device 110 may run application 120 that performs multiple functions. Application 120 may be any suitable type of application for providing multiple functions, such as a video sharing application, an audio sharing application, etc. User 140 may interact with application 120 via electronic device 110 and / or its attached devices.

[0018] exist Figure 1 In environment 100, if application 120 is active, electronic device 110 can use application 120 to present interface 150 for providing a variety of functions.

[0019] In some cases, electronic device 110 communicates with server 130 to provide services to application 120. Electronic device 110 can be any type of mobile terminal, fixed terminal, or portable terminal, including mobile phones, desktop computers, laptop computers, notebook computers, netbook computers, tablet computers, media computers, multimedia tablets, handheld computers, portable gaming terminals, VR / AR devices, personal communication system (PCS) devices, personal navigation devices, personal digital assistants (PDAs), audio / video players, digital cameras / camcorders, positioning devices, television receivers, radio receivers, e-book devices, gaming devices, or any combination of the foregoing, including accessories and peripherals of these devices or any combination thereof. In some cases, electronic device 110 can also support any type of user-facing interface (such as "wearable" circuitry).

[0020] Server 130 can be a standalone physical server, a server cluster or distributed system composed of multiple physical servers, or a cloud server providing basic cloud computing services such as cloud services, cloud databases, cloud computing, cloud functions, cloud storage, network services, cloud communication, middleware services, domain name services, security services, content delivery networks, and big data and artificial intelligence platforms. Server 130 may include, for example, computing systems / servers such as mainframes, edge computing nodes, computing devices in a cloud environment, etc. Server 130 can provide background services for the application 120 in electronic device 110 that supports fault handling.

[0021] A communication connection can be established between server 130 and electronic device 110. This communication connection can be established via wired or wireless means. The communication connection can include, but is not limited to, Bluetooth, mobile network, Universal Serial Bus (USB), and Wireless Fidelity (WiFi) connections. In some cases, server 130 and electronic device 110 can exchange signaling information through their communication connection.

[0022] It should be understood that the structure and function of the various elements in environment 100 are described for illustrative purposes only and do not imply any limitation on the scope of the scheme. The examples will continue to be described below with reference to the accompanying drawings. In some cases, the application system may include electronic device 110 and / or server 130.

[0023] When a failure occurs in a large-scale application system, an "alarm storm" often occurs, characterized by a massive, multi-source, heterogeneous flood of alarms generated within a very short period, with an excessive number of noisy alarms. This makes it difficult for administrators to quickly identify alarms related to the failure. Furthermore, some failures exhibit strong correlations, requiring manual correlation of numerous alarms, which is time-consuming and labor-intensive. These types of failures often require more immediate handling, and manual processing is often insufficient to meet the timeliness requirements. Moreover, alarm content may be incomplete and non-standardized. In particular, large-scale distributed application systems contain numerous different components, developed and managed by different teams. This leads to inconsistent alarm formats and potential inaccurate or missing alarm descriptions. Human understanding of these descriptions is difficult, making it challenging to accurately manage failures and alarms through textual descriptions.

[0024] While technical solutions for handling faults have been developed, these solutions heavily rely on expert experience. Large-scale distributed application systems have complex architectures and intricate fault propagation chains, requiring administrators with exceptional expertise to accurately identify propagation paths. Although machine learning models have been proposed for managing alarm data in application systems, the training and fine-tuning of these models require a vast amount of ground-value data and lengthy training, fine-tuning, and repeated testing to ensure model stability. Furthermore, machine learning models often lack knowledge of the application system's architecture and corresponding fault handling mechanisms, potentially leading to misinterpretations during inference. Therefore, there is a need for a more accurate and efficient way to process alarm data, thereby addressing faults in application systems promptly and ensuring their healthy operation.

[0025] To at least partially address the aforementioned problems, a method for handling faults is proposed. In summary, a large volume of received alarm data can first be filtered using a knowledge graph. Then, a machine learning model is used to process the smaller set of alarm data obtained after filtering and perform inference. Given that machine learning models lack domain knowledge of the application system, domain knowledge can be used in advance based on the knowledge graph to select a candidate set of alarm data more conducive to fault handling from the massive alarm data. Subsequently, the powerful text understanding capabilities of the machine learning model can be used to semantically associate alarms and faults. At this point, the machine learning model only needs to analyze the semantic correlation between fault data and alarm data to accurately associate faults and alarms.

[0026] Specifically, the proposed method receives fault data items and multiple alarm data items from an application system; based on the fault data items, it uses a knowledge graph to extract at least one alarm data item associated with the fault data item from the multiple alarm data items, where the knowledge graph represents the propagation relationship between faults of multiple entities in the application system; and based on the fault data items and at least one alarm data item, it provides analysis results of the faults in the application system according to a model. In this way, scattered valid alarms can be accurately associated with known fault contexts, thereby improving fault handling efficiency.

[0027] Specifically, this method provides a more accurate and efficient way to process alarm data and effectively correlate alarm data with system faults. It can accurately determine whether there are known faults related to the alarms to be processed, and execute correlation actions when relevant faults exist, thereby effectively aggregating alarms into the corresponding fault handling process. This aggregated processing approach accelerates fault location and resolution. Through this fault-centric alarm handling method, fault investigation and handling in application systems can be advanced in a timely manner, ensuring the healthy operation of application systems.

[0028] The proposed solution addresses the problems of time-consuming and labor-intensive fine-tuning of models, insufficient generalization ability, and the lack of domain knowledge in general models. It should be understood that the most direct solution to the lack of domain knowledge in models is domain fine-tuning; however, fine-tuning requires significant resources and data, and is time-consuming and labor-intensive. Furthermore, fine-tuned models lack generalization ability, requiring continuous retraining with substantial resources when their performance declines. Directly applying the model without domain knowledge can produce numerous illusions, rendering the association results unreliable. The proposed solution pre-injects the necessary domain knowledge into the knowledge graph, then selects at least one alarm data item more relevant to the fault for subsequent processing.

[0029] Compared with existing technical solutions (such as manual processing, statistical processing, machine learning models, etc.), the proposed technical solution has significant advantages in text understanding, understanding the framework of the application system (fault propagation range), noise resistance, maintenance cost, distinguishing the propagation mode of similar faults, and intelligent evolution.

[0030] See Figure 2 Describe the proposed technical solution. Figure 2 A flowchart 200 illustrates example procedures for handling faults in several scenarios. For example... Figure 2 As shown, the system can receive fault data item 212 and multiple alarm data items 210. Here, fault data item 212 can represent a description of a fault occurring in the application system, and alarm data item 210 can represent alarm information provided by the application system. It should be understood that a large number of alarm data items may be generated during the operation of the application system, and these alarm data items can notify the application system of abnormal states in real time. However, these alarm data items may be associated with one or more faults. Therefore, during fault handling, it is necessary to identify one or more alarm data items associated with fault data item 212.

[0031] Before invoking model 230 to perform inference, multi-path recall 220 can be performed to filter out irrelevant alarm data items. Specifically, spatial recall 222 can be performed based on knowledge graph 250. Since model 230 lacks knowledge about the deployment architecture and service dependencies of the application system, knowledge graph 250 can be used to supplement this knowledge. Specifically, a knowledge graph can be built based on the propagation of historical faults in the application system, and new faults can obtain historical influencing factors through the knowledge graph.

[0032] It should be understood that, due to the model's lack of knowledge regarding the duration of the fault's impact, alternatively and / or additionally, time-based recall 224 can be performed to supplement the aforementioned knowledge. Specifically, the trend of alarm density changes over time can be derived from a large number of historical fault cases, and the timing of stopping alarm data item reception can be dynamically determined based on the changes in alarm density. Furthermore, because the model lacks knowledge of the mapping relationships between entities in the application system, it cannot identify whether different terms in various data items represent the same entity. For example, a certain IP (Internet Protocol) address and a certain hostname in the application system can have a one-to-one mapping relationship and represent the same entity. Through the mapping relationship, it is possible to identify whether multiple terms represent the same entity, thereby improving the accuracy of subsequent alarm processing. Although various recall methods have been described above, in some cases, one or more recalls from multiple paths can be performed.

[0033] Through multi-path recall 220, at least one alarm data item with a closer correlation to fault data item 212 can be selected from a large number of alarm data items. At this point, fault data item 212 and the selected at least one alarm data item can be input into model 230 to provide analysis results 240. Alternatively and / or additionally, if the analysis results 240 are confirmed to be correct, the knowledge graph 250 can be updated using these results.

[0034] In some scenarios, an offline knowledge building process can be provided. This can receive historical alarm data, historical fault tickets (including manually confirmed fault causes and associated alarms), and system topology information from the configuration management database. Through offline data mining, a context-aware fault propagation graph containing rich information can be constructed. This graph serves as the core knowledge base. The graph can be a structured, weighted directed graph containing fault type and severity information.

[0035] In some scenarios, online association processes can be provided. When a new fault occurs and generates an initial alarm, online association can be performed. Multipath recall can leverage domain knowledge to coarsely screen a large number of alarms, allowing the model to identify alarms truly relevant to the fault. Multipath recall does not rely on a single information source but can efficiently filter candidate alarm sets from multiple complementary perspectives in parallel. Specifically, spatial (graph) recall can recall alarms from downstream nodes along a specific propagation path based on the type of the current fault. Temporal (window) recall can employ adaptive dynamic time windows to recall alarms occurring within the fault's impact period. Entity (rule and semantic) recall can combine key entity matching in text to recall highly relevant alarms. The model then receives the candidate alarm set output by multipath recall and organizes it along with fault context information into structured prompts. The model acts as a constrained causal inference engine, responsible for the final judgment and filtering of candidate alarms, outputting high-confidence association results.

[0036] In some cases, an adaptive evolutionary process can be provided. Administrators can verify the accuracy of the analysis results output by the model and automatically trigger updates to the offline knowledge graph. For example, if a new fault propagation path is manually identified, the corresponding edges can be automatically added or enhanced in the graph. In this way, a continuously iterative and knowledge-enhancing graph can be formed, enabling the proposed technical solution to identify new or rare fault propagation patterns in the future.

[0037] In some cases, the knowledge graph 250 may include nodes (represented by circles, e.g., nodes 252, 256) and edges (represented by line segments, e.g., edge 254). Specifically, multiple nodes may represent multiple entities in the application system. Edges may exist between multiple nodes, with the direction of the edge indicating the direction of fault propagation between a first entity and a second entity among the multiple entities. Specifically, a directed graph G = (V, E) can be constructed, where node V represents various entities in the application system, such as logical units like services, middleware, and databases. Alternatively and / or additionally, node V may also represent physical or virtual nodes that carry these units, such as instance names, virtual machine identifiers, etc., to support finer-grained associations. Directed edges E may represent historical, confirmed fault propagation relationships. In this way, the knowledge graph can be used to represent the propagation relationships of faults that have occurred in the application system at a finer granularity, thereby supplementing the domain knowledge lacking in the model.

[0038] In some cases, edges may further include at least one of the following attributes: fault type, fault severity, or historical propagation information of the fault. Here, the attributes of each edge are not single weights, but tuples containing multidimensional contextual information, the structure of which can be represented, for example, as: {fault type, fault severity, propagation probability / frequency}. For example, node 256 can represent "switch A", and node 252 can represent "service B". The edge from "switch A" to "service B" can be recorded with the attributes {fault type: "network jitter", propagation frequency: 2+1, fault severity: P0}. Here, the propagation frequency can represent a historical propagation frequency of 2 and a current propagation frequency of 2+1=3. Alternatively and / or additionally, another edge can be recorded as {fault type: "CPU overload", propagation frequency: 0+1, fault severity: P3}, and so on.

[0039] In some cases, a simplified graph structure can be provided. The edges of the graph can consist only of weights that indicate the frequency of associations. Updating the graph is also simplified to simply accumulating the edge weights. In this way, although the ability to leverage fault context for more refined recall is lost, this approach simplifies the logic of graph construction and maintenance.

[0040] A knowledge graph can be built by analyzing historical failures; see [link / reference]. Figure 3 To describe more details, the Figure 3 A block diagram 300 illustrates several scenarios for acquiring knowledge graphs. For example... Figure 3 As shown, historical faults 310 can be analyzed, and fault handling can be performed at box 320 to determine the fault category 332 and fault level 334. Alternatively and / or additionally, the services affected by the fault 330 and the service to which the fault belongs 336 can be determined. Specifically, the fault source entity (S_src), the affected downstream entity (S_dst), and the root cause type (T_fault) and fault level (L_fault) of each fault can be extracted. Subsequently, a directed edge from node S_src to S_dst can be found or created in the knowledge graph, and the propagation count corresponding to (T_fault, L_fault) on that edge can be updated. In some cases, different thresholds can be set based on the number of alarms received at that time to determine whether each edge is considered. If the number of alarms is higher than the threshold, the corresponding edge is considered; otherwise, the corresponding edge is not considered.

[0041] It should be understood that in scenarios where faults and alarms are associated, not all faults can affect all services along their service dependencies. For example, a large-scale network fault may cause the service dependencies of a network service node to have a wide impact on the knowledge graph, but if that node experiences other non-network type faults, it may not be necessary to recall alarms from so many nodes. Faults have varying degrees of impact depending on their type and severity. Using the proposed scheme, by injecting fault categories and severity levels into the knowledge graph—that is, injecting specific service entities into the nodes of the knowledge graph and adding fault severity and categories to the edges—automatic filtering based on historical faults can be achieved, and at least one alarm data item associated with a fault can be found more accurately.

[0042] In some cases, obtaining at least one alarm data item from a plurality of alarm data items includes: in response to a fault data item indicating a fault at a first entity in the application system, obtaining a first node in a knowledge graph, the first node corresponding to the first entity; based on the knowledge graph, obtaining a second node in the knowledge graph, an edge existing between the first node and the second node, and the second node corresponding to a second entity; and based on the second entity, obtaining at least one alarm data item from the plurality of alarm data items, wherein the alarm data item in the at least one alarm data item is associated with the second entity.

[0043] In some scenarios, when a new fault occurs at node C, the number of current alarms can be counted to determine the weight m of the edge corresponding to that number. The fault type can be determined using a model; assuming the fault type is T_new, a spatial recall algorithm is initiated. This algorithm does not perform an indiscriminate breadth-first or depth-first search on the graph, but instead prioritizes traversing paths starting from node C where the "fault type" in the edge attributes completely matches or is semantically similar to T_new, and the frequency of that type is greater than a threshold. For downstream nodes found on these paths, if alarms are generated within a specified time window, these alarms can be added to the candidate set. This method gives the recall process "contextual awareness." For example, a network fault will be recalled along network dependency paths, while an application fault at the same node will be recalled along the service call chain. In this way, the recall accuracy can be greatly improved, effectively suppressing noise amplification in "area-scale fault" scenarios.

[0044] Since knowledge graph-based associations are merely preliminary filtering before invoking the model, they can be simply updated using a union approach, recording the broadest impact of such faults historically. The model can then be invoked to make precise decisions. This method avoids adding all service nodes of the entire service dependency graph to the candidate set, which introduces significant noise to the model, while continuously evolving the specific impact of faults based on fault propagation patterns.

[0045] In some cases, feedback from the model can be used to dynamically update the knowledge graph. Specifically, in response to confirming the correctness of the analysis results, the knowledge graph is updated based on those results. It should be understood that for existing rule-based solutions, graph-based association solutions, and model fine-tuning, it is difficult to add empirical knowledge to the model when new fault types or new propagation patterns (i.e., affecting different ranges) emerge. Specifically, graph-based solutions struggle to decide which to retain based on existing knowledge; the fixed vertices and edges of a graph limit its ability to record only one propagation pattern. Model fine-tuning requires collecting high-quality data and undergoing a time-consuming and labor-intensive new round of adjustments. Here, the proposed technical solution, based on a collaborative approach between the knowledge graph and the model, can continuously update the knowledge graph.

[0046] In some cases, updating a knowledge graph based on analysis results can include at least one of the following: updating nodes in the knowledge graph based on entities in the analysis results; updating edges in the knowledge graph based on fault propagation relationships in the analysis results; or updating at least one attribute of an edge in the knowledge graph based on faults in the analysis results. See also... Figure 3 As shown in box 340, a map update can be performed.

[0047] like Figure 3 As shown, the existing knowledge graph 250 can be updated to a new knowledge graph 352. For example, new nodes can be added. If a fault is found to propagate from the entity represented by node 362 to a new entity, a new node 364 can be added to the knowledge graph to represent the new entity. New edges can be added; for example, a new edge can be added between nodes 362 and 364, which can be represented as: {Fault Type: "Type XXX", Propagation Frequency: 0+1, Fault Level: P2}. Alternatively and / or additionally, if a fault is found to propagate from the entity represented by node 360 ​​to the entity represented by node 362, at least one attribute of the edge between nodes 360 and 362 can be updated. For example, the propagation frequency can be updated to the current number plus 1, and so on. In this way, the knowledge graph can be continuously updated using the fault dependencies that have been confirmed to be correct. At this time, the knowledge graph can continuously include relevant knowledge of various types of faults in the application system, thereby supplementing the domain knowledge lacking in the model.

[0048] In some scenarios, during the graph update process, not only manually confirmed "positive samples" (confirming associations) can be used, but also manually excluded "negative samples" (confirming non-associations) can be utilized. Specifically, when a "fault-alarm" pair is confirmed as irrelevant, the weight of the corresponding graph path can be reduced. Alternatively and / or additionally, it can be removed when the weight falls below a certain threshold. Introducing negative feedback can make the graph converge faster, more effectively correct erroneous propagation path assumptions, and further improve the accuracy of the graph. However, this requires the front-end interaction to support "exclusion" operations.

[0049] In some scenarios, feedback-based intelligent evolution loops can establish low-cost, automated knowledge update mechanisms, enabling systems to learn from newly occurring or even never-before-seen fault modes, achieving continuous capability evolution without retraining or fine-tuning expensive large models. When a work order for handling a fault is closed, and the work order includes a list of associated alarms ultimately confirmed by the administrator, "manually labeled" ground truth results can be automatically captured. Based on the captured feedback, the knowledge graph is updated.

[0050] For a manually confirmed association (e.g., from entity D to entity E, caused by fault type T), if a corresponding edge does not exist in the graph, a new edge can be created and its attributes initialized. If the association already exists in the graph, the count of the corresponding edge can be incremented, thus updating its propagation frequency. The graph can be defined as "the union of all possibilities," while the model is responsible for "dynamically selecting the most relevant subset" from this union based on the specific fault context at each runtime. This separation of responsibilities makes the graph maintenance logic exceptionally simple, thus avoiding time-consuming and laborious model fine-tuning while ensuring the system can quickly learn and adapt to new knowledge.

[0051] Details regarding spatial recall 222 have been described. In some cases, temporal recall 224 and entity recall 226 can supplement spatial recall 222, respectively supplementing the model with domain knowledge about the time range of failure impact and entity alias mapping that it does not possess on its own.

[0052] See below. Figure 4 Describe the specific process of recalling 224. Figure 4 A block diagram 400 illustrates several scenarios for determining multiple alarm data items based on time recall. In some cases, the timestamps of multiple alarm data items fall within a threshold time window. For example, a predefined time window can be set, which can be determined based on the impact time of historical faults. For instance, a threshold time window could be defined as 30 minutes before and after the fault occurrence time (or other time lengths). See also... Figure 4Assuming the fault occurs at time T1, then time points T0 to T2 can be used as a time window 410. In this way, alarm data items with minor time dependencies can be filtered out.

[0053] In some situations, the time window can be dynamically adjusted. During the reception of multiple alarm data items, the density of multiple alarm data items received within a threshold time window can be obtained; and in response to determining that the density is higher than a threshold density, the threshold time window can be extended. For example... Figure 4 As shown, the time window can be extended along the extension direction 420. Specifically, time recall can be achieved by setting an adaptive dynamic sliding window. To avoid missing later alarms for persistent faults due to a fixed time window, the window can be dynamically extended based on alarm density.

[0054] Specifically, alarm recall can begin from an initial time window (e.g., time window 410, i.e., including 30 minutes before and after the fault occurrence time). The alarm density within the window can be obtained. Alternatively and / or additionally, the alarm density for a certain time period at the end of the window (e.g., the last 10 minutes) can be obtained. If this density is higher than a preset threshold, it indicates that the fault impact may still be ongoing, and the window will automatically extend backward by one step (e.g., 15 minutes), and this process will be repeated until the alarm density drops or the preset maximum window duration is reached. At this point, time window 420 can be expanded to time window 430, i.e., including the time period between time point T0 and T3. In this way, it can be ensured that more alarms that may be related to the fault are continuously retrieved.

[0055] In some cases, entity recall may include entity identification and text semantic similarity matching. See also Figure 5 For more details describing the entity recall, the Figure 5 A block diagram 500 illustrates several scenarios for determining multiple alarm data items based on entity recall. For example... Figure 5 As shown, the system identifies identical entities in fault data item 510 and alarm data items 210, 520, ..., 522. Specifically, identical entities can be determined based on mapping relationship 520. The identified text representing identical entities can be replaced with the same content. Feature extraction 530 can be performed to determine the features of each data item. Furthermore, semantic similarity comparison 540 can be performed, and alarm data items 520, ..., 522 with higher semantic similarity to fault data item 510 can be selected.

[0056] In some cases, regular expressions or named entity recognition techniques can be used to extract uniquely identifying hard entities, such as IP addresses, hostnames, instance identifiers, and tracking identifiers, from fault and alarm data items. In other cases, besides regular expressions, dictionary-based methods can also be used for entity recognition. Dictionary-based methods can maintain a dynamically updated entity database; this method offers high accuracy, but its coverage depends on the completeness of the dictionary.

[0057] Because the model lacks knowledge of the mapping relationships between entities in the application system, it cannot identify whether different terms in various data items represent the same entity. For example, it can be specified that a certain IP address and a certain hostname have a one-to-one mapping relationship and represent the same entity. For example, an interface can be provided to complete the mapping between IP addresses (e.g., "10.0.0.1") and hostnames (e.g., "host01"). If an alarm data item and a fault data item include one or more of the same entities (such as sharing the same IP), the alarm data item is given high priority and directly added to the candidate set. This provides the model with the knowledge that "10.0.0.1" and "host01" are from the same device. In this way, the mapping relationship can be used to identify whether multiple terms represent the same entity, thereby improving the accuracy of subsequent alarm processing. Furthermore, the semantic similarity between fault data items and alarm data items can be determined in a more accurate way.

[0058] In some cases, alarm data items with low semantic similarity to the fault data item can be filtered out, while those with high semantic similarity can be retained. In other words, the semantic similarity between the fault data item and at least one of the recalled alarm data items is higher than a threshold similarity. This ensures a high correlation between the recalled alarm data item and the fault data item, thereby improving the accuracy of fault diagnosis.

[0059] In some cases, semantic similarity between fault data items and alarm data items can be determined by converting each alarm data item into a high-dimensional vector using a pre-trained encoder model (e.g., a sentence vector model). Fault data items can also be converted to vector format, and their similarity (e.g., cosine similarity) can be calculated to determine semantic similarity. In some cases, the K alarm data items that are semantically closest to the fault data item can be recalled. In other cases, different methods can be used to determine similarity. For example, a lighter-weight bag-of-words model or other pre-trained language models can be used.

[0060] In some cases, Model 230 can be used to provide analytical results; see [link / reference]. Figure 6 Describe more details. Figure 6A block diagram 600 illustrates several scenarios where model-based analysis results are provided. For example... Figure 6 As shown, prompt words 620 can be provided to model 230 (e.g., a language model), prompt words 620 can instruct model 230 to generate analysis results 240 based on fault data item 510 and at least one alarm data item 520, ..., 522; and receive analysis results 240 from model 230.

[0061] In some scenarios, the powerful natural language understanding and logical reasoning capabilities of the model can be leveraged to perform accurate causal reasoning within a candidate set of alarm data items infused with domain knowledge, while structured input can suppress model "illusions." Structured prompts can be constructed; for example, at least one alarm data item obtained through the aforementioned multi-path recall strategy (reducing the number of alarm data items from thousands to dozens) can be integrated with fault data items, optionally including contextual information (e.g., fault occurrence time, source entity, fault type, etc.). Constraints can be injected into the prompts; for example, the model can be instructed to act as a senior system administrator, analyzing the causal relationships between fault data items and alarm data items.

[0062] In this way, the model's reasoning can be constrained by real-world systems, rather than being purely textual associations. Furthermore, the model's output format can be specified: for example, the model can be required to output results in a standardized JavaScript Object Notation (JSON) format. Each alert data item can correspond to an entry, including, for example, a Boolean judgment of "Associated with: True / False" and a "Reason:..." field explaining the basis for its reasoning in natural language. This structured output facilitates automatic system parsing and provides a transparent decision-making process for human verification.

[0063] In some scenarios, inference can be performed based on traditional machine learning models (e.g., gradient boosting decision trees, logistic regression, etc.). In this case, feature engineering is required on the "fault-alarm" pair. For example, various numerical features can be extracted, including time difference, text similarity score, entity co-occurrence count, and graph path length, and then a binary classification model is trained for judgment. This approach offers extremely fast inference speed and low resource consumption. Although this technical solution has limited ability to understand complex and fuzzy semantic relationships, it is particularly suitable for simple application systems with high real-time requirements.

[0064] In some situations, different model sizes can be chosen based on sensitivity to cost and response time. For example, in scenarios with extremely stringent time requirements, a smaller, faster distillation model can be used. In offline analysis scenarios where extreme accuracy is sought, a model with a larger number of parameters can be used. Small-scale models are fast and inexpensive, but their inference capabilities and accuracy are relatively weaker. Large-scale models perform better, but their cost and latency are also higher.

[0065] The proposed scheme provides a collaborative processing architecture for multi-dimensional pre-screening and model refinement. Specifically, the complex alarm association task can be decoupled into two core stages: multi-dimensional recall and model refinement. The recall stage performs rapid and high-recall pre-screening of massive real-time alarms from multiple dimensions, including spatial (graph), temporal (dynamic window), entity (hard association), and semantic (vector), generating a scalable and highly relevant candidate alarm set. The refinement stage submits this candidate set, along with rich contextual information, to a language model, leveraging its powerful logical reasoning capabilities to perform the final causal relationship determination and output highly accurate association results.

[0066] Using the provided scheme, a holistic processing procedure of convergence followed by refinement is proposed. This procedure provides the model with necessary domain knowledge through multi-path recall, effectively overcoming the "illusion" problem of the model. Simultaneously, pre-screening significantly reduces the model's processing load, resolving the cost and timeliness issues of directly using the model for association. This improves the performance of accuracy, recall, and timeliness in complex systems.

[0067] The proposed scheme provides a context-aware knowledge graph for fault propagation. Unlike existing static topology graphs, the directed edges of the proposed knowledge graph not only represent dependencies, but their attributes also include key contextual information such as "fault type," "fault level," and "historical propagation frequency." During spatial recall, based on the current fault type, traversal can prioritize specific paths in the graph that match that type, and the specific propagation frequency threshold can be determined based on the system's current health status (alarm level). In this way, fault type and fault level can be used as graph edge attributes to distinguish propagation paths, thus making the graph dynamic. It can predict completely different "explosion radii" for different types of faults at the same node, thereby achieving higher recall accuracy.

[0068] Using the proposed scheme, a decoupled, lightweight online evolution closed-loop mechanism is put forward. Specifically, knowledge can be injected into the knowledge graph outside the model, rather than updating the model itself. Specifically, the knowledge graph is automatically updated by capturing the final association results verified by humans. If a new fault propagation pattern is discovered, a new edge is created in the graph. If an existing pattern is confirmed, the frequency of the corresponding edge is increased. In this way, the advantages of "self-evolution" and "low maintenance cost" can be achieved. Through the above decoupled design, the model can quickly absorb new knowledge and adapt to new faults at extremely low cost. Compared with existing technical solutions that require high fine-tuning costs or rely on hard-coded rule updates, the proposed technical solution can achieve higher efficiency.

[0069] Experimental data demonstrate that the proposed fault-alarm association method based on spatiotemporal entity multi-angle recall and model co-optimization achieves significant technical results in practical applications. Compared with existing technologies, the proposed solution exhibits substantial advantages in accuracy, processing efficiency, maintenance costs, and system evolution capabilities. The proposed solution can be deployed in fault handling platforms for large-scale distributed application systems. In real-world fault scenarios, this solution provides higher automated association capabilities and achieves an exponential improvement in fault diagnosis efficiency.

[0070] In summary, a multi-angle recall strategy can build a reasoning foundation for the model that incorporates spatiotemporal, topological, and entity knowledge, fundamentally solving the problems of model "illusion" and cost. Furthermore, utilizing a unique context-aware graph can overcome the cognitive bottlenecks of traditional methods, achieving deep association. In addition, a lightweight, decoupled evolutionary loop enables self-learning and maintenance-free capabilities. In this way, the proposed technical solution achieves higher performance in terms of accuracy, comprehensiveness, timeliness, and maintainability of alarm association.

[0071] Example process Figure 7 A flowchart of an example method 700 for handling faults in several scenarios is shown. Method 700 can be implemented in an electronic device with processing capabilities. At block 710, fault data items and multiple alarm data items from an application system are received. At block 720, based on the fault data items, at least one alarm data item associated with the fault data items is retrieved from the multiple alarm data items according to a knowledge graph representing the propagation relationships between faults of multiple entities in the application system. At block 730, based on the fault data items and at least one alarm data item, an analysis result of the fault in the application system is provided according to a model.

[0072] In some cases, the timestamps of multiple alarm data items fall within the threshold time window.

[0073] In some cases, receiving multiple alarm data items includes: obtaining the density of multiple alarm data items received within a threshold time window; and extending the threshold time window in response to determining that the density is higher than a threshold density.

[0074] In some cases, a knowledge graph includes: multiple nodes, each representing a different entity in an application system; and edges between the nodes, the direction of which indicates the direction of fault propagation between the first entity and the second entity among the multiple entities.

[0075] In some cases, the edge may further include at least one of the following attributes: the type of fault, the severity of the fault, or the historical propagation information of the fault.

[0076] In some cases, the method further includes updating the knowledge graph based on the analysis results in response to determining that the analysis results are correct.

[0077] In some cases, updating a knowledge graph based on the analysis results includes at least one of the following: updating nodes in the knowledge graph based on entities in the analysis results; updating edges in the knowledge graph based on fault propagation relationships in the analysis results; or updating at least one attribute of an edge in the knowledge graph based on faults in the analysis results.

[0078] In some cases, the semantic similarity between a fault data item and an alarm data item in at least one alarm data item is higher than the threshold similarity.

[0079] In some cases, providing analysis results includes: providing cue words to the model, which instruct the model to generate analysis results based on fault data items and at least one alarm data item; and receiving analysis results from the model.

[0080] Example devices and equipment A corresponding apparatus for implementing the above methods or processes is also provided. Figure 8 A schematic structural block diagram of an example device 800 for handling faults under certain circumstances is shown. Device 800 can be implemented as or included in an electronic device. The various modules / components in device 800 can be implemented by hardware, software, firmware, or any combination thereof.

[0081] like Figure 8As shown, the device 800 includes: a receiving module 810 configured to receive fault data items and multiple alarm data items in an application system; an acquisition module 820 configured to acquire at least one alarm data item associated with the fault data item from the multiple alarm data items based on the fault data item and according to a knowledge graph, wherein the knowledge graph represents the propagation relationship between faults of multiple entities in the application system; and a providing module 830 configured to provide analysis results of faults in the application system based on the fault data item and at least one alarm data item, according to a model.

[0082] In some cases, the timestamps of multiple alarm data items fall within the threshold time window.

[0083] In some cases, receiving multiple alarm data items includes: obtaining the density of multiple alarm data items received within a threshold time window; and extending the threshold time window in response to determining that the density is higher than a threshold density.

[0084] In some cases, a knowledge graph includes: multiple nodes, each representing a different entity in an application system; and edges between the nodes, the direction of which indicates the direction of fault propagation between the first entity and the second entity among the multiple entities.

[0085] In some cases, the edge may further include at least one of the following attributes: the type of fault, the severity of the fault, or the historical propagation information of the fault.

[0086] In some cases, a processing module is further included, configured to update the knowledge graph based on the analysis results in response to determining that the analysis results are correct.

[0087] In some cases, the processing module is further configured to update the knowledge graph based on the analysis results, including at least one of the following: updating nodes in the knowledge graph based on entities in the analysis results; updating edges in the knowledge graph based on fault propagation relationships in the analysis results; or updating at least one attribute of edges in the knowledge graph based on faults in the analysis results.

[0088] In some cases, the semantic similarity between a fault data item and an alarm data item in at least one alarm data item is higher than the threshold similarity.

[0089] In some cases, the providing module is further configured to: provide prompt words to the model, which instruct the model to generate analysis results based on fault data items and at least one alarm data item; and receive analysis results from the model.

[0090] The modules included in device 800 can be implemented in various ways, including software, hardware, firmware, or any combination thereof. In some cases, one or more modules can be implemented using software and / or firmware, such as machine-executable instructions stored on a storage medium. In addition to or as an alternative to machine-executable instructions, some or all of the units in device 800 can be implemented at least partially by one or more hardware logic components. By way of example and not limitation, exemplary types of hardware logic components that can be used include field-programmable gate arrays (FPGAs), application-specific integrated circuits (ASICs), application-specific standard parts (ASSPs), systems on a chip (SOCs), complex programmable logic devices (CPLDs), and so on.

[0091] Figure 9 A block diagram of an electronic device 900 in which one or more examples can be implemented is shown. It should be understood that... Figure 9 The electronic device 900 shown is merely exemplary and should not be construed as limiting the functionality and scope of the examples described herein. Figure 9 The electronic device 900 shown can be used to implement the electronic device 110 discussed above.

[0092] like Figure 9 As shown, electronic device 900 is in the form of a general-purpose electronic device. Components of electronic device 900 may include, but are not limited to, one or more processing units or processors 910, memory 920, storage devices 930, one or more communication units 940, one or more input devices 950, and one or more output devices 960. Processor 910 may be a physical or virtual processor and is capable of performing various processes according to programs stored in memory 920. In a multiprocessor system, multiple processors execute computer-executable instructions in parallel to improve the parallel processing capability of electronic device 900.

[0093] Electronic device 900 typically includes multiple computer storage media. Such media can be any accessible media that is accessible to electronic device 900, including but not limited to volatile and non-volatile media, removable and non-removable media. Memory 920 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 930 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 and can be accessed within electronic device 900.

[0094] Electronic device 900 may further include additional removable / non-removable, volatile / non-volatile storage media. Although not explicitly stated... Figure 9 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 920 may include computer program product 929 having one or more program modules configured to perform various methods or actions of various examples.

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

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

[0097] 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. 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.

[0098] The flowcharts and / or block diagrams of the methods, apparatus, devices, and computer program products referred to herein describe various aspects. It should be understood that each block of the flowcharts and / or block diagrams, as well as combinations of blocks in the flowcharts and / or block diagrams, can be implemented by computer-readable program instructions.

[0099] 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.

[0100] 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.

[0101] The flowcharts and block diagrams in the accompanying figures illustrate the architecture, functionality, and operation of possible implementations of systems, methods, and computer program products under various scenarios. In this respect, 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 marked in the blocks may occur in a different order than those shown in the figures. 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, can 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.

[0102] Various examples have been described above. The foregoing 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 implementations disclosed herein.

Claims

1. A method for handling faults, comprising: Receive fault data items and multiple alarm data items from the application system; Based on the fault data item, at least one alarm data item associated with the fault data item is obtained from the plurality of alarm data items according to a knowledge graph, wherein the knowledge graph represents the propagation relationship between faults of multiple entities in the application system; and Based on the fault data items and the at least one alarm data item, the analysis results of the faults in the application system are provided according to the model.

2. The method according to claim 1, wherein the timestamps of the plurality of alarm data items are within a threshold time window.

3. The method according to claim 2, wherein receiving the plurality of alarm data items includes: Obtain the density of the plurality of alarm data items received within the threshold time window; as well as In response to determining that the density is higher than a threshold density, the threshold time window is extended.

4. The method according to claim 1, wherein the knowledge graph comprises: Multiple nodes, each representing a different entity in the application system; as well as The edges between the plurality of nodes, wherein the direction of the edges represents the direction of fault propagation between the first entity and the second entity among the plurality of entities.

5. The method of claim 4, wherein the edge further comprises at least one of the following attributes: the type of fault, the level of fault, or historical propagation information of fault.

6. The method of claim 5, further comprising: In response to determining that the analysis result is correct, the knowledge graph is updated based on the analysis result.

7. The method of claim 6, wherein updating the knowledge graph based on the analysis results comprises at least one of the following: Based on the entities in the analysis results, update the nodes in the knowledge graph; Based on the fault propagation relationships in the analysis results, update the edges in the knowledge graph; or Based on the faults identified in the analysis results, update at least one attribute of the edges in the knowledge graph.

8. The method according to claim 1, wherein the semantic similarity between the fault data item and the alarm data item in the at least one alarm data item is higher than a threshold similarity.

9. The method according to claim 1, wherein providing the analysis results comprises: Provide the model with prompt words that instruct the model to generate the analysis results based on the fault data items and the at least one alarm data item; as well as Receive the analysis results from the model.

10. An apparatus for handling faults, comprising: The receiving module is configured to receive fault data items and multiple alarm data items from the application system; The acquisition module is configured to acquire at least one alarm data item associated with the fault data item from the plurality of alarm data items based on the fault data item and according to a knowledge graph, wherein the knowledge graph represents the propagation relationship between faults of multiple entities in the application system. as well as A module is configured to provide analysis results of faults in the application system based on the fault data items and the at least one alarm data item, according to a model.

11. 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, the instructions causing the electronic device to perform the method according to any one of claims 1 to 9 when executed by the at least one processor.

12. A computer-readable storage medium having stored thereon computer-executable instructions that can be executed by a processor to implement the method according to any one of claims 1 to 9.

13. A computer program product tangibly stored in a computer storage medium and comprising computer-executable instructions that, when executed by a device, cause the device to perform the method according to any one of claims 1 to 9.

Images