Root cause positioning method and device

Abstract

The invention provides a root cause positioning method and device. The method comprises the following steps: in response to acquired alarm information of a current alarm event, analyzing the alarm information to obtain an alarm type and an alarm intensity value of the current alarm event; generating an alarm source vector under the alarm type based on the alarm intensity value; taking a node corresponding to each non-zero element in the alarm source vector as a first father node, and querying an attenuation coefficient from the first father node to a first child node from a preset diffusion coefficient table; the first child node is a child node of at least one level connected with the first father node; determining the potential energy of each node in the service dependency graph based on the alarm intensity value of the first father node and the attenuation coefficient of the first child node of each level; and positioning the root cause node of the current alarm event from the service dependency graph based on the potential energy of each node in the service dependency graph. According to the invention, the accuracy of root cause positioning can be improved.

Description

Technical Field

[0001] This application relates to the field of computer technology, and in particular to a root cause localization method and apparatus. Background Technology

[0002] In distributed systems, microservice architecture improves scalability and flexibility by breaking down a monolithic application into multiple interdependent service instances. However, this architecture also significantly increases system complexity, especially when anomalies occur, as faults can propagate along multi-hop call chains, exhibiting a variety of interconnected symptoms. Therefore, quickly and accurately locating the root cause has become an important research direction in the field of operations and maintenance.

[0003] In related technologies, root cause analysis methods are typically based on alarm information and service dependency graphs. They often treat different types of alarms as uniform "energy" that can propagate equally along the service dependency graph to identify the most likely source of the fault. While such methods can reflect the dependencies between services, they often struggle to effectively distinguish between the true root cause and secondary effects, especially when alarm signals are complex and service topologies are dynamically changing. This can easily lead to location errors or misjudgments, thus reducing the accuracy and efficiency of root cause analysis. Summary of the Invention

[0004] This application provides a root cause localization method and apparatus. By identifying the alarm type of a current alarm event and querying the attenuation coefficient in a preset diffusion coefficient table, the alarm intensity value is propagated along the service dependency graph under that alarm type to obtain the potential energy of each node. Thus, based on the potential energy of each node, the root cause node of alarm events of different alarm types can be accurately located, improving the accuracy of root cause localization.

[0005] The technical solution of this application embodiment is implemented as follows:

[0006] This application provides a root cause localization method, the method comprising: in response to obtaining alarm information of a current alarm event, parsing the alarm information to obtain the alarm type and alarm intensity value of the current alarm event; generating an alarm source vector under the alarm type based on the alarm intensity value; each element in the alarm source vector corresponding to a node in the service dependency graph under the alarm type; taking the node corresponding to each non-zero element in the alarm source vector as a first parent node, querying the attenuation coefficient from the first parent node to the first child node from a preset diffusion coefficient table; the first child node being a child node at least one level connected to the first parent node; determining the potential energy of each node in the service dependency graph based on the alarm intensity value of the first parent node and the attenuation coefficient of the first child node at each level; and locating the root cause node of the current alarm event from the service dependency graph based on the potential energy of each node in the service dependency graph.

[0007] This application provides a root cause localization device, comprising: a parsing module, configured to parse the alarm information in response to obtaining alarm information of a current alarm event, and obtain the alarm type and alarm intensity value of the current alarm event; a generation module, configured to generate an alarm source vector under the alarm type based on the alarm intensity value; each element in the alarm source vector corresponds to a node in the service dependency graph under the alarm type; a query module, configured to query the attenuation coefficient from the first parent node to the first child node from a preset diffusion coefficient table, taking the node corresponding to each non-zero element in the alarm source vector as the first parent node; the first child node is a child node at least one level connected to the first parent node; a determination module, configured to determine the potential energy of each node in the service dependency graph based on the alarm intensity value of the first parent node and the attenuation coefficient of the first child node at each level; and a root cause localization module, configured to locate the root cause node of the current alarm event from the service dependency graph based on the potential energy of each node in the service dependency graph.

[0008] In the above scheme, the parsing module is further configured to: in response to obtaining the alarm information of the current alarm event, parse the type field in the alarm information having a preset format to obtain the alarm type of the current alarm event; and parse the level field in the alarm information to obtain the alarm level of the current alarm event; and map the alarm level to the alarm intensity value based on a preset mapping table.

[0009] In the above scheme, the generation module is further configured to: parse the node identifier field in the alarm information to obtain the node identifier of the alarm node corresponding to the current alarm event; construct a sparse vector corresponding to the alarm type based on the number of nodes in the service dependency graph; the dimension of the sparse vector is equal to the number of nodes, and each element in the sparse vector corresponds to a node in the service dependency graph; and write the alarm intensity value into the element position corresponding to the alarm node in the sparse vector based on the node identifier to obtain the alarm source vector under the alarm type.

[0010] In the above scheme, the determining module is further configured to: determine the alarm intensity value of the first parent node as the potential energy of the first parent node; determine the alarm intensity value of the first child node at each level as the initial potential energy of the first child node; determine the incremental potential energy of the first child node by multiplying the alarm intensity value of the first parent node by the attenuation coefficient of the first child node at each level; and for each first child node, determine the potential energy of the first child node by summing the initial potential energy and the incremental potential energy.

[0011] In the above scheme, the alarm system has multiple alarm types for alarm events; the root cause localization module is further configured to: for each node in the service dependency graph, obtain the potential energy of the node under each alarm type at the current time and the channel weight corresponding to each alarm type; sum the potential energy of multiple alarm types based on the channel weight to obtain the total potential energy of the node; determine the responsibility of each node based on the total potential energy of each node in the service dependency graph and the connection relationship between the nodes; and locate the root cause node of the current alarm event from the service dependency graph based on the responsibility.

[0012] In the above scheme, the root cause localization module is further configured to: for each node in the service dependency graph, take the node as the second parent node, determine at least one level of second child nodes connected to the second parent node based on the connection relationship; determine the total potential energy of the at least one level of second child nodes; and determine the degree of responsibility of the node based on the total potential energy of the node and the sum of the total potential energy.

[0013] In the above scheme, the root cause localization module is further configured to: sort the nodes in the service dependency graph in descending order of responsibility to form a node sequence; determine the first N nodes in the node sequence as the root cause nodes of the current alarm event; N is an integer greater than 0; or, determine the nodes with a responsibility level greater than a preset responsibility level threshold as the root cause nodes of the current alarm event.

[0014] In the above scheme, the root cause localization module is further used to: smooth the potential energy under each alarm type to obtain smoothed potential energy; and to weight and sum the smoothed potential energy under multiple alarm types based on the channel weights to obtain the total potential energy of the node.

[0015] In the above scheme, the root cause localization module is further configured to: for each alarm type, obtain the first potential energy of the node within a first time window before the current time and the second potential energy within a second time window; the window length of the first time window is less than the window length of the second time window; based on the first potential energy and the potential energy of the node at the current time, determine the third potential energy of the node within the first time window including the current time; based on the second potential energy and the potential energy of the node at the current time, determine the fourth potential energy of the node within the second time window including the current time; and fuse the third potential energy and the fourth potential energy to obtain the smoothed potential energy of the node.

[0016] In the above scheme, the device further includes: a table generation module, used to determine the call frequency and latency parameters between every two connected nodes in the service dependency graph before querying the attenuation coefficient from the first parent node to the first child node from a preset diffusion coefficient table; determine the target weight of the edge between every two connected nodes under different alarm types based on the call frequency and the latency parameters; generate a weight matrix for each alarm type based on the target weight of each edge under different alarm types; generate a Laplace matrix for each alarm type based on the weight matrix under the alarm type; determine the attenuation coefficient of each node in the service dependency graph based on the Laplace matrix; and store the attenuation coefficient of each node in the diffusion coefficient table.

[0017] In the above scheme, the table generation module is further configured to: for each node in the service dependency graph, take the node as the source node, traverse at least one level of child nodes connected to the source node to obtain a subgraph of the source node; construct the standard basis vector of the source node; and determine the decay coefficient of each node in the subgraph based on the element value corresponding to each node in the Laplacian matrix and the standard basis vector.

[0018] In the above scheme, the diffusion coefficient table corresponds to a version number; the device further includes: a table update module, used to determine the potential energy of each node in the service dependency graph based on the alarm intensity value of the first parent node and the attenuation coefficient of the first child node at each level, and then determine the energy conservation residual based on the potential energy of each node, the alarm intensity value, and the diffusion coefficient table; in response to the determination that the attenuation coefficient of a node in the service dependency graph has changed based on the energy conservation residual, the attenuation coefficient of the node is recalculated to obtain a new attenuation coefficient, and a new diffusion coefficient table is generated using the new attenuation coefficient; and a new version number is generated for the new diffusion coefficient table.

[0019] In the above scheme, the table update module is further configured to: obtain two service dependency graphs when performing root cause localization on two adjacent alarm events; determine the edge change rate between the two service dependency graphs; in response to the edge change rate being greater than a preset change rate threshold, recalculate the attenuation coefficient of the node to obtain a new attenuation coefficient, and use the new attenuation coefficient to generate a new diffusion coefficient table; and generate a new version number for the new diffusion coefficient table.

[0020] This application provides an electronic device, which includes: a memory for storing computer-executable instructions or computer programs; and a processor for executing the computer-executable instructions or computer programs stored in the memory to implement the root cause localization method provided in this application.

[0021] This application provides a computer-readable storage medium storing a computer program or computer-executable instructions for implementing the root cause localization method provided in this application when executed by a processor.

[0022] This application provides a computer program product, including a computer program or computer executable instructions. When the computer program or computer executable instructions are executed by a processor, they implement the root cause localization method provided in this application.

[0023] The embodiments of this application have the following beneficial effects:

[0024] When performing root cause analysis on a current alarm event, the alarm type and alarm intensity value are first obtained by parsing the alarm information, thereby constructing an alarm source vector for that alarm type. Next, using the attenuation coefficients in a pre-defined diffusion coefficient table, the alarm intensity value is propagated along the service dependency graph for that alarm type, obtaining the potential energy of each node in the service dependency graph. Finally, the root cause node of the current alarm event is located from the service dependency graph based on the node's potential energy. This effectively distinguishes the propagation paths of different alarm types, avoiding false alarms caused by mistransmission of resource-related alarms. Furthermore, by looking up the nodes corresponding to non-zero elements in the alarm source vector and combining this with the alarm intensity value to determine the potential energy of each node, it replaces the solution of the entire graph matrix, significantly improving online inference efficiency. Therefore, the root cause analysis method provided in this application can accurately and efficiently locate the root cause nodes of alarm events of different alarm types, thereby improving the accuracy and efficiency of root cause analysis. Attached Figure Description

[0025] Figure 1 This is an optional flowchart illustrating the root cause localization method provided in an embodiment of this application;

[0026] Figure 2 This is a schematic diagram illustrating the implementation process of obtaining alarm type and alarm intensity value provided in the embodiments of this application;

[0027] Figure 3 This is a schematic diagram illustrating the implementation process of generating alarm source vectors under different alarm types provided in this application embodiment;

[0028] Figure 4 This is the original service dependency graph provided in the embodiments of this application;

[0029] Figure 5 This is a channel-oriented diffusion diagram under the delay type provided in the embodiments of this application;

[0030] Figure 6 This is a schematic diagram of the implementation process for determining the potential energy of each node provided in an embodiment of this application;

[0031] Figure 7 This is a schematic diagram of the implementation process for locating the root cause node of the current alarm event provided in an embodiment of this application;

[0032] Figure 8 This is a schematic diagram illustrating the implementation process of the smoothing process provided in the embodiments of this application;

[0033] Figure 9 This is a schematic diagram of the offline generation process of the diffusion coefficient table provided in the embodiments of this application;

[0034] Figure 10 This is a schematic diagram illustrating one implementation process of updating the diffusion coefficient table provided in an embodiment of this application;

[0035] Figure 11 This is a schematic diagram of another implementation process for updating the diffusion coefficient table provided in an embodiment of this application;

[0036] Figure 12 This is a schematic diagram of the overall process of the root cause localization method provided in the embodiments of this application;

[0037] Figure 13 This is a structural block diagram of the root cause localization device provided in the embodiments of this application;

[0038] Figure 14 This is a schematic diagram of the structure of the electronic device provided in the embodiments of this application. Detailed Implementation

[0039] To make the objectives, technical solutions, and advantages of this application clearer, the application will be further described in detail below with reference to the accompanying drawings. The described embodiments should not be regarded as limitations on this application. All other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this application.

[0040] In the following description, references are made to “some embodiments,” which describe a subset of all possible embodiments. However, it is understood that “some embodiments” may be the same subset or different subsets of all possible embodiments and may be combined with each other without conflict.

[0041] In the following description, the terms "first, second, third" are used merely to distinguish similar objects and do not represent a specific ordering of objects. It is understood that "first, second, third" may be interchanged in a specific order or sequence where permitted, so that the embodiments of this application described herein can be implemented in an order other than that illustrated or described herein.

[0042] In the embodiments of this application, the terms "module" or "unit" refer to a computer program or part of a computer program that has a predetermined function and works with other related parts to achieve a predetermined goal, and can be implemented wholly or partially using software, hardware (such as processing circuitry or memory), or a combination thereof. Similarly, a processor (or multiple processors or memory) can be used to implement one or more modules or units. Furthermore, each module or unit can be part of an overall module or unit that includes the functionality of that module or unit.

[0043] Unless otherwise defined, all technical and scientific terms used in the embodiments of this application have the same meaning as commonly understood by one of ordinary skill in the art. The terminology used in the embodiments of this application is for the purpose of describing the embodiments of this application only and is not intended to limit this application.

[0044] In the implementation of this application, the collection and processing of relevant data should strictly comply with the requirements of relevant laws and regulations, obtain the informed consent or separate consent of the personal information subject, and carry out subsequent data use and processing within the scope of laws and regulations and the authorization of the personal information subject.

[0045] Before providing a further detailed description of the embodiments of this application, the nouns and terms involved in the embodiments of this application will be explained, and the nouns and terms involved in the embodiments of this application shall be interpreted as follows.

[0046] 1) Responding to: used to indicate the conditions or states on which the operation is performed depends. When the conditions or states on which it depends are met, one or more operations can be performed in real time or with a set delay. Unless otherwise specified, there is no restriction on the order in which the multiple operations are performed.

[0047] 2) Alarm Type: This refers to the category to which the alarm event belongs, such as Latency, Error, Resource, or Connectivity. Different alarm types have different propagation mechanisms and impact ranges. Alarm type is the basic classification for constructing a multi-channel impact field.

[0048] 3) Service Dependency Graph: This graph represents the call relationships between services in a microservice system. Nodes represent service instances, and edges between nodes represent the call chains between services. The service dependency graph is the basic topology structure in the root cause localization process, used to describe the propagation path of anomaly energy between services.

[0049] 4) Potential Energy: In this embodiment, potential energy is used to measure the intensity of abnormal energy accumulated at a node at the current moment. The higher the potential energy value, the more likely the node is to be the root cause of the fault. The calculation of potential energy is based on the propagation mechanism of alarm source vector, diffusion coefficient table, and attenuation coefficient.

[0050] 5) Attenuation Coefficient: This represents the attenuation ratio of anomalous energy as it propagates from one node to another. It is generated during the offline phase based on the service dependency graph and call statistics, and stored in a pre-defined diffusion coefficient table. During online inference, the attenuation coefficient is obtained by querying the diffusion coefficient table, thereby quickly completing the local propagation of anomalous energy.

[0051] 6) Intrinsic Responsibility Score (IRS): This measures the proportion of anomalous energy a node retains between itself and its immediate downstream nodes. A higher IRS indicates that the node is more likely to be the root cause of the failure. The IRS value is calculated based on the node's total potential energy and the sum of the potential energies of its downstream nodes.

[0052] 7) Dual Exponential Decay Smoothing: To suppress instantaneous spikes while retaining slow-rising fault characteristics, the alarm system maintains two exponential moving averages (fast window and slow window) in parallel for each node. These are then weighted to fuse the fault characteristics of the fast and slow windows into a smoothing potential energy. The fast window offers fast response, while the slow window provides high stability; their fusion effectively balances sensitivity and robustness.

[0053] 8) Energy Conservation Residual: Used to detect the consistency between the root cause localization model and the actual environment. The alarm system calculates the energy conservation residual after each root cause localization. If the energy conservation residual exceeds the set residual threshold, an offline recalculation mechanism is triggered to ensure the long-term accuracy and reliability of the root cause localization model.

[0054] 9) Root Cause Node: This refers to the node that is most likely to be the source of the anomaly in the current alarm event. The goal of root cause localization is to identify these nodes so that operations and maintenance personnel can handle the fault in a timely manner or initiate automated repair processes.

[0055] 10) Typed Laplace Matrix: A Laplace matrix constructed for each alarm type to describe the propagation pattern of that alarm type in the service dependency graph. The Laplace matrix has properties such as always having zero row sums and being positive semi-definite, thus ensuring the physical consistency of abnormal energy propagation.

[0056] The field of intelligent operations and maintenance (AIOps, Artificial Intelligence for IT Operations) has formed a research and engineering system centered on alarm correlation, root cause localization, and self-healing around "Metrics / Logs / Traces". Existing research has pointed out that fault localization methods in microservice scenarios are divided into multiple technical routes such as rule / statistics, graph traversal, and causal / learning, but they generally face challenges such as multimodal data, dynamic topology, and high real-time requirements. The root cause localization methods in related technologies have at least the following shortcomings that need to be improved: (1) The alarm type propagation mechanism is not distinguished. The mainstream approach in related technologies often treats different types of alarms such as delay, error, and resource (CPU / memory) as "energy" that can be propagated equally along the service dependency graph. This leads to resource alarms being spread incorrectly along the call chain, causing false alarms; while delay alarms that are really caused by the slowdown of downstream speed may be folded too early and miss the alarm, which seriously affects the localization accuracy. (2) Insufficient real-time performance, making it difficult to meet the millisecond-level closed-loop requirements. The graph traversal or depth model schemes in related technologies typically take more than 0.5–1 second to infer on service dependency graphs containing thousands to tens of thousands of edges. This cannot keep pace with high QPS online services, resulting in root cause analysis results often lagging behind fault evolution and limiting the effectiveness of automated self-healing capabilities. (3) Lack of interpretable and self-checking verification mechanisms. The schemes in related technologies only output the "most likely root cause node" without consistency verification. When the call weight or the topology of the service dependency graph drifts, there is a lack of quantitative monitoring to determine whether the root cause localization model still satisfies the conservation constraints and whether the inference error is controllable. It is difficult to detect and correct inaccuracy risks in a timely manner, thereby reducing the availability and reliability of the project.

[0057] To address at least one of the aforementioned problems in related technologies, this application proposes a root cause localization method and apparatus, improving upon these deficiencies by employing typed Laplace modeling and multi-channel influence field incremental solution, outputting with millisecond-level delays, and incorporating a residual self-checking mechanism to enhance the accuracy, real-time performance, and interpretability of root cause localization. Specifically, in the root cause localization method provided in this application, when performing root cause localization on a current alarm event, firstly, the alarm type and alarm intensity value are obtained by parsing the alarm information, thereby constructing the alarm source vector under that alarm type. Next, using the attenuation coefficients in a preset diffusion coefficient table, the alarm intensity value is propagated along the service dependency graph under that alarm type to obtain the potential energy of each node in the service dependency graph. Finally, the root cause node of the current alarm event is located from the service dependency graph based on the node's potential energy. In this way, the propagation paths of different alarm types are effectively distinguished, avoiding false alarms caused by mistransmission of resource-related alarms. Simultaneously, by performing local table lookups on the nodes corresponding to non-zero elements in the alarm source vector and combining this with the alarm intensity value to determine the potential energy of each node, the full graph matrix solution is replaced, significantly improving online inference efficiency. Therefore, the root cause localization method provided in this application can accurately and efficiently locate the root cause nodes of alarm events of different alarm types, thereby improving the accuracy and efficiency of root cause localization.

[0058] It should be noted that the embodiments of this application can be applied to various cloud-native service systems, and are particularly suitable for root cause analysis scenarios under large-scale microservice architectures. The root cause localization method of the embodiments of this application can achieve efficient, accurate, and interpretable root cause localization without relying on deep learning or graphics processing unit (GPU) acceleration, significantly improving the real-time performance and availability of AIOps systems.

[0059] The root cause localization methods provided in the embodiments of this application can be executed by an operation and maintenance monitoring system, an alarm processing engine, an alarm system, or an automated fault analysis platform. The operation and maintenance monitoring system, alarm processing engine, or automated fault analysis platform can be a distributed node deployed in a cloud-native service architecture or a standalone AIOps platform. The root cause localization methods in the embodiments of this application can be executed by a single distributed node as an alarm processing node, or by multiple collaboratively working distributed nodes, depending on the deployment method and load requirements of the alarm system.

[0060] In this embodiment, the alarm processing node can be implemented as an electronic device, which can be a terminal or a server. In one implementation, the electronic device for implementing the root cause localization method provided in this embodiment can be any terminal with alarm processing capabilities, such as a laptop, tablet, desktop computer, or intelligent robot. In another implementation, the electronic device provided in this embodiment can also be implemented as a server, which can be an independent physical server, a server cluster consisting of multiple physical servers, or a distributed system. The terminal and the server can be directly or indirectly connected via wired or wireless communication, and this embodiment does not impose any restrictions.

[0061] The root cause localization method provided in the embodiments of this application will be described in detail below with reference to the accompanying drawings.

[0062] Figure 1 This is an optional flowchart illustrating the root cause localization method provided in this application embodiment. The following will be combined with... Figure 1 The steps shown will be explained. It should be noted that... Figure 1 The root cause localization method in this example uses an electronic device as the executing entity. Figure 1 As shown, the method includes the following steps S101 to S105:

[0063] S101, in response to obtaining the alarm information of the current alarm event, the alarm information is parsed to obtain the alarm type and alarm intensity value of the current alarm event.

[0064] When a microservice system detects abnormal behavior, it generates an alert and sends it to the electronic device. The alert may include fields such as service instance identifier (nodeID), metric name (metricName), alert level (severityRaw), and timestamp. The electronic device parses the alert based on these fields and determines the alert type by checking the type field corresponding to the metric name. Alert types include Latency, Error, Resource, and Connectivity.

[0065] Delay-type alerts characterize slower response times, focusing on the time dimension. Corresponding alert metrics include: Response Time (RT), P99 / P95 latency, queue wait time, and call span time in the call chain. Delay-type alerts can be triggered by scenarios such as downstream dependencies hanging, thread pool exhaustion, garbage collection (GC) pauses, and sudden increases in RT due to network congestion. The propagation of delay-type alerts is upstream along the call chain; upstream services will also report delays due to timeouts. Error-type alerts characterize "failure to return a response," focusing on the result dimension. Error-type alert metrics include: HTTP 5xx / 4xx ratio, RPC exception rate, number of error log entries, and business status code failures. Error-type alerts can be triggered by scenarios such as: Null Pointer Exception (NPE), database deadlock, downstream 500 responses, and cache breakdown. The propagation characteristics of error-type alerts are that they can propagate across layers (retry or fail-fast), which can cause upstream tasks to also encounter errors, or they may be stopped by circuit breakers from spreading further. Resource types are used to characterize "capacity or underlying resource shortages," focusing on the system capacity dimension. Alert metrics for resource types include: CPU, memory, disk, file descriptors (FD), thread pool saturation, connection pool limit, etc. Resource-type alerts can be triggered by scenarios such as: memory leaks, sudden surges in traffic during promotional events, batch processing filling up disks, and host machine overselling. Regarding the propagation characteristics of resource-type alerts, they generally do not spread along the call chain, but they can indirectly lead to increased upstream latency / errors. Therefore, when locating the root cause, it is important to avoid treating resource types as ordinary "call exceptions" and continuing to propagate them downstream. Network types are used to characterize "reachability or transient quality anomalies between nodes," focusing on the link dimension. Network-related alert metrics include: Transmission Control Protocol (TCP) connection establishment failure, packet loss rate, Round-Trip Time (RTT) jitter, Domain Name System (DNS) resolution failure, and Service Mesh 503 UC (Upstream Connect Error). Network-related alert events can be triggered by scenarios such as: switch failure, Pod restart with IP address drift, firewall packet loss, and sidecar container not starting properly.The propagation characteristics of network-type alarm events are manifested as random or sudden call failures / delays, often accompanied by a sawtooth waveform of alternating "success-failure"; these can be quickly identified through the "no response" label of network probes or distributed tracing.

[0066] In this embodiment of the application, after classifying alarm events into four alarm types, root cause reasoning can be performed according to the "type-related" propagation rules. For example, alarm events of the delay type can continue to be scored up along the call chain, alarm events of the resource type only retain weight in the local node, and alarm events of the network type trigger short-term circuit breakers, thereby significantly reducing false alarms and false negatives.

[0067] The alarm intensity value maps the alarm level of the current alarm event to a numerical value between 0 and 1, representing the severity of the alarm event. For example, a P1 level alarm corresponds to an alarm intensity value of 1.0, a P2 level alarm corresponds to an alarm intensity value of 0.8, and so on. The alarm type and alarm intensity value form the basis for subsequent potential energy calculations.

[0068] In practice, after receiving a current alarm event from the microservice system, the electronic device first parses the current alarm event into structured data and then categorizes it into the corresponding channel (i.e., the processing channel corresponding to different alarm types) according to preset rules. The parsing and classification process of the current alarm event ensures that alarm events of different types can be correctly identified and propagated abnormally according to their respective impact paths, thereby avoiding false alarms caused by mistransmission of resource-related alarm events.

[0069] In some embodiments, see Figure 2 , Figure 2 The process of obtaining the alarm type and alarm intensity value of the current alarm event in step S101 is shown, which can be achieved through the following steps S1011 to S1012:

[0070] S1011, in response to obtaining the alarm information of the current alarm event, the type field in the alarm information with a preset format is parsed to obtain the alarm type of the current alarm event; and the level field in the alarm information is parsed to obtain the alarm level of the current alarm event.

[0071] In this embodiment of the application, the alarm information can be structured data, such as information in JSON or XML format. The alarm information contains multiple fields, which describe the details of the current alarm event.

[0072] In this embodiment, after receiving an alarm message, the electronic device first identifies whether the alarm message conforms to a preset format, i.e., whether it contains a type field and a level field. The type field is used to identify the specific category of the current alarm event corresponding to the alarm message, such as alarm types like delay, error, insufficient resources, or network problems; the level field is used to indicate the severity of the current alarm event corresponding to the alarm message, such as P1 (Critical), P2 (Major), etc. By parsing the type field and the level field, the electronic device can obtain the alarm type and alarm level of the current alarm event corresponding to the alarm message, respectively, thereby providing a clear classification basis for subsequent processing.

[0073] S1012, based on a preset mapping table, map the alarm level of the current alarm event to the alarm intensity value of the current alarm event.

[0074] While the alarm level of a current alarm event can express its severity, alarm levels are usually in discrete string form, making them difficult to directly participate in numerical calculations. Therefore, this application introduces a mapping table, which predefines the correspondence between alarm levels and corresponding alarm intensity values ​​for different alarm events. For example, alarm level P1 maps to alarm intensity value 1.0, alarm level P2 maps to alarm intensity value 0.8, and so on. By querying the mapping table, the electronic device can convert the parsed alarm level of the current alarm event into a standardized alarm intensity value, thereby facilitating the unified processing of alarm events of various alarm types and alarm levels.

[0075] In this embodiment, the received alarm information is parsed, and a preset mapping table is used to convert the alarm level of the current alarm event into a calculable alarm intensity value. This process ensures accurate classification and quantification of alarm information, thereby supporting more efficient root cause localization algorithms and improving the real-time performance and accuracy of fault diagnosis.

[0076] S102, Based on the alarm intensity value, generate the alarm source vector under the alarm type; each element in the alarm source vector corresponds to a node in the service dependency graph under the alarm type.

[0077] After determining the alarm type and alarm intensity value, the electronic device constructs a sparse vector, called the alarm source vector. The length of the alarm source vector is equal to the number of nodes in the service dependency graph. Each element in the alarm source vector represents whether a node in the service dependency graph has generated an alarm and the alarm intensity value. For nodes that have not generated an alarm, the corresponding position in the alarm source vector is 0; for nodes that have generated an alarm, the electronic device assigns the corresponding alarm intensity value to the corresponding position in the alarm source vector. This vector form allows the electronic device to efficiently represent alarm information in large-scale topologies and provides input for subsequent potential propagation.

[0078] In practical implementation, the construction of alarm source vectors is a crucial step for rapid completion during the online phase. Since most nodes do not generate alarms simultaneously, alarm source vectors are typically highly sparse. This characteristic of highly sparse alarm source vectors helps reduce memory usage and computational overhead.

[0079] In some embodiments, if multiple alarm events occur repeatedly within a short period of time on the same node in the same type of channel (e.g., a delay-type channel), the electronic device will adopt a strategy of retaining the maximum value and write the maximum alarm intensity value of the multiple alarm events to the corresponding position in the alarm source vector, thereby preventing duplicate counting from affecting the accuracy of the results.

[0080] In some embodiments, see Figure 3 , Figure 3 The process of generating alarm source vectors under alarm types in step S102 is shown, which can be achieved through the following steps S1021 to S1023:

[0081] S1021, parse the node identifier field in the alarm information to obtain the node identifier of the alarm node corresponding to the current alarm event.

[0082] Alarm information refers to abnormal data collected and sent by a microservice system. It typically contains multiple fields, such as timestamp, node identifier (i.e., service instance identifier nodeID), metric name, and alarm level. The node identifier field uniquely identifies the service instance or node that triggered the alarm, and it is crucial for locating the service entity corresponding to the alarm. By parsing the node identifier field in the alarm information, the specific node ID that triggered the alarm can be extracted, providing input for subsequent processing.

[0083] In this embodiment of the application, by parsing the node identifier field in the alarm information, the node where the current alarm event occurred can be accurately identified, thereby ensuring that subsequent operations are carried out based on the correct service instance, and thus improving the accuracy of the fault root cause localization process.

[0084] S1022, Based on the number of nodes in the service dependency graph, construct a sparse vector corresponding to the alarm type; the dimension of the sparse vector is equal to the number of nodes, and each element in the sparse vector corresponds to a node in the service dependency graph.

[0085] A service dependency graph refers to the call relationship diagram between services in a microservice architecture. It is usually represented as a directed graph, where each node represents a service instance in the service dependency graph, and the edges represent the call relationships between services. The service dependency graph mentioned in this application embodiment includes the original service dependency graph and channel-oriented diffusion graphs generated from the original service dependency graph under different alarm types.

[0086] like Figure 4 The diagram shown is the original service dependency graph provided in the embodiments of this application. Figure 4 The original service dependency graph shown includes four service instances: a user gateway instance, a business aggregation instance, a payment service instance, and a bill storage instance. The user gateway instance calls the business aggregation instance and the payment service instance; the business aggregation instance calls the payment service instance; and the payment service instance calls the bill storage instance. In this embodiment, each edge in the original service dependency graph has a weight, which is the original weight between each pair of connected nodes in the original service dependency graph. This weight can be a preset value. In subsequent channel-oriented diffusion graphs generated for each alarm type, the target weight of the edge between each pair of connected nodes in the original service dependency graph under different alarm types is calculated. This target weight is used as a quantitative indicator to characterize the degree of influence of the edge between each pair of connected nodes in the service dependency graph under different alarm types. This quantitative indicator reflects the relative importance of the edge corresponding to the target weight in anomaly diffusion. It should be noted that the channel-oriented diffusion graph here is the service dependency graph under different alarm types, that is, the diffusion graph obtained after calculating the target weight of the original service dependency graph under different alarm type channels.

[0087] like Figure 5 The diagram shown illustrates a channel-directed diffusion graph for different alarm types, as provided in this embodiment. In this graph, the weight of each edge represents the degree of influence of the two nodes on that edge under the given latency type. It should be noted that in the original service dependency graph and in the channel-directed diffusion graphs for different alarm types generated based on the original service dependency graph, the type and number of service instances are the same (i.e., the type and number of nodes are the same), and the calling relationships between different service instances are also the same. In other words, the original service dependency graph and the channel-directed diffusion graphs for different alarm types generated based on the original service dependency graph have the same structure. The nodes in the service dependency graph described in this embodiment refer to the nodes in the channel-directed diffusion graph for the corresponding alarm type.

[0088] Sparse vectors are an efficient mathematical structure. The length of a sparse vector equals the number of nodes in the service dependency graph, but only a few positions have non-zero values, while the rest are zero (i.e., since alarm events typically do not occur on a large number of services within the same time period, only the positions of the few nodes where alarms occurred have non-zero values). In this embodiment, a sparse vector corresponding to each alarm type is constructed. Sparse vectors are suitable for describing the distribution of alarm information in the service topology represented by the service dependency graph, because most nodes do not trigger alarms at any given time. By mapping alarm information to sparse vectors, it is possible to efficiently represent which nodes triggered alarms and assign corresponding alarm intensity values ​​to the sparse vectors.

[0089] In this embodiment, by constructing sparse vectors corresponding to alarm types, the distribution of alarm information in the service dependency graph can be efficiently represented. The method in this embodiment avoids unnecessary storage and computational overhead, while ensuring accurate representation of alarm information.

[0090] S1023, based on the node identifier, write the alarm intensity value into the element position corresponding to the alarm node in the sparse vector to obtain the alarm source vector under the alarm type.

[0091] Alarm intensity value is a quantitative representation of alarm severity, typically linearly mapping the original alarm level (e.g., P1, P2, etc.) to a continuous value between 0 and 1. Electronic devices write the alarm intensity value into the corresponding node position in a sparse vector corresponding to the alarm type, thereby generating a complete alarm source vector for that alarm type. The alarm source vector not only reflects which nodes triggered alarms but also the relative severity of these alarms, providing fundamental input for subsequent anomaly propagation calculations and root cause localization. This embodiment of the application, by writing the alarm intensity value into the corresponding node position in a sparse vector corresponding to the alarm type, can generate a high-precision alarm source vector, providing reliable data support for subsequent anomaly propagation modeling and root cause determination processes.

[0092] In this embodiment, by parsing the node identifier field in the alarm information, a sparse vector corresponding to the service dependency graph is constructed, and the alarm intensity value is written into the corresponding position in the sparse vector, thereby generating an alarm source vector. Through this method, accurate location and efficient representation of alarm events can be achieved, thereby reducing computational complexity and improving the real-time performance and accuracy of the root cause localization process.

[0093] In summary, in practical implementation, this embodiment first identifies the specific node that triggered the alarm by parsing the node identifier field in the alarm information. Next, a sparse vector is constructed based on the service dependency graph, representing the alarm distribution within the service topology represented by the entire service dependency graph. Finally, the alarm intensity value is written into the corresponding node position in the sparse vector, forming the final alarm source vector. This achieves efficient modeling and representation of alarm events, providing a clear and computable data structure for subsequent root cause analysis.

[0094] S103, taking the node corresponding to each non-zero element in the alarm source vector as the first parent node, and querying the attenuation coefficient from the first parent node to the first child node from the preset diffusion coefficient table.

[0095] Here, the first child node is a child node at least one level connected to the first parent node. After obtaining the alarm source vector, the electronic device searches for the adjacent nodes of each non-zero element in the service dependency graph and obtains the corresponding attenuation coefficient from a pre-built diffusion coefficient table. The diffusion coefficient table is obtained offline by solving the local matrix within the k-hop neighborhood. The diffusion coefficient table records the proportion of abnormal energy propagated by the first parent node to the first child node at least one level connected to it. For example, if node A, as the parent node, propagates an anomaly to node B, an attenuation coefficient α can be obtained through a table lookup operation. This attenuation coefficient α indicates what proportion of the abnormal energy of node A will be transmitted to node B. It should be noted that the first child node at least one level is connected in series with the first parent node. For example, suppose the number of levels of the first child node connected to the first parent node is 3, where the first parent node is node A; the first child node of the first level connected to node A is node B; the first child node of the second level connected to node A is node C; node C is connected to node B, and node C is a child node of node B; the first child node of the third level connected to node A is node D; node D is connected to node C, and node D is a child node of node C.

[0096] In practical implementation, the attenuation coefficient is obtained by looking up a table, avoiding complex matrix operations during the online phase, thus achieving millisecond-level response speeds. This table-based approach not only improves computational efficiency but also reduces hardware resource requirements, making it suitable for deployment on edge nodes or low-power devices.

[0097] S104. Based on the alarm intensity value of the first parent node and the attenuation coefficient of the first child node at each level, determine the potential energy of each node in the service dependency graph.

[0098] After obtaining the alarm intensity value of the first parent node and the attenuation coefficient of the first child node, the electronic device begins to calculate the propagation of abnormal energy. Specifically, it multiplies the alarm intensity value of the first parent node by the corresponding attenuation coefficient to obtain the potential energy increment flowing to the first child node, and accumulates this potential energy increment in the potential energy bucket of the first child node. This process iterates layer by layer until a preset propagation level is reached (usually 2 or 3 hops). Finally, the electronic device calculates a total potential energy for each node, which is used to measure how much abnormal energy the node has at the current moment.

[0099] In practice, the propagation of potential energy follows the principle of potential conservation, meaning the total inflow of abnormal energy should equal the total outflow. Based on this principle, electronic devices can accurately simulate the propagation path of anomalies in the service dependency graph and provide fundamental data for subsequent responsibility calculations.

[0100] In some embodiments, see Figure 6 , Figure 6 The process of determining the potential energy of each node in step S104 is shown, which can be achieved through the following steps S1041 to S1043:

[0101] S1041, the alarm intensity value of the first parent node is determined as the potential energy of the first parent node; and the alarm intensity value of the first child node at each level is determined as the initial potential energy of the first child node.

[0102] Alarm intensity value refers to a continuous numerical value between 0 and 1 mapped from the original alarm level (such as P1, P2, etc.), used to represent the severity of the anomaly on a node. For example, P1 / Critical is mapped to 1.0, P2 / Major to 0.8, and so on. The higher the alarm intensity value, the stronger the abnormal energy carried by the node corresponding to the alarm intensity value. In the embodiments of this application, the alarm intensity value is directly used as the basic input for potential energy calculation to initialize the energy distribution of the node.

[0103] Initial potential energy refers to the original energy value of a child node without considering the influence of its parent node. The initial potential energy is equal to the alarm intensity value of the first child node itself. Treating the alarm intensity values ​​of each first child node independently as initial potential energy avoids premature merging or dilution of the original abnormal signals due to the influence of the parent node, thus preserving the independent contribution of each node. This ensures that the abnormal energy of each node has a clear starting point and basic magnitude before propagation, enabling it to accurately participate in the subsequent potential energy superposition and propagation process, thereby improving the accuracy and robustness of root cause localization.

[0104] S1042, the incremental potential energy of the first child node is determined by multiplying the alarm intensity value of the first parent node with the attenuation coefficient of the first child node at each level.

[0105] The attenuation coefficient refers to the proportion of anomalous energy that decreases as it propagates from the first parent node to the first child node in a service dependency graph. The attenuation coefficient depends on the local structure of the edge weight matrix W and the Laplacian matrix L. Specifically, the attenuation coefficient reflects the proportion of loss when a unit of anomalous energy is transmitted from the first parent node to a first child node under the current topology of the service dependency graph. The attenuation coefficient is typically less than 1, and it may vary on different paths to reflect differences in the importance of the call chain.

[0106] Incremental potential energy refers to the additional energy transferred from the anomalous energy of the first parent node to the first child node after attenuation. The additional energy gained by the first child node due to the anomalous energy of the first parent node is quantified by multiplying the alarm intensity value of the first parent node by the attenuation coefficient from the first parent node to the first child node. For the first child node, this embodiment considers not only the intensity of the anomaly source but also the weight and characteristics of the propagation path, thus more realistically simulating the diffusion process of the anomaly in the service dependency graph. By introducing an attenuation mechanism and multi-hop propagation modeling, multi-hop propagation modeling of anomalous energy can be achieved, enabling the first child node to perceive the impact of anomalies from upstream nodes and thus identify potential root cause nodes. Simultaneously, the introduction of an attenuation mechanism prevents the unlimited propagation of anomalous energy and improves the stability and interpretability of the microservice system.

[0107] S1043, for each first child node, the sum of the initial potential energy and the incremental potential energy is determined as the potential energy of the first child node.

[0108] Potential energy refers to the total abnormal energy accumulated by each node in the service dependency graph. Potential energy consists of two parts: one part is the alarm intensity value of the first child node itself (i.e., the initial potential energy), and the other part is the incremental potential energy brought about by the propagation of abnormal energy from the first parent node. By adding these two parts, the overall abnormal state of the first child node at the current moment can be obtained.

[0109] The method of calculating potential energy ensures that the energy of each node includes both direct anomaly information of that node and indirect impact information from upstream nodes (which can be one or more) in the service dependency graph. This design ensures that a node in the service dependency graph is either severely anomaly-prone or the primary source of the anomaly. By sorting the potential energy of all nodes, the most likely root cause node can be quickly identified. Through a comprehensive calculation method of potential energy, dynamic superposition and propagation modeling of anomaly energy can be achieved, thus more comprehensively reflecting the anomaly distribution throughout the service dependency graph. Using this comprehensive potential energy calculation method, the root cause node that truly causes the failure can be effectively distinguished from merely affected downstream nodes, improving the accuracy of root cause localization.

[0110] In this embodiment, the alarm intensity value of the first parent node is determined as the potential energy of the first parent node and the initial potential energy of the first child node, respectively. The incremental potential energy of the first child node is calculated by combining the alarm intensity value of the first parent node with the attenuation coefficient of the first child node. Finally, the initial potential energy and the incremental potential energy are added together to obtain the final potential energy of the first child node. This method enables accurate propagation modeling of abnormal energy, identifies the main sources of abnormal energy, and improves the accuracy and real-time performance of root cause localization.

[0111] In summary, through steps S1041 to S1043, a layer-by-layer propagation model of abnormal energy in the service dependency graph is achieved, ensuring that the potential energy of each node fully reflects its own abnormal state and the influence of its upstream nodes. Furthermore, employing a reasonable potential energy calculation method can improve the efficiency and reliability of root cause localization.

[0112] S105, based on the potential energy of each node in the service dependency graph, locate the root cause node of the current alarm event in the service dependency graph.

[0113] In this embodiment, after calculating the potential energy of all nodes, the Intrinsic Responsibility Score (IRS) of each node is further calculated. This IRS represents the percentage of abnormal energy retained by each node within itself and its direct downstream nodes. A higher IRS score indicates a higher likelihood of the fault being the root cause. The IRS scores of all nodes can be sorted, and nodes with IRS scores above a set threshold (e.g., 0.6) or those ranked highly are selected as root cause candidates. Finally, a high-confidence root cause list is output for maintenance personnel to reference or to trigger automated repair operations.

[0114] In practical implementation, the calculation of responsibility levels effectively distinguishes the true source of the fault from the affected nodes, thereby reducing false alarms and missed alarms. Furthermore, it supports double exponential decay smoothing to suppress the impact of transient glitches and ensure the stability and reliability of the output results.

[0115] The root cause localization method provided in this application significantly improves the accuracy and real-time performance of root cause localization by classifying alarm types, constructing a multi-channel influence field model, and utilizing a preset diffusion coefficient table to achieve rapid anomaly propagation. Furthermore, the introduction of accountability and a self-checking mechanism enhances the interpretability and long-term stability of the root cause localization process, making it suitable for fault diagnosis scenarios in large-scale cloud-native service systems.

[0116] In some embodiments, see Figure 7 , Figure 7 The process of locating the root cause node of the current alarm event in step S105 is shown, which can be achieved through the following steps S1051 to S1054:

[0117] S1051, for each node in the service dependency graph, obtain the potential energy of the node under each alarm type at the current time and the channel weight corresponding to each alarm type.

[0118] In this embodiment, by distinguishing alarm events of different alarm types (such as delay, error, resource, network, etc.), an independent propagation path and diffusion mechanism are defined for each alarm type, and the potential energy of alarm events of different alarm types at each node in the service dependency graph is calculated. This allows for more accurate identification of the source of the anomaly, avoids mistransmission or masking between alarm events of different alarm types, thereby improving the accuracy and reliability of fault location and enabling rapid closed-loop processing. Alarm type refers to a category classified according to the anomaly's manifestation, such as delay, error, resource, network, etc. Different alarm types have different propagation characteristics. For example, the propagation path of delay alarms typically spreads upstream along the call chain, while the propagation path of resource alarms is mainly limited to the current node. Therefore, when calculating the potential energy, each alarm type must be modeled separately to ensure that the propagation path is consistent with the actual behavior.

[0119] Potential energy refers to the abnormal energy value carried by each node at a certain moment in the potential conservation model. The value of potential energy is determined by the cumulative result of the alarm intensity values ​​injected into the node after propagation. The higher the potential energy within a certain period, the more likely the node carrying the abnormal energy value at that moment is an abnormal accumulation point, i.e., a possible root cause node. Channel weights are used to describe the degree of influence of different alarm types on root cause determination. For example, delay and error alarms usually have higher channel weights for root cause determination, while resource alarms may have lower channel weights; that is, the channel weights of delay and error alarms are greater than those of resource alarms. By weighted summing of the potential energy of different channels, a comprehensive total potential energy index can be obtained, which facilitates subsequent responsibility calculation.

[0120] S1052, based on the channel weight, the potential energy of multiple alarm types is weighted and summed to obtain the total potential energy of the node.

[0121] In this embodiment, by linearly fusing the potential energy of alarm events of various alarm types at each node according to preset channel weights, a comprehensive potential energy index reflecting the overall abnormal state of the node can be generated. This method can effectively integrate the information of alarm events of different alarm types and avoid the one-sided influence of a single alarm type. This comprehensive potential energy index method can improve the robustness and accuracy of root cause localization, thereby supporting fault diagnosis in more complex scenarios.

[0122] Weighted summation is a mathematical operation that assigns different weight coefficients to different input items and then sums them to obtain a comprehensive output. In this embodiment, the potential energy of each alarm event of each alarm type at each node can be multiplied by the channel weight corresponding to that alarm type and then summed to calculate the total potential energy of the node currently being processed. This weighted summation method can flexibly adjust the influence ratio of various alarm events on the final result, enhancing the adaptability of the microservice system. The total potential energy is the result of weighted summation of the potential energy of multiple alarm types through channel weights, representing the overall abnormality of the node under all alarm types. The total potential energy is the basis for subsequent responsibility calculations and determines the relative importance of the node in the service dependency graph.

[0123] In practice, there are significant differences in the propagation patterns between alarm types. For example, delayed alarms tend to propagate upwards, while resource alarms tend to remain local. Therefore, when performing weighted summation, the propagation characteristics between alarm types should be considered to influence the weight allocation, ensuring that the calculation of the total potential energy more closely reflects reality.

[0124] In some embodiments, the total potential energy of a node in step S1052, which involves weighted summation of potential energy under multiple alarm types based on channel weights, can be achieved as follows: First, the potential energy under each alarm type is smoothed to obtain smoothed potential energy; then, the smoothed potential energy under multiple alarm types is weighted and summed based on channel weights to obtain the total potential energy of the node.

[0125] Here, smoothing is used to suppress the impact of instantaneous jitter or spikes on the potential energy calculation results. Since the monitored abnormal data has certain noise characteristics, such as a high value appearing once in a short period of time, it may only be an occasional event and cannot truly reflect the changing trend of the system state. Therefore, a smoothing mechanism is introduced to make the potential energy changes more stable and reliable.

[0126] In practical implementation, smoothing can be achieved using an Exponential Moving Average (EMA), maintaining two time windows: a fast window and a slow window. The fast window is used for rapid response to sudden anomalies, while the slow window is used to capture long-term trends. Electronic devices then merge the fast and slow windows in a certain proportion to generate a smooth potential value that is both sensitive and stable.

[0127] In some embodiments, see Figure 8 , Figure 8 This application embodiment demonstrates the smoothing of potential energy for each alarm type, which can be achieved through the following steps S201 to S204:

[0128] S201, for each alarm type, obtain the first potential energy of the node in the first time window before the current time and the second potential energy in the second time window; the window length of the first time window is less than the window length of the second time window.

[0129] The first and second time windows are used to collect potential energy data from different time periods, respectively, for subsequent double exponential decay smoothing processing. The first time window is typically shorter, such as potential energy data within the most recent minute, used to capture rapidly changing trends; while the second time window is longer, such as potential energy data within the most recent five minutes, used to reflect the stability of the trend. By combining data from these two different time scales, the trajectory of abnormal energy changes can be assessed more accurately, avoiding interference from instantaneous fluctuations in the judgment.

[0130] In practical applications, electronic devices trace back to two time windows based on the current timestamp, extracting the potential energy values ​​of nodes under each window. This multi-window mechanism provides more comprehensive contextual information, helping electronic devices better distinguish between brief jitters and persistent anomalies.

[0131] S202, based on the first potential energy and the node's potential energy at the current moment, determine the node's third potential energy within the first time window including the current moment.

[0132] The third potential energy is a linear combination of the potential energy of the current node at the latest moment within the first time window and the first potential energy, used to describe the dynamic changes of the node within the short-term window. Specifically, the third potential energy can be calculated using a weighted average method, such as the exponential moving average method. In this method, the potential energy at the current moment has a greater impact on the overall result and can more effectively reflect the real-time changes of the microservice system.

[0133] During implementation, the electronic device calculates the third potential energy based on the current potential energy and the first potential energy, combined with a preset weighting coefficient (e.g., α=0.6). This calculation method enhances the microservice system's response speed to new anomalies while reducing the influence of old data and improving the sensitivity of judgment.

[0134] S203, based on the second potential energy and the node's potential energy at the current moment, determine the node's fourth potential energy within the second time window including the current moment.

[0135] The fourth potential energy is a linear combination of the current node's potential energy at the latest moment within the second time window and the second potential energy, used to describe the node's trend change within the long-term window. Similarly, the fourth potential energy can also be calculated using the exponential moving average method, but the weighting coefficient corresponding to the fourth potential energy is usually smaller than that corresponding to the third potential energy (e.g., β=0.2) to highlight the stability of the long-term trend. By calculating the fourth potential energy, electronic devices can filter out short-term noise to a certain extent, focusing on identifying anomalies with lasting impact. This method of calculating the fourth potential energy and filtering out short-term noise to focus on identifying anomalies with lasting impact is crucial for avoiding false alarms and missed alarms, ensuring that only truly noteworthy fault signals are considered in high-frequency monitoring scenarios.

[0136] S204, the third potential energy and the fourth potential energy are merged to obtain the smooth potential energy of the node.

[0137] Smoothing potential energy is the result of weighted fusion of the third and fourth potential energies in a certain proportion. The purpose of smoothing potential energy is to synthesize short-term and long-term potential energy changes to form a more robust potential energy representation. Smoothing potential energy reflects the comprehensive anomaly level of a node after considering historical trends and the current state. Compared to historical potential energy, smoothing potential energy better reflects the true system behavior and helps improve the stability and accuracy of root cause localization. The calculation process of smoothing potential energy can be implemented using a double exponential decay smoothing method. The introduction of smoothing potential energy can effectively reduce the bias that may be caused by a single time window and improve the robustness of anomaly detection. Smoothing potential energy not only retains the sensitivity to short-term anomalies but also avoids misjudgments caused by random fluctuations, making the final root cause analysis more accurate and reliable.

[0138] In this embodiment, multiple time windows are set and combined with a double exponential decay smoothing method to refine the node potential energy. By setting multiple time windows and combining them with the double exponential decay smoothing method to refine the node potential energy, transient glitches can be effectively suppressed, allowing electronic devices to focus on true abnormal trends, thereby improving the accuracy of root cause analysis and ultimately enhancing fault location efficiency and the level of operation and maintenance automation.

[0139] In summary, in practical implementation, steps S201 to S204 are closely interconnected and work together to form a potential energy processing flow based on a multi-time window and smooth fusion mechanism. First, two time windows of different durations are set to obtain the first and second potential energies, used to characterize short-term changes and long-term trends, respectively. Next, the current potential energy is weighted and calculated with historical potential energies to generate the third and fourth potential energies, further updating the behavioral characteristics of nodes at different time scales. Finally, the two are fused into a smooth potential energy, serving as an important basis for subsequent root cause analysis. This potential energy processing flow based on the multi-time window and smooth fusion mechanism not only improves the electronic device's ability to perceive complex anomalies but also enhances the stability and reliability of the overall diagnostic process.

[0140] Regarding the smoothing of potential energy for each alarm type, for example, in a cloud-native service system, if a node in the system suddenly experiences a latency-related alarm, the node's initial potential energy might rise rapidly. However, since the nodes in the cloud-native service system have been operating normally recently, the sudden increase in initial potential energy is likely due to an anomaly caused by a single, accidental request, rather than a systemic failure. In this case, smoothing reduces the contribution of this accidental request-induced anomaly to the node's potential energy, thus avoiding misjudgment.

[0141] S1053. Based on the total potential energy of each node in the service dependency graph and the connection relationship between nodes, determine the responsibility of each node.

[0142] In this embodiment, the responsibility level of each node is calculated by combining the total potential energy of the node with its topological structure in the service dependency graph, thereby quantifying the likelihood of the node being a root cause. This approach enables an objective assessment of root cause nodes, rather than relying solely on the magnitude of their potential energy. This improves the interpretability and reliability of root cause localization, reduces manual intervention, and enhances the efficiency of automated operations and maintenance.

[0143] Responsibility is a metric that measures the proportion of anomalous potential energy retained by a node between that node and its immediate downstream nodes. A higher responsibility level indicates that the node is more likely to be the true root cause, because nodes with high responsibility retain more anomalous energy rather than passing it on to downstream nodes. Responsibility is not related to the number of alarm events; it relies solely on the law of conservation of energy, thus possessing strong physical significance and explanatory power.

[0144] The connections in a service dependency graph reflect the calling or dependency logic between services, and these relationships determine how exception energy flows between nodes. When calculating responsibility, the connections between a node in the service dependency graph and its direct downstream nodes need to be considered to determine whether the exception was caused by the node itself or propagated from an upstream node. In practice, the connections in the service dependency graph not only determine the direction of exception propagation but also affect the distribution of responsibility. For example, in a service dependency graph, if a node has many downstream nodes, its responsibility may be higher because this node is more likely to be the source of the exception.

[0145] In some embodiments, determining the responsibility of each node in step S1053 based on the total potential energy of each node in the service dependency graph and the connection relationships between nodes can be achieved as follows: First, for each node in the service dependency graph, taking that node as the second parent node, determine at least one level of second child nodes connected to the second parent node based on the connection relationships. Then, determine the sum of the total potential energy of the at least one level of second child nodes. Finally, determine the responsibility of the node based on its total potential energy and the sum of its total potential energy.

[0146] Here, the second parent node refers to the node currently being processed, and it is considered as an upstream node in the service dependency graph. The second child node refers to a downstream node that is directly or indirectly connected to the second parent node through a call chain or dependency relationship. A second child node at least one level can be a child node with one hop (direct connection), two hops (intermediate node), or more hops, depending on the topology of the service dependency graph. This method of determination allows identification of all potential downstream nodes affected by the current node, thus enabling a more comprehensive assessment of the current node's role in the entire anomaly propagation process.

[0147] In practice, there is a clear contextual call relationship or dependency relationship between the second parent node and the second child node. These relationships are usually manifested as service calls, data flow transmission, or functional dependencies. For example, in a microservice architecture, a payment service might be a child node of the order service, and the inventory service might be a child node of the payment service. In this case, the inventory service is defined as the second child node.

[0148] The total potential energy sum refers to the sum of the accumulated anomaly energy (i.e., the total potential energy of each node) across all second-child nodes. Total potential energy reflects the degree of anomaly propagation in the service dependency graph, while the total potential energy sum measures the overall impact of anomalies initiated or propagated by the current node on downstream nodes. Calculating the total potential energy sum is helpful for subsequent responsibility assessment because it provides information on the total amount of impact on downstream nodes.

[0149] In practical implementation, the total potential energy can be calculated by summing the anomaly detection results of each second child node. Specifically, electronic devices can collect indicators such as service latency, error rate, and throughput, and combine these indicators with a preset anomaly weight model. Based on this combination relationship, the indicators are converted into potential energy values ​​for each child node, and finally, the potential energy values ​​of all child nodes are summed.

[0150] Responsibility measure is used to assess the proportion of anomalous energy a node retains within itself and its downstream nodes. Specifically, a higher responsibility level indicates that a node is more likely to be the root cause. By comparing the total potential energy of the current node with the sum of the total potential energy of its downstream nodes, it is possible to quantitatively assess whether the current node tends to retain anomalous energy rather than pass it on to downstream nodes. The method for calculating responsibility not only improves the accuracy of root cause localization but also enhances the interpretability of the root cause localization process.

[0151] In this embodiment, the current node is considered as the second parent node, and the downstream second child nodes of the current node are identified based on the connection relationship of the service dependency graph. The sum of the total potential energy of these child nodes is then calculated to determine the responsibility level of the current node. By treating the current node as the second parent node and identifying the downstream second child nodes based on the connection relationship of the service dependency graph, the distribution of abnormal energy can be determined more accurately, thereby distinguishing the node that truly caused the fault and improving the accuracy and response speed of root cause localization.

[0152] In practical implementation, the steps in the entire process of determining node responsibility are closely linked, forming a closed-loop feedback mechanism. First, by identifying the second parent node and its second child node, a local influence range is constructed. Next, the sum of the total potential energy within the local influence range is calculated, and this value is used as a quantitative basis for the anomaly propagation intensity. Finally, combined with the total potential energy of the current node itself, the responsibility level is comprehensively calculated, thereby achieving accurate location of the root cause node. The method of this application embodiment fully utilizes the topological structure characteristics of the service dependency graph, achieving high efficiency and accuracy in anomaly tracing. Therefore, this application embodiment can quickly identify and locate the root cause node in a complex service call environment, effectively supporting maintenance personnel in troubleshooting and repair.

[0153] S1054, Based on the degree of responsibility, locate the root cause node of the current alarm event from the service dependency graph.

[0154] In this embodiment, by sorting and filtering nodes with a responsibility level higher than a set threshold, the root cause node most likely to cause the current alarm event can be efficiently identified. This process enables rapid identification of the root cause of the fault, avoids ineffective troubleshooting, shortens fault repair time, reduces the risk of business interruption, and improves user satisfaction.

[0155] A root cause node is a service node in the service dependency graph that is the root cause of the current alarm event. Root cause nodes are usually the starting point of an anomaly, and anomalies in other nodes may be caused by the root cause node. By ranking responsibility and filtering by thresholds, this critical node can be accurately identified, providing a basis for subsequent alarm folding and self-healing operations.

[0156] In summary, this embodiment first analyzes the propagation characteristics of different alarm types to obtain the potential energy and channel weights of each node under various alarm types; then, it generates the total potential energy through weighted summation; next, it calculates the responsibility degree of each node by combining the connection relationship of the service dependency graph; finally, it determines the root cause node by ranking the responsibility degree. The entire process forms a closed-loop root cause localization mechanism, which can achieve efficient and accurate fault diagnosis in complex service architectures.

[0157] In the specific implementation process, the process of locating the root cause node of the current alarm event from the service dependency graph based on the degree of responsibility in step S1054 can be implemented in the following way: First, sort the nodes in the service dependency graph in descending order of the degree of responsibility to form a node sequence; then, determine the first N nodes in the node sequence as the root cause node of the current alarm event; N is an integer greater than 0; or, determine the nodes with a degree of responsibility greater than a preset degree of responsibility threshold as the root cause node of the current alarm event.

[0158] Here, the node sequence is constructed by traversing all nodes in the service dependency graph and sorting them according to the responsibility value of each node. For example, in a service topology containing hundreds of nodes, a list of nodes arranged from highest to lowest responsibility can be quickly generated. In this embodiment, by sorting nodes according to responsibility, the nodes most likely to cause the current alarm event can be effectively identified, thereby improving the accuracy and efficiency of root cause localization, quickly narrowing the scope of investigation, and enabling faster fault repair or self-healing operations.

[0159] The top N nodes in the sorted node sequence are selected as root cause candidates. N is a configurable parameter, for example, it can be 3 or 5. The reason for selecting the top N nodes as root cause candidates is that the top N nodes have the highest degree of responsibility, which means that the top N nodes have accumulated the most anomalous energy during the anomaly propagation process, and therefore the top N nodes are most likely the source of the fault. For example, in a real-world scenario, if N equals 3, the three nodes with the highest degree of responsibility are marked as root causes, and these three nodes are submitted to operations personnel or automated processing procedures.

[0160] In some embodiments, a preset responsibility threshold may be introduced. A dynamic screening mechanism uses this threshold to determine which nodes have sufficiently high responsibility to be considered potential root causes. The preset responsibility threshold can be set based on historical data or experience, for example, 0.6. Only when a node's responsibility exceeds this value will it be considered a root cause candidate.

[0161] This screening method, which introduces a preset responsibility threshold, allows electronic devices to flexibly adjust the criteria for root cause screening when faced with alarm scenarios of varying complexity. For example, in certain business scenarios with high reliability requirements, electronic devices can appropriately increase the preset responsibility threshold to ensure that only highly probable root cause nodes are considered; while in other scenarios, electronic devices can appropriately decrease the preset responsibility threshold to broaden the scope of investigation.

[0162] In practice, there is a close relationship between the preset responsibility threshold set by the electronic device and the responsibility level of the nodes. Only when the responsibility level of a node exceeds the preset responsibility threshold will the node be determined as a valid root cause candidate. Therefore, by setting a preset responsibility threshold as a screening mechanism for responsibility, the root cause candidate set can be further optimized and refined.

[0163] In this embodiment, by sorting nodes according to their level of responsibility and selecting the top N nodes or nodes with a level of responsibility higher than a preset threshold as root cause nodes, this method can effectively identify high-confidence root causes. By employing this method, the accuracy of root cause localization can be improved, thereby accelerating the fault diagnosis and handling process and further enhancing the stability and reliability of the microservice system.

[0164] In summary, by leveraging the synergistic effects of the steps described above to pinpoint the root cause of the current alarm event, an efficient root cause localization mechanism can be achieved. Specifically, firstly, the responsibility level of each node is calculated and sorted to form a node sequence; then, the most likely root cause node is selected based on a preset N value or responsibility level threshold. Throughout the entire process, responsibility level serves as the core indicator, guiding the identification and localization of the root cause, making the root cause localization process more scientific, accurate, and efficient. In practical implementation, the root cause localization mechanism can quickly pinpoint the source of failure in complex microservice architectures, significantly improving the intelligence level of operations and maintenance.

[0165] The diffusion coefficient table in this application embodiment can be pre-generated offline. This diffusion coefficient table can be pre-generated before querying the attenuation coefficient from the first parent node to the first child node from a preset diffusion coefficient table. This application embodiment further provides a method for generating the diffusion coefficient table offline, such as... Figure 9 As shown, the process of generating the diffusion coefficient table includes the following steps S301 to S306:

[0166] S301, determine the call frequency and latency parameters between each pair of connected nodes in the service dependency graph.

[0167] Call frequency refers to the number of calls between two services within a certain time frame, usually expressed as the number of requests per unit time, reflecting the activity level and interaction intensity between services. Latency parameter refers to the average response time or the response time at a specific quantile (e.g., P95) required for a single call, used to measure the efficiency and stability of service calls. Call frequency and latency parameter together constitute a quantitative description of the communication characteristics between services and provide basic data support for subsequent weight calculations. This application's embodiments, by obtaining call frequency and latency parameters, can more accurately assess the dependencies between services and anomaly propagation paths, thereby improving the accuracy of root cause localization.

[0168] S302, based on the call frequency and latency parameters, determine the target weight of the edge between each two connected nodes in the service dependency graph under different alarm types.

[0169] Target weight is a quantifiable indicator of the impact of an edge between any two connected nodes in the service dependency graph under different alarm types, reflecting the relative importance of the edge corresponding to the target weight in the anomaly propagation. For example, in delay-type alarms, the target weight might be calculated by multiplying the call frequency by the reciprocal of the delay; while in resource-type alarms, since the anomaly does not propagate along the call chain, the target weight is set to 0. This differentiated approach ensures that the impact range of different alarm types conforms to the physical propagation mechanism of different alarm types, thereby avoiding misjudgments.

[0170] In this embodiment, determining the target weight of the edge between every two connected nodes in the service dependency graph under different alarm types can be achieved as follows: First, based on the call frequency and latency parameters, the original weight of the edge between every two connected nodes is determined; then, the original weight of each edge in the service dependency graph is normalized to obtain the normalized weight of each edge; finally, based on the normalized weight, the target weight of each edge under different alarm types is determined. Setting the target weight can effectively distinguish the propagation behavior of different types of alarms, thereby optimizing the accuracy of the anomaly propagation model and reducing the possibility of incorrect localization.

[0171] S303 generates a weight matrix for each alarm type based on the target weight of each edge in the service dependency graph under different alarm types.

[0172] The weight matrix is ​​a sparse matrix used to describe the connection strength of all edges in the service dependency graph under a given alarm type. Each element of the weight matrix represents the target weight of an edge, and the rows and columns correspond to the nodes in the service dependency graph corresponding to the weight matrix. By constructing the weight matrix, the impact of different alarm types can be independently modeled, providing input for the subsequent construction of the Laplace matrix.

[0173] The generation of the weight matrix enables a structured representation of the service dependency graph, allowing each alarm type to be modeled independently on a unified topology, thus improving the flexibility and scalability of the root cause localization process.

[0174] S304. For each alarm type, generate the Laplace matrix for that alarm type based on the weight matrix for that alarm type.

[0175] In this embodiment of the application, a Laplace matrix for the alarm type is generated based on the weight matrix for that alarm type. Specifically, this can be achieved by: determining the out-degree diagonal matrix based on the weight matrix for that alarm type; and then generating the Laplace matrix based on the out-degree diagonal matrix and the weight matrix.

[0176] The Laplace matrix is ​​a mathematical tool used to describe the energy conservation relationships in a network. It is constructed by subtracting the original weight matrix from the out-degree diagonal matrix. For each alarm type, the Laplace matrix captures the propagation path and distribution characteristics of anomalous energy under that alarm type, providing a foundation for subsequent solutions to the local Green's function. The construction of the Laplace matrix ensures that the propagation of anomalous energy satisfies conservation constraints, while maintaining the efficiency and stability of the computational process, providing a reliable mathematical framework for online inference.

[0177] S305, based on the Laplace matrix, determines the attenuation coefficient of each node in the service dependency graph.

[0178] The attenuation coefficient represents the proportion by which anomalous energy gradually weakens with increasing distance during propagation; it is a component of the local Green's function. By solving the linear equation of the Laplace matrix, the attenuation coefficient of each node with respect to its neighbors can be obtained. These attenuation coefficients describe how anomalous energy is distributed and attenuated locally, providing key parameters for rapid diffusion in the online phase. Determining the attenuation coefficient significantly reduces the computational complexity of the online phase; the anomalous diffusion process can be completed through table lookups and multiplication operations, greatly improving the real-time performance of the root cause localization process.

[0179] In some embodiments, the attenuation coefficient of each node in the service dependency graph is determined based on the Laplace matrix in step S305. This can be achieved in the following way: First, for each node in the service dependency graph, taking the node as the source node, traverse at least one level of child nodes connected to the source node to obtain the subgraph of the source node. At the same time, construct the standard basis vector of the source node. Finally, based on the element value of each node in the Laplace matrix and the standard basis vector, determine the attenuation coefficient of each node in the subgraph.

[0180] Here, the source node refers to the service node currently being processed, serving as the starting point for analyzing its influence scope. Child nodes are other nodes directly or indirectly connected to the source node through service call relationships, forming the influence path of the source node. A subgraph is a local structure extracted from the service dependency graph, containing only the source node and its child nodes at several levels. It simplifies computation and focuses on key influence areas. By constructing subgraphs, complex global topologies can be decomposed into multiple smaller problems, thereby reducing computational complexity and improving inference efficiency. In practice, there is a clear hierarchical relationship between the source node, child nodes, and subgraph: the source node is the starting point of analysis, child nodes are downstream dependencies of the source node, and the subgraph is a local structure composed of the source node and its child nodes.

[0181] A standard basis vector is a vector with dimension equal to the number of nodes in the service dependency graph, where only the elements corresponding to the source nodes are set to 1, and the remaining elements are set to 0. Standard basis vectors represent the initial state of a unit alarm signal in the subgraph after it is injected into the source node. Constructing standard basis vectors involves modeling the initial state of the source nodes in the subgraph and providing input conditions for subsequent linear equation solving. This method of constructing standard basis vectors provides a clear mathematical foundation for the computation process, facilitating the implementation of efficient numerical solution algorithms.

[0182] The Laplace matrix possesses properties such as zero row sum and positive semi-definiteness, reflecting the connectivity and energy conservation characteristics of the service dependency graph. The attenuation coefficient, obtained by solving local linear equations, represents the proportion of anomalies experienced by each node in the subgraph when a unit alarm is injected into the source node. The attenuation coefficient reflects the relative influence of different nodes on the propagation path, providing a basis for liability calculation.

[0183] In summary, using a local subgraph instead of the global graph to calculate the attenuation coefficient for each node in the service dependency graph not only reduces computational complexity but also improves the response speed of electronic devices. Furthermore, by introducing standard basis vectors and the Laplace matrix, the anomaly propagation process has a clear mathematical expression, thereby enhancing the interpretability and scalability of the attenuation coefficient calculation process.

[0184] S306, store the attenuation coefficient of each node in the service dependency graph into the diffusion coefficient table.

[0185] The diffusion coefficient table is a hash table structure used to store the attenuation coefficient of each node in the storage dependency graph under different alarm types. By using a hash table structure for the diffusion coefficient table, the corresponding attenuation coefficient can be quickly looked up and applied during the online phase, achieving millisecond-level anomaly propagation and root cause localization.

[0186] By pre-calculating and caching the attenuation coefficient, complex anomaly propagation modeling can be completed without affecting real-time performance. This approach provides technical support for automated operation and maintenance in high-QPS scenarios.

[0187] In this embodiment, by determining the call frequency and latency parameters between every two connected nodes in the service dependency graph, the target weight of the edge between every two connected nodes in the service dependency graph under different alarm types is determined based on the call frequency and latency parameters. A weight matrix for each alarm type is generated, and a Laplace matrix is ​​further constructed. Finally, the attenuation coefficient of each node is determined and stored in a diffusion coefficient table. After performing the above steps, accurate modeling of the propagation mechanism of alarm events of different alarm types can be achieved, and a corresponding diffusion coefficient table can be generated.

[0188] In some embodiments, each diffusion coefficient table corresponds to a version number. The version number is a unique identifier assigned to each diffusion coefficient table to distinguish it from tables generated at different times or under different topologies. The version number is automatically generated after a complete offline computation and stored along with the diffusion coefficient table. Using the version number ensures that the diffusion coefficients used during the online inference phase remain consistent with the current service dependency graph.

[0189] After determining the potential energy of each node in the service dependency graph based on the alarm intensity value of the first parent node and the attenuation coefficient of the first child node at each level, if the attenuation coefficient in the diffusion coefficient table changes or the topology of the service dependency graph has significantly shifted, an asynchronous offline recalculation can be triggered immediately to update the diffusion coefficient table. For example... Figure 10 The diagram shown is a schematic representation of an implementation process for updating the diffusion coefficient table provided in this application, including the following steps S401 to S403:

[0190] S401 determines the energy conservation residual value based on the potential energy, alarm intensity value, and diffusion coefficient table of each node.

[0191] The energy conservation residual is a consistency verification metric for the abnormal energy propagation process throughout the service dependency graph. It measures the model's accuracy by comparing the difference between the actually calculated potential energy distribution and the theoretical conservation conditions. Specifically, after each round of alarm processing, a theoretical energy balance state is derived from the current potential energy distribution, and this theoretical energy balance state is compared with the actual potential energy value to calculate the difference. If the energy conservation residual exceeds a set threshold, it indicates that the current diffusion coefficient table may be invalid and needs to be recalculated. This mechanism ensures the long-term stability of the root cause localization process and avoids misjudgments caused by topology drift or weight changes.

[0192] S402, in response to a change in the attenuation coefficient of a node in the service dependency graph determined based on the energy conservation residual value, the attenuation coefficient of the node is recalculated to obtain a new attenuation coefficient, and a new diffusion coefficient table is generated using the new attenuation coefficient.

[0193] The new attenuation coefficients are generated through an automatic local recalculation triggered when the existing diffusion coefficient table no longer satisfies the energy conservation constraint. This automatic local recalculation process can be performed only on the affected node and its k-hop subgraph, rather than globally calculating the entire service dependency graph, thus significantly reducing computational overhead. The new attenuation coefficients are generated based on the latest call frequency and latency statistics, combined with a typed Laplacian matrix for local solution. After the new attenuation coefficients are generated, they are written into a new diffusion coefficient table for subsequent alarm processing. This dynamic update mechanism ensures that the root cause localization method can quickly adapt to changes in network topology and business needs while maintaining real-time online processing.

[0194] S403 generates a new version number for the new diffusion coefficient table.

[0195] Generating a new version number for the new diffusion coefficient table is a crucial step in the version control mechanism. Each time a new diffusion coefficient table is generated, a new version number is assigned to it, and the new version number, along with the table's contents, is written to the storage system. The generation of the new version number is typically based on a timestamp or other incrementing sequence to ensure that each generated version is unique. Once the new version number takes effect, the diffusion coefficient table corresponding to that new version number will be used in the next round of alarm processing, thus guaranteeing data consistency and reliability. Furthermore, the new version number supports rollback operations; that is, if the new version number fails the energy conservation residual self-check, the electronic device can automatically revert to the previous stable version, ensuring the continuity of alarm processing.

[0196] In this embodiment of the application, by introducing a version number mechanism and an energy conservation residual self-checking method, the accuracy and consistency of the diffusion coefficient table can be dynamically maintained, thereby enabling timely responses to changes in topology and business environment, and thus improving the accuracy and real-time performance of root cause localization.

[0197] In some embodiments, the edge change rates of service dependency graphs in adjacent rounds can also be compared to trigger offline recalculation in a timely manner to update the diffusion coefficient table. For example... Figure 11 The diagram shown is a schematic representation of another implementation process for updating the diffusion coefficient table provided in this application embodiment, including the following steps S501 to S504:

[0198] S501, Obtain the two service dependency graphs when performing root cause localization on two adjacent alarm events.

[0199] Service dependency graphs are typically generated by Service Mesh, distributed tracing systems, etc., and include timestamps to reflect topology changes at different points in time. For example, when an alert occurs, a service dependency graph can be built based on the most recent call logs; when the next alert occurs, another service dependency graph can be built. These two service dependency graphs are used together to analyze changes in the service call chain, thereby helping to determine whether root cause localization is affected by changes in the topology.

[0200] By acquiring the service dependency graph of two consecutive alarm events, dynamic changes in the service call chain can be captured. Electronic devices can identify changes in the anomaly propagation path caused by topology alterations, thereby improving the accuracy and robustness of root cause localization.

[0201] S502, determine the edge change rate between two service dependency graphs.

[0202] Edge change rate refers to the ratio of newly added, deleted, or modified edges between two service dependency graphs to the total number of edges. It reflects the degree of change in service call relationships between two alert events. The edge change rate is calculated as: (Number of newly added edges + Number of deleted edges) / Total number of edges in the service dependency graph. A higher edge change rate indicates a significant adjustment to the service topology, which may affect the validity of the previously calculated diffusion coefficient table. For example, in a cloud-native platform, if a service module is refactored or replaced, the upstream and downstream call relationships of that service module will change, leading to a significant increase in the edge change rate.

[0203] By calculating the edge change rate, the stability of the service topology can be quantified. Based on this quantification, a basis can be provided for determining whether the diffusion coefficient needs to be recalculated, and the use of old parameters can be avoided when the topology has undergone significant changes, thereby reducing the risk of misjudgment.

[0204] S503, in response to the edge change rate being greater than the preset change rate threshold, the attenuation coefficient of the node is recalculated to obtain a new attenuation coefficient, and a new diffusion coefficient table is generated using the new attenuation coefficient.

[0205] When the edge change rate exceeds a set threshold, it indicates a significant change in the current topology, rendering the original attenuation coefficients inapplicable. Therefore, new attenuation coefficients need to be recalculated, and a new propagation coefficient table generated based on these new coefficients. For example, if a service node adds multiple downstream callers, the attenuation coefficients along the original propagation path will change, requiring recalculation. By monitoring the edge change rate and triggering the recalculation of attenuation coefficients, the root cause analysis process is ensured to always be based on the latest service topology information, thereby improving the real-time performance and accuracy of root cause analysis. This mechanism is particularly important in cloud-native environments where service architectures frequently change.

[0206] S504 generates a new version number for the new diffusion coefficient table.

[0207] In this embodiment, by obtaining the service dependency graph corresponding to two adjacent alarm events, the edge change rate of the service dependency graph is calculated. When the edge change rate exceeds a set threshold, the attenuation coefficient is recalculated and a new diffusion coefficient table is generated to ensure that the root cause localization process always operates based on the latest service topology. Through this process, the impact of changes in the service topology can be detected and addressed in a timely manner, thereby improving the accuracy and stability of root cause localization and further enhancing the self-healing capability and operational efficiency of cloud-native systems.

[0208] The following will describe an exemplary application of the embodiments of this application in a real-world application scenario.

[0209] This application addresses the shortcomings of root cause localization practices in microservice systems (AIOps) in related technologies. It proposes a method that improves the accuracy, real-time performance, and interpretability of root cause localization by employing typed Laplace modeling and multi-channel influence field incremental solution, outputting results with millisecond-level latency, and incorporating a residual self-checking mechanism. This application will detail the theoretical baseline, overall approach, data flow and input / output, offline preparation, online inference process, and results of the proposed method.

[0210] This section first introduces the theoretical baseline of the root cause localization method in the embodiments of this application.

[0211] Before introducing the overall process, we must first clarify the theoretical basis of this application's embodiments: the potential conservation model. The potential conservation model treats the microservice call graph as a weighted circuit. In this circuit model, nodes represent voltage nodes, and the weights on the edges are considered as conductance values; alarm information is mapped to a constant current s continuously injected into a certain node. According to the principle of potential conservation, when the potential of a certain node is higher, it indicates that the anomaly is more likely to accumulate at this node, thus indicating that the node is more likely to be the root cause of the problem. This conservation law can be discretized into the following formulas (1) and (2):

[0212] (1);

[0213] (2);

[0214] Where W is the edge weight matrix, D is the row and diagonal matrix, and L is the Laplacian matrix calculated based on the edge weight matrix and the row and diagonal matrix; The node potential energy to be calculated. To better reflect actual monitoring, this embodiment further breaks down different alarm types into multiple independent conservation equations, expressed as the following formula (3):

[0215] (3);

[0216] in, This represents the Laplace matrix for alarm type k. The node potential energy to be calculated under alarm type k; in this embodiment, the alarm events of the four alarm types are divided into four channels L / E / R / C according to the propagation mechanism, where L (Latency) refers to performance alarms such as interface latency or timeout; E (Error) refers to failure alarms triggered by service error codes or abnormal logs; R (Resource) refers to alarms of node resource exhaustion such as CPU, memory or video memory; and C (Connectivity) refers to network connectivity alarms such as link packet loss, connection reset, and bandwidth jitter.

[0217] Furthermore, in the embodiments of this application, business weights are used during the online phase. node potential energy Combined into total potential See the following formula (4):

[0218] (4).

[0219] All subsequent steps—local k-hop Green's lookup table, double exponential decay, responsibility calculation, and energy conservation residual self-check—are efficient approximations or extensions of the above conservation equations, ensuring that the algorithm has both solid physical meaning and can be applied to real-time scenarios.

[0220] Figure 12 This is a schematic diagram of the overall process of the root cause localization method provided in the embodiments of this application. The following will be combined with... Figure 12 This paper introduces the overall concept of the root cause localization method in the embodiments of this application.

[0221] A single failure in a microservice system often triggers multiple alarms of varying types: the entry interface may report timeouts, the middleware layer may report error codes, and some nodes may also display CPU or memory alarms. These alarms share the same call topology but have distinct propagation mechanisms. For example, latency / errors typically amplify upstream along the call chain, while resource alarms are mostly confined to the local node. Current technologies either treat all alarms as homogeneous signals, leading to both false positives and false negatives, or rely on full graph traversal or deep learning model inference, which struggles to meet sub-second closed-loop latency requirements.

[0222] This application embodiment first divides alarm events into several "type channels" (delay, error, resource, network, etc.) according to the propagation mechanism, and generates a directional diffusion map for each alarm type on the same service dependency graph, including the following constraints: the directional diffusion map for delay / error type is only allowed to spread upstream along the calling direction; the directional diffusion map for resource type locks the energy in this node; the directional diffusion map for network type propagates symmetrically at both ends of the link.

[0223] Building upon this, a discrete influence field model is constructed using the physical analogy of potential-heat diffusion: each alarm is treated as a unit heat source, decaying and propagating along its respective directional diffusion map. To avoid performing full matrix inversion on large-scale topologies, the "local Green coefficient" (i.e., the attenuation coefficient of unit energy in the neighborhood) is calculated only for the subgraph within k hops of each node in the offline thread and stored in a lookup table. During online inference, the algorithm only needs to perform the following steps: lookup table, multiply coefficients, and accumulate potential energy, which can diffuse each new alarm message to the neighborhood of this alarm message within milliseconds. Next, the responsibility degree of each node is calculated, that is, the proportion of the potential energy retained by this node to the sum of the potential energy of this node and its direct downstream nodes; sorting or filtering according to IRS can provide a high-confidence root cause list within milliseconds. The entire process fully complies with the conservation of potential energy and can be self-checked at any time using residuals: when the weights are called or the topology drift causes the residuals to exceed the threshold, the local coefficients are automatically recalculated to ensure long-term stability. This allows for a type-aware, interpretable, millisecond-level root cause localization loop without relying on GPUs or deep training.

[0224] The data flow and input / output of the root cause localization method provided in the embodiments of this application are described below.

[0225] This application's embodiments transfer data along a sequence of map preparation, real-time inference, and closed-loop processing. The overall data flow is described first here, followed by a detailed explanation of the specific technical details of each part.

[0226] First, alerting and topology preparation are performed at the input end. The microservice system continuously generates metrics, logs, and call chain information. The alert center first assigns a type label to each abnormal event, such as latency, error, resource, or network, and linearly maps the original level of the alert event (P1, P2, ...) to an intensity value between 0 and 1, generating the simplest alert source vector. Simultaneously, the service mesh or tracing system periodically extracts the dependencies between service A and service B, forming the service topology required for current inference. At this point, two key base maps are available: one showing the sparse vector of abnormal energy, and the other showing the topology along which edges the energy can propagate.

[0227] Then, diffusion and judgment are performed in the main online process. For example... Figure 12 As shown, whenever a new alarm source vector arrives, i.e., after an alarm event is monitored in step S1201, step S1202 is executed to perform type identification and level normalization, generating a sparse source vector. Afterwards, the inference engine looks up a small-scale diffusion coefficient table in memory (i.e., a preset diffusion coefficient table, which is pre-determined by an offline thread based on the topology, requiring no real-time computation). The inference engine uses the decay coefficients retrieved from this small-scale diffusion coefficient table to diffuse the abnormal energy upstream or locally along the call chain, covering the vast majority of affected nodes in just two or three hops, i.e., executing step S1203 to perform k-hop Green's lookup table diffusion to obtain the instantaneous potential energy. Then, step S1204 performs double exponential decay, and step S1205 performs multi-channel potential energy fusion. Finally, step S1206 calculates the responsibility level, calculating the proportion of abnormal energy remaining on each node (responsibility level). To avoid one-time spikes or jitter affecting the judgment, the abnormal energy needs to be simultaneously passed through two exponential averages (fast window + slow window) before fusion smoothing. Finally, in step S1207, threshold filtering is performed and root cause nodes are output. The node with the highest abnormal energy and responsibility exceeding the threshold is regarded as the root cause node of this round of alarm events.

[0228] Finally, alarm folding and closed-loop self-healing are performed at the output end. Once the root cause node list is generated, it is immediately sent back to the alarm platform. Alarms from downstream nodes of the root cause node are silenced and folded, while alarms from upstream nodes are retained. If the corresponding automated scripts for the root cause node (e.g., scaling, restarting, rate limiting) have been pre-configured, they will be executed directly. Simultaneously, an energy conservation residual is calculated. If the energy conservation relationship is found to be violated by the new topology, the diffusion coefficient table is immediately recalculated to ensure the reliability of subsequent inferences. In this way, the entire process of an alarm event, from its occurrence to silencing, location, self-healing, and self-checking, completes the closed loop in milliseconds, requiring no deep training or heavy computing resources.

[0229] The offline preparation stage of the root cause localization method provided in this application embodiment will be described below, through which a preset diffusion coefficient table is obtained.

[0230] First, in step S1208, the topology is invoked and metrics are collected to obtain the service topology and raw statistics. Service call records for the most recent 5 minutes can be continuously pulled from Service Mesh telemetry logs or distributed tracing. For each record, the service names of the caller and callee, as well as the call latency, are parsed out. Then, directed edges are constructed in the "caller → callee" relationship, and all edges are aggregated into a service dependency graph G(V, E). During graph construction, two statistics are accumulated for each edge: average call frequency. (Total number of requests during the recording period ÷ time), average or p95 latency These two sets of figures summarize "how busy this path is" and "how great the transmission resistance is," and will be directly referenced in subsequent weight calculations. After processing, the topology G(V, E) and its edge attributes are written to versioned storage; all subsequent offline steps use this graph as input.

[0231] Then, in step S1209, the typed weight matrix is ​​determined. The edge weights can be calculated and normalized. After obtaining the dependency graph with QPS and latency statistics, the next step is to quantify the "importance of the call path" into a dimensionless coefficient between 0 and 1. The specific method is: first, measure the activity of the path by the call frequency, and then measure the propagation efficiency of the anomaly along the path by the inverse of the latency. Multiply the two to obtain an original weight, see the following formula (5):

[0232] (5).

[0233] in, It is a baseline delay constant used to bring the reciprocal of the delay dimension back to a dimensionless value on the same order of magnitude as QPS. A value of 30ms can be used to ensure that the fraction values ​​fall within roughly the same order of magnitude across common service latency ranges. Let be the original weights between node i and node j. To ensure that all edge weights fall within [0, 1], a linear compression is then performed using the minimum and maximum values ​​of the entire graph, as shown in the following formula (6):

[0234] (6).

[0235] in, To minimize the original weight of the entire graph, Maximum original weight of the entire graph. Let be the weight in the i-th row and j-th column of the linearly compressed weight matrix.

[0236] Different alarm types have different requirements for propagation direction, so multiple "typed" weight matrices need to be derived on the same topology diagram: the delay channel and the error channel directly adopt the above... ; Resource channels accumulate only at this node due to anomalies, so the weights of all edges are set to 0; Network channels assume that both ends of the link are affected simultaneously, so the forward and reverse weights are added together to obtain the weights of the edges under the network channel type, see the following formula (7):

[0237] (7)

[0238] in, This represents the weight of the edge between node i and node j in network channel C.

[0239] Ultimately, each alarm type yields its own sparse matrix. This is written to the same repository along with a timestamp, providing direct input for subsequent Laplace construction.

[0240] Next, in step S1210, a typed Laplacian matrix is ​​constructed. This is followed by obtaining the weight matrices for each alarm type. The next step in the offline process is to transform these "heat transfer coefficients" into truly computable conservation operators. For example, we can first calculate the total weight of each node's outward leakage, and then use "total leakage - single leakage" to form a Laplace matrix. Specifically, for a certain type k (latency, error, resource, or network), the following operations are performed: First, calculate the out-degree diagonal matrix. Summing each row of the weight matrix yields the total outward leakage weight of node i. Place the total outward leakage weight of node i on the diagonal, and fill the remaining positions with zeros to obtain the value in the i-th row and i-th column of the out-degree diagonal matrix. See the following formula (8):

[0241] (8).

[0242] Then, combine them to form the Laplace matrix. Subtract the original weight matrix from the out-degree diagonal matrix from the previous step to obtain the Laplace matrix. See the following formula (9):

[0243] (9).

[0244] This is how it was obtained. It possesses the following characteristics: the row sum is always zero, ensuring that the abnormal energy strictly follows the "outflow = inflow" rule; it is positive semi-definite, preventing divergence in subsequent linear equation solving; and it is highly sparse, with non-zero values ​​only at the actual call edges, facilitating local inversion. After this step, each alarm type has its own sparse Laplacian matrix, with a version number written to the offline library, providing direct input for the next step of calculating local Green's coefficients.

[0245] Next, in step S1211, a local Green's coefficient table (i.e., a preset diffusion coefficient table) is generated. The final step in offline preparation is to convert the previously obtained Laplace matrix into a readily usable attenuation coefficient table. The core idea is to first calculate the steady-state distribution of the unit anomaly within each node's own k-hop neighborhood; in the online phase, only a table lookup and one multiplication are needed to obtain the actual diffusion amount of the anomaly energy. The entire process is completed in three steps: First, a k-hop subgraph is extracted, which can be started from the source node i and traversed to the k-th layer reachable node using breadth-first search (BFS) (k can be 2 or 3). The resulting subgraph... Typically, there are only a few dozen nodes, allowing for rapid matrix operations. The second step is to calculate the unit source response vector within this k-hop subgraph. To describe "if 1 unit anomaly is injected at node i, how many units remain in the surrounding nodes," we can first construct a standard basis vector where only the i-th position is equal to 1, and the remaining positions are 0. It is expressed as the following formula (10):

[0246] (10).

[0247] Bundle Treating it as the source vector, solve the local linear equation (11):

[0248] (11)

[0249] in, This represents the subgraph at the i-th node under alarm type k. In the equation, the weight coefficients of each node, and the solution of the equation. This describes the potential energy share borne by each node in the neighborhood at steady state if a unit anomaly is injected into node i. In other words, It is the local Green's function sequence of node i with respect to its k-hop neighborhood. This provides an accurate attenuation coefficient for subsequent online diffusion.

[0250] The third step is to extract the weight coefficients from the parent node to the child node and write them into a table. Since online propagation only requires the proportion of abnormal energy that the parent node i transmits to the directly connected child node j, the following calculation formula (12) can be used to obtain the attenuation coefficient under alarm type k. :

[0251] (12).

[0252] Write the calculation result into a hash table, with the key being the parent node i and the value being {( , The list is as follows. After all nodes have been processed, the lookup table files (i.e., diffusion coefficient tables) for the four alarm channels can reside in memory and be used for online queries. After completing this diffusion coefficient table, when a new alarm event is encountered during the online phase, no matrix needs to be calculated. Only table lookup, coefficient multiplication, and accumulation are required to complete an abnormal diffusion and potential energy update in milliseconds.

[0253] After generating the local Green's coefficient table, versioning and consistency monitoring are performed. The weight matrix, Laplace matrix, and local Green's coefficients (i.e., decay coefficients) calculated offline must always be synchronized with the online business; otherwise, the inference will be inaccurate. Therefore, this embodiment implements a dual mechanism of version control and online self-checking for this offline asset set to ensure long-term reliability without interrupting real-time services.

[0254] In the versioning and consistency monitoring process, version encapsulation is performed first. After each offline calculation, a version number is generated for the entire data set. The generated version number is represented as: verID = timestamp || SHA256. Here, timestamp is the completion time of all decay coefficient calculations; snapshot is the time when all... The file's binary string is concatenated, encapsulated, and written to disk and memory cache. The online thread only holds a pointer to the currently available verID, ensuring atomic replacement with no window of inactivity during switching. Then, a residual conservation self-check is performed. After online inference, the electronic device immediately calculates the energy conservation residual for alarm type k. See the following formula (13):

[0255] (13).

[0256] Where V represents the number of nodes in the current service dependency graph; This represents the alarm intensity value of node i under alarm type k; This represents the value of the element in the i-th row and j-th column of the Laplace matrix under alarm type k; This represents the potential energy of node j after k-hop diffusion and smoothing. In the embodiments of this application, maintenance Moving average ,when If the residual threshold ε is exceeded (the default value can be 0.05), it is considered that the weights or topology have significantly drifted, and an asynchronous offline recalculation is immediately triggered. If the recalculation is successful, a new version number verID is generated, and the online thread is notified to switch seamlessly; if the recalculation fails, it is rolled back to the most recent normal version.

[0257] In addition, the edge change rates of service dependency graphs in two adjacent rounds can be compared. See the following formula (14):

[0258] (14).

[0259] Where E represents the set of edges in the service dependency graph. This represents the set of newly added edges in the service dependency graph. This represents the set of original edges in the service dependency graph. =( )∪( / The sum of newly added and deleted edges is represented by ), where represents the union of newly added and deleted edges. If the proportion of newly added or deleted edges is greater than or equal to 5%, offline recalculation will be triggered in advance to ensure that the diffusion coefficient is consistent with the actual service dependency graph.

[0260] In this embodiment, by using version number, residual threshold and topology drift as dual criteria, it can be ensured that the real-time link always references a verified diffusion coefficient table and the inference is not interrupted; the offline thread refreshes in the background and is switched only when the new version passes the conservation self-check.

[0261] The online inference process of the root sound localization method in the embodiments of this application will be described below.

[0262] When performing online inference, the first step is to receive real-time events and generate source vectors. The starting point for online inference is to "quickly transcribe a monitoring alarm into a data structure usable by the model." During real-time event reception and source vector generation, it is necessary to identify the alarm type and assign it to the correct channel; and to map discrete levels into 0-1 alarm intensity values ​​and write them into a sparse vector.

[0263] For the raw alarm information of the received alarm events, the input format can be...<nodeID,metricName,severityRaw,timestamp> The rules for parsing alarm information can be based on metricName or alarm label to categorize events into channels such as latency, error, resource, or network. Most monitoring systems use P1-P5 or Critical / Warning to represent alarm levels. This application embodiment uses a fixed mapping table to convert alarm levels into continuous values ​​from 0 to 1, as shown in Table 1.

[0264] Table 1 Mapping Relationship Table

[0265] Original level Alarm intensity value P1 / Critical 1.0 P2 / Major 0.8 P3 / Minor 0.5 P4 / Warning 0.2 P5 / Info 0.1

[0266] The mapping formula can be expressed as formula (15):

[0267] (15).

[0268] in, This represents a mapping function that corresponds to the mapping relationship table in Table 1. This represents the alarm intensity value (i.e., normalized intensity) of the i-th node under alarm type k.

[0269] In this embodiment, a sparse vector s_type of length |V| can be maintained for each alarm type. Upon receiving an alarm event, the corresponding index position of the sparse vector s_type can be written to... The remaining positions are kept at 0. If the same node repeatedly alarms within the same type of channel in a short period of time, a deduplication strategy of taking the most recent alarm and retaining the maximum value can be used to ensure that each node records the intensity only once per round.

[0270] After writing the alarm events as typed sparse source vectors s_type, the source values ​​in these sparse source vectors can be rapidly diffused topologically into node potential φ_type using the local Green coefficients (i.e., attenuation coefficients) from the offline prepared local Green coefficient table. The algorithm relies on table lookup and multiplication, and the process consists of the following three steps:

[0271] The first step is to fetch the source node. Extract all non-zero entries from s_type to form a set to be processed. See the following formula (16):

[0272] (16).

[0273] The second step is to propagate outwards hop by hop. First, starting from the source node: [The text abruptly ends here, likely due to an incomplete sentence or missing information.] This is considered the "0th hop" boundary; then, the diffusion coefficient table is consulted to obtain the attenuation coefficient: for each parent node u on the boundary, the attenuation coefficient from all parent nodes u (i.e., the first parent node mentioned above) to child nodes v (i.e., the first child node mentioned above) is directly read from the offline-generated diffusion coefficient table. Then, multiply the outlier carried by the current node by the attenuation coefficient to obtain the incremental potential energy flowing to the child node, see formula (17):

[0274] (17).

[0275] Next, put Accumulate the potential energy bucket of child node v; if the same child node comes from multiple parent edges, these incremental potential energies are summed before entering the next hop; iterate k times, and stop diffusion when the number of layers pushed outward reaches the preset k (e.g., 2 or 3 times).

[0276] The third step is to generate the instantaneous potential energy vector. After completing the k-hop propagation, the instantaneous potential energy distribution of this type is obtained, as shown in the following formula (18):

[0277] (18).

[0278] At this point, the real-time dissemination of a single alarm has been completed.

[0279] In this embodiment of the application, the real-time diffusion obtained... It is a transient impact, highly sensitive to monitoring glitches. In order to capture new anomalies without over-responding to jitter, the embodiments of this application perform double exponential decay smoothing. At each node, a fast window exponential average and a slow window exponential average are maintained simultaneously, and then adaptively fused using a weight α.

[0280] Suppose that node v already has at the previous time step (That is, the average potential energy within the first time window mentioned above; the first time window is a fast window with short memory) and (That is, the average potential energy within the second time window mentioned above; the second time window is a slow window with a long memory), receiving new instantaneous potential energy. Then, the update process of the following formulas (19) and (20) is executed synchronously:

[0281] (19);

[0282] (20).

[0283] in, It can take the value 0.7. The value can be 0.95. The smooth potential energy is obtained by merging the two windows, as shown in the following formula (21):

[0284] (twenty one).

[0285] The weight α ∈ [0, 1], with a default value of 0.6. The fast window rapidly increases the accuracy of the system in response to new anomalies, while the slow window ensures a smooth decrease when there is no new input; α can be automatically tuned offline using historical accuracy.

[0286] In the above scheme, each alarm type k has obtained its own smooth potential energy distribution. However, the four types of alarms—latency, error, resource, and network—have different importance in contributing to the root cause. Therefore, this application embodiment uses an adjustable channel weight vector. The potential energy of each channel is linearly combined into a single total potential energy ϕ, which is then used for subsequent IRS determination, as shown in the following formula (22):

[0287] (twenty two).

[0288] For each node v, the potential energy of the four channels is multiplied by the corresponding weights and then summed.

[0289] The total potential energy ϕ after merging describes how much abnormal energy is currently accumulated at each node, but it does not specify whether this abnormal energy is caused by the node itself or comes from downstream nodes. To address this, embodiments of this application introduce a responsibility rating IRS. IRS measures the proportion of abnormal potential energy left by a node in the node-downstream node combination; the higher the value, the more likely the node is to be the root cause of the failure.

[0290] Let child(v) be the set of direct downstream nodes of node v. The responsibility of node v at the current time is denoted by the following formula (23):

[0291] (twenty three).

[0292] ≈1 means that almost all of the abnormal potential energy remains inside node v, so node v is very likely the root cause of the fault. This indicates that the abnormal potential energy is mainly transmitted downstream, and node v is more likely just a byproduct. All nodes can be sorted in descending order of IRS, and the nodes exceeding the threshold θ (default 0.6) or the top n (e.g., Top-3) can be selected as the root cause nodes and displayed.

[0293] The root cause localization method provided in this application embodiment can achieve at least the following technical effects: (1) Shorten the localization link and lock the root cause in advance. With the help of the process of type recognition, k-hop Green table lookup and IRS responsibility, the abnormal accumulation position is measured at the moment of alarm sampling, and the root cause determination is moved to the monitoring side in advance rather than troubleshooting after the fact. (2) Suppress false alarms and focus on high confidence nodes. The typed Laplace matrix isolates resources and delay propagation paths, double exponential decay eliminates spikes, and IRS emphasizes the retention ratio of this node; the combined strategy actively suppresses accompanying alarms and noisy alarms, so that the operation and maintenance attention is focused on the real source of failure. (3) Lightweight architecture with low computation and maintenance overhead. The online link only performs table lookup and multiplication and addition, and the CPU usage is controllable; the offline link only calculates the local inverse matrix in the k-hop subgraph, and the computation scale grows with the neighborhood rather than the whole network. No GPU or deep training is required, and the deployment cycle and computing power cost are greatly reduced. (4) Self-check and hot-switching version. It can monitor the model-environment consistency in real time with the residual, and trigger local recalculation and atomic replacement of the version when the residual threshold is exceeded, without the need for manual intervention. (5) Interpretability. Each output node is equipped with potential energy φ, responsibility IRS and propagation link, which can be directly embedded into the operation and maintenance visualization for interpretation.

[0294] It should be noted that the root cause localization method provided in this application includes, but is not limited to, the following key technical points: (1) Typed Laplace propagation model: This application first constructs a Laplace matrix for different alarm types based on the service call topology. Among them, delay and error propagate along the call direction, and resource channel order Accumulation occurs only at this node; network channels use undirected weights. This design is the first to explicitly distinguish the propagation mechanism within a unified topology, thereby eliminating false alarms caused by the mispropagation of resource-related alarms along the link. (2) Local k-hop Green's lookup table algorithm: For each node, the local equation is solved only in the k-hop neighborhood of this node. And the attenuation coefficient from parent node to child node The cache is in the form of a hash table. During the online phase, the abnormal spread does not require matrix inversion, but only "look up the table - multiply the coefficient - accumulate", which reduces the computational complexity and ensures that the root cause inference is completed within the monitoring sampling period. (3) Double exponential decay gating smoothing: In order to suppress instantaneous spikes while retaining slow rise faults, the system maintains a fast window in parallel for each node. and slow window Two exponential moving averages, then weighted... Merging into smooth potential energy This gating is more robust than single-window averaging, and can respond quickly to new anomalies and smoothly fall back. (4) Root cause determination formula: The proportion of anomalies of a node to its direct downstream is defined by formula (23). This indicator is not related to the number of alarms, but only depends on energy conservation, so it is interpretable and topology-independent. After threshold screening, the set of high-confidence root causes can be obtained. (5) Self-checking and hot-switching mechanism for conserving residuals: Real-time calculation of conserving residuals; once the conserving residuals or the topology change rate exceeds the threshold, the background automatically recalculates the local Green coefficient and atomically replaces the new version, so as to keep the model and environment consistent without manual intervention.

[0295] Based on the root cause localization method described in the above embodiments Figure 13 This paper illustrates a structural block diagram of a root cause localization device according to an embodiment of this application. The root cause localization device 100 can be a device in an electronic device (e.g., a server). The root cause localization device can be implemented in software, and can be software in the form of programs and plugins, including the following software modules: a parsing module 101, used to parse the alarm information in response to obtaining alarm information of a current alarm event, to obtain the alarm type and alarm intensity value of the current alarm event; a generation module 102, used to generate an alarm source vector under the alarm type based on the alarm intensity value; each element in the alarm source vector corresponds to a service dependency graph under the alarm type. A node in the alarm source vector; a query module 103, used to query the attenuation coefficient from the first parent node to the first child node from a preset diffusion coefficient table, with each non-zero element in the alarm source vector corresponding to the first parent node as the first parent node; the first child node is a child node of at least one level connected to the first parent node; a determination module 104, used to determine the potential energy of each node in the service dependency graph based on the alarm intensity value of the first parent node and the attenuation coefficient of the first child node at each level; a root cause localization module 105, used to locate the root cause node of the current alarm event in the service dependency graph based on the potential energy of each node in the service dependency graph.

[0296] In some embodiments, the parsing module 101 is further configured to: in response to obtaining alarm information of the current alarm event, parse the type field in the alarm information having a preset format to obtain the alarm type of the current alarm event; and parse the level field in the alarm information to obtain the alarm level of the current alarm event; and map the alarm level to the alarm intensity value based on a preset mapping table.

[0297] In some embodiments, the generation module 102 is further configured to: parse the node identifier field in the alarm information to obtain the node identifier of the alarm node corresponding to the current alarm event; construct a sparse vector corresponding to the alarm type based on the number of nodes in the service dependency graph; the dimension of the sparse vector is equal to the number of nodes, and each element in the sparse vector corresponds to a node in the service dependency graph; and write the alarm intensity value to the element position corresponding to the alarm node in the sparse vector based on the node identifier to obtain the alarm source vector under the alarm type.

[0298] In some embodiments, the determining module 104 is further configured to: determine the alarm intensity value of the first parent node as the potential energy of the first parent node; determine the alarm intensity value of the first child node at each level as the initial potential energy of the first child node; determine the incremental potential energy of the first child node by multiplying the alarm intensity value of the first parent node by the attenuation coefficient of the first child node at each level; and determine the sum of the initial potential energy and the incremental potential energy of each first child node as the potential energy of the first child node.

[0299] In some embodiments, the number of alarm types in the alarm system is multiple; the root cause localization module 105 is further configured to: for each node in the service dependency graph, obtain the potential energy of the node under each alarm type at the current time and the channel weight corresponding to each alarm type; calculate the total potential energy of the node by weighted summation of the potential energy under multiple alarm types based on the channel weight; determine the responsibility of each node based on the total potential energy of each node in the service dependency graph and the connection relationship between the nodes; and locate the root cause node of the current alarm event from the service dependency graph based on the responsibility.

[0300] In some embodiments, the root cause localization module 105 is further configured to: for each node in the service dependency graph, taking the node as a second parent node, determine at least one level of second child nodes connected to the second parent node based on the connection relationship; determine the total potential energy of the at least one level of second child nodes; and determine the degree of responsibility of the node based on the total potential energy of the node and the total potential energy sum.

[0301] In some embodiments, the root cause localization module 105 is further configured to: sort the nodes in the service dependency graph in descending order of responsibility to form a node sequence; determine the first N nodes in the node sequence, where N is an integer greater than 0, as the root cause nodes of the current alarm event; or determine the nodes with a responsibility level greater than a preset responsibility level threshold as the root cause nodes of the current alarm event.

[0302] In some embodiments, the root cause localization module 105 is further configured to: smooth the potential energy under each alarm type to obtain smoothed potential energy; and weight and sum the smoothed potential energy under multiple alarm types based on the channel weights to obtain the total potential energy of the node.

[0303] In some embodiments, the root cause localization module 105 is further configured to: for each alarm type, acquire a first potential energy of the node within a first time window before the current time and a second potential energy within a second time window; the window length of the first time window is less than the window length of the second time window; determine a third potential energy of the node within the first time window including the current time based on the first potential energy and the potential energy of the node at the current time; determine a fourth potential energy of the node within the second time window including the current time based on the second potential energy and the potential energy of the node at the current time; and fuse the third potential energy and the fourth potential energy to obtain the smoothed potential energy of the node.

[0304] In some embodiments, the apparatus further includes: a table generation module, configured to: determine the call frequency and latency parameters between every two connected nodes in the service dependency graph before querying the attenuation coefficient from the first parent node to the first child node from a preset diffusion coefficient table; determine the target weight of the edge between every two connected nodes under different alarm types based on the call frequency and the latency parameters; generate a weight matrix for each alarm type based on the target weight of each edge under different alarm types; generate a Laplace matrix for each alarm type based on the weight matrix for each alarm type; determine the attenuation coefficient of each node in the service dependency graph based on the Laplace matrix; and store the attenuation coefficient of each node in the diffusion coefficient table.

[0305] In some embodiments, the table generation module is further configured to: for each node in the service dependency graph, taking the node as the source node, traverse at least one level of child nodes connected to the source node to obtain a subgraph of the source node; construct the standard basis vector of the source node; and determine the decay coefficient of each node in the subgraph based on the element value corresponding to each node in the Laplacian matrix and the standard basis vector.

[0306] In some embodiments, the diffusion coefficient table corresponds to a version number; the apparatus further includes: a table update module, configured to, after determining the potential energy of each node in the service dependency graph based on the alarm intensity value of the first parent node and the attenuation coefficient of the first child node at each level, determine an energy conservation residual based on the potential energy of each node, the alarm intensity value, and the diffusion coefficient table; in response to determining that the attenuation coefficient of a node in the service dependency graph has changed based on the energy conservation residual, recalculate the attenuation coefficient of the node to obtain a new attenuation coefficient, and generate a new diffusion coefficient table using the new attenuation coefficient; and generate a new version number for the new diffusion coefficient table.

[0307] In some embodiments, the table update module is further configured to: obtain two service dependency graphs when performing root cause localization on two adjacent alarm events; determine the edge change rate between the two service dependency graphs; in response to the edge change rate being greater than a preset change rate threshold, recalculate the attenuation coefficient of the node to obtain a new attenuation coefficient, and use the new attenuation coefficient to generate a new diffusion coefficient table; and generate a new version number for the new diffusion coefficient table.

[0308] It should be noted that the description of the apparatus in this application embodiment is similar to the description of the method embodiment described above, and has similar beneficial effects as the method embodiment; therefore, it will not be repeated. For technical details not disclosed in this apparatus embodiment, please refer to the description of the method embodiment of this application for understanding.

[0309] This application provides an electronic device. Figure 14 This is a schematic diagram of the structure of the electronic device provided in an embodiment of this application. For example... Figure 14 As shown, the electronic device 130 includes: at least one processor 131 ( Figure 14 (Only one is shown in the diagram), memory 132, and computer-executable instructions 133 stored in memory 132 and executable on at least one processor 131, which, when executed by processor 131, implement the steps in any of the above-described audio generation method embodiments.

[0310] The electronic device may include, but is not limited to, a processor 131 and a memory 132. Those skilled in the art will understand that... Figure 14 This is merely an example of electronic device 130 and does not constitute a limitation on electronic device 130. It may include more or fewer components than shown, or combine certain components, or different components, such as input / output devices, network access devices, etc.

[0311] Processor 131 can be a central processing unit (CPU), or it can be other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), field-programmable gate arrays (FPGs), or other programmable logic devices, discrete gate or transistor logic devices, discrete hardware components, etc. A general-purpose processor can be a microprocessor or any conventional processor.

[0312] In some embodiments, memory 132 may be an internal storage unit of electronic device 130, such as a hard disk or memory of electronic device 130. In other embodiments, memory 132 may be an external storage device of electronic device 130, such as a plug-in hard disk, smart media card (SMC), secure digital card (SD), flash card, etc., equipped on electronic device 130. Furthermore, memory 132 may include both internal and external storage units of electronic device 130. Memory 132 is used to store operating system, application programs, bootloader, data, and other programs, such as program code of computer programs. Memory 132 may also be used to temporarily store data that has been output or will be output.

[0313] This application provides a computer program product including a computer program or computer-executable instructions stored in a computer-readable storage medium. A processor of an electronic device reads the computer-executable instructions from the computer-readable storage medium and executes the computer-executable instructions, causing the electronic device to perform the root cause localization method described above in this application.

[0314] This application provides a computer-readable storage medium storing computer-executable instructions or a computer program. When the computer-executable instructions or the computer program are executed by a processor, the processor will execute the audio generation method provided in this application. For example, ... Figure 1 The root cause localization method is shown.

[0315] In some embodiments, the computer-readable storage medium may be a memory such as RAM, ROM, flash memory, magnetic surface memory, optical disk, or CD-ROM; or it may be a variety of devices including one or any combination of the above-mentioned memories.

[0316] In some embodiments, computer-executable instructions may take the form of programs, software, software modules, scripts, or code, written in any form of programming language (including compiled or interpreted languages, or declarative or procedural languages), and may be deployed in any form, including as stand-alone programs or as modules, components, subroutines, or other units suitable for use in a computing environment.

[0317] As an example, computer-executable instructions may, but do not necessarily, correspond to files in a file system. They may be stored as part of a file that holds other programs or data, for example, in one or more scripts in a HyperText Markup Language (HTML) document, in a single file dedicated to the program in question, or in multiple co-located files (e.g., a file that stores one or more modules, subroutines, or code sections).

[0318] As an example, computer-executable instructions can be deployed to execute on a single electronic device, or on multiple electronic devices located at one location, or on multiple electronic devices distributed across multiple locations and interconnected via a communication network.

[0319] The above description is merely an embodiment of this application and is not intended to limit the scope of protection of this application. Any modifications, equivalent substitutions, and improvements made within the spirit and scope of this application are included within the scope of protection of this application.

Claims

1. A root cause localization method, characterized in that, The method includes: In response to obtaining the alarm information of the current alarm event, the alarm information is parsed to obtain the alarm type and alarm intensity value of the current alarm event; Based on the alarm intensity value, an alarm source vector is generated for the alarm type; each element in the alarm source vector corresponds to a node in the service dependency graph for the alarm type. The node corresponding to each non-zero element in the alarm source vector is taken as the first parent node, and the attenuation coefficient from the first parent node to the first child node is queried from the preset diffusion coefficient table; the first child node is a child node of at least one level connected to the first parent node. Based on the alarm intensity value of the first parent node and the attenuation coefficient of the first child node at each level, the potential energy of each node in the service dependency graph is determined. Based on the potential energy of each node in the service dependency graph, the root cause node of the current alarm event is located in the service dependency graph.

2. The method according to claim 1, characterized in that, In response to obtaining the alarm information of the current alarm event, the alarm information is parsed to obtain the alarm type and alarm intensity value of the current alarm event, including: In response to obtaining the alarm information of the current alarm event, the type field in the alarm information with a preset format is parsed to obtain the alarm type of the current alarm event; and the level field in the alarm information is parsed to obtain the alarm level of the current alarm event. Based on a preset mapping table, the alarm level is mapped to the alarm intensity value.

3. The method according to claim 1, characterized in that, The step of generating an alarm source vector for the alarm type based on the alarm intensity value includes: The node identifier field in the alarm information is parsed to obtain the node identifier of the alarm node corresponding to the current alarm event; Based on the number of nodes in the service dependency graph, a sparse vector corresponding to the alarm type is constructed; the dimension of the sparse vector is equal to the number of nodes, and each element in the sparse vector corresponds to a node in the service dependency graph. Based on the node identifier, the alarm intensity value is written to the element position corresponding to the alarm node in the sparse vector to obtain the alarm source vector under the alarm type.

4. The method according to claim 1, characterized in that, The determination of the potential energy of each node in the service dependency graph based on the alarm intensity value of the first parent node and the attenuation coefficient of the first child node at each level includes: The alarm intensity value of the first parent node is determined as the potential energy of the first parent node; the alarm intensity value of the first child node at each level is determined as the initial potential energy of the first child node. The incremental potential energy of the first child node is determined by multiplying the alarm intensity value of the first parent node with the attenuation coefficient of the first child node at each level. For each first child node, the sum of the initial potential energy and the incremental potential energy is determined as the potential energy of the first child node.

5. The method according to claim 1, characterized in that, The alarm system has multiple alarm types; locating the root cause node of the current alarm event from the service dependency graph based on the potential energy of each node in the service dependency graph includes: For each node in the service dependency graph, obtain the potential energy of the node under each alarm type at the current time and the channel weight corresponding to each alarm type; The total potential energy of the node is obtained by weighted summation of the potential energy under multiple alarm types based on the channel weights. Based on the total potential energy of each node in the service dependency graph and the connection relationships between the nodes, the responsibility of each node is determined. Based on the degree of responsibility, the root cause node of the current alarm event is located from the service dependency graph.

6. The method according to claim 5, characterized in that, The determination of the responsibility level of each node based on the total potential energy of each node in the service dependency graph and the connection relationships between the nodes includes: For each node in the service dependency graph, taking the node as the second parent node, determine at least one level of second child nodes connected to the second parent node based on the connection relationship; Determine the sum of the total potential energy of the second child nodes at at least one level; The degree of responsibility of a node is determined based on its total potential energy and the sum of its total potential energy.

7. The method according to claim 5, characterized in that, The step of locating the root cause node of the current alarm event from the service dependency graph based on the degree of responsibility includes: The nodes in the service dependency graph are sorted in descending order of responsibility to form a node sequence; The first N nodes in the node sequence are determined as the root cause nodes of the current alarm event; N is an integer greater than 0. Alternatively, nodes with a responsibility level greater than a preset responsibility level threshold can be identified as the root cause nodes of the current alarm event.

8. The method according to claim 5, characterized in that, The step of weighted summation of potential energy under multiple alarm types based on the channel weights to obtain the total potential energy of the node includes: The potential energy under each alarm type is smoothed to obtain the smoothed potential energy. The total potential energy of the node is obtained by weighted summation of the smooth potential energy under multiple alarm types based on the channel weights.

9. The method according to claim 8, characterized in that, The process of smoothing the potential energy for each alarm type to obtain smoothed potential energy includes: For each alarm type, the first potential energy of the node within a first time window before the current time and the second potential energy within a second time window are obtained; the window length of the first time window is less than the window length of the second time window. Based on the first potential energy and the potential energy of the node at the current moment, determine the third potential energy of the node within the first time window including the current moment. Based on the second potential energy and the potential energy of the node at the current moment, determine the fourth potential energy of the node within the second time window including the current moment; The third potential energy and the fourth potential energy are fused to obtain the smooth potential energy of the node.

10. The method according to any one of claims 1 to 9, characterized in that, Before querying the attenuation coefficient from the first parent node to the first child node from a preset diffusion coefficient table, the method further includes: Determine the call frequency and latency parameters between each pair of connected nodes in the service dependency graph; Based on the call frequency and the delay parameter, determine the target weight of the edge between each pair of connected nodes under different alarm types; Based on the target weight of each edge under different alarm types, a weight matrix is ​​generated for each alarm type; For each alarm type, a Laplace matrix for that alarm type is generated based on the weight matrix for that alarm type. Based on the Laplace matrix, the attenuation coefficient of each node in the service dependency graph is determined; The attenuation coefficient of each node is stored in the diffusion coefficient table.

11. The method according to claim 10, characterized in that, The determination of the attenuation coefficient for each node in the service dependency graph based on the Laplace matrix includes: For each node in the service dependency graph, taking the node as the source node, traverse at least one level of child nodes connected to the source node to obtain the subgraph of the source node; Construct the standard basis vectors of the source node; Based on the element value corresponding to each node in the Laplacian matrix and the standard basis vector, the attenuation coefficient of each node in the subgraph is determined.

12. The method according to any one of claims 1 to 9, characterized in that, The diffusion coefficient table corresponds to a version number; after determining the potential energy of each node in the service dependency graph based on the alarm intensity value of the first parent node and the attenuation coefficient of the first child node at each level, the method further includes: Based on the potential energy of each node, the alarm intensity value, and the diffusion coefficient table, the energy conservation residual is determined; In response to the change in the attenuation coefficient of a node in the service dependency graph determined based on the energy conservation residual, the attenuation coefficient of the node is recalculated to obtain a new attenuation coefficient, and a new diffusion coefficient table is generated using the new attenuation coefficient. Generate a new version number for the new diffusion coefficient table.

13. The method according to any one of claims 1 to 9, characterized in that, The method further includes: Obtain two service dependency graphs when performing root cause analysis on two adjacent alarm events; Determine the edge change rate between the two service dependency graphs; In response to the edge change rate being greater than a preset change rate threshold, the attenuation coefficient of the node is recalculated to obtain a new attenuation coefficient, and a new diffusion coefficient table is generated using the new attenuation coefficient. Generate a new version number for the new diffusion coefficient table.

14. A root cause localization device, characterized in that, The device includes: The parsing module is used to parse the alarm information of the current alarm event in response to the acquisition of alarm information, and to obtain the alarm type and alarm intensity value of the current alarm event. The generation module is used to generate an alarm source vector under the alarm type based on the alarm intensity value; each element in the alarm source vector corresponds to a node in the service dependency graph under the alarm type; The query module is used to query the attenuation coefficient from the first parent node to the first child node from a preset diffusion coefficient table, taking the node corresponding to each non-zero element in the alarm source vector as the first parent node; the first child node is a child node of at least one level connected to the first parent node. The determination module is used to determine the potential energy of each node in the service dependency graph based on the alarm intensity value of the first parent node and the attenuation coefficient of the first child node at each level. The root cause localization module is used to locate the root cause node of the current alarm event from the service dependency graph based on the potential energy of each node in the service dependency graph.

Images