Caton root cause analysis method, device and equipment

Abstract

This application provides a method, apparatus, and device for analyzing the root causes of lag, relating to the field of data processing. The method includes: converting first log data in a first format into second log data in a second format; determining at least one lag event in the second log data based on a preset lag rule base, where a lag event is a set of log entries in the second log data that match a target lag rule in the lag rule base, and the target lag rule is any rule in the lag rule base; and determining the root cause of the lag event based on first device operation data corresponding to the target lag event and the second log data, where the target lag event is any one of the at least one lag event, and the first device operation data is device operation data within the time window corresponding to the target lag event. The method provided in this application improves the efficiency and accuracy of determining lag events and their root causes.

Description

Technical Field

[0001] This application relates to the field of data processing, and more particularly to a method, apparatus, and device for analyzing the root causes of catastrophic loss. Background Technology

[0002] With the rapid development of mobile internet technology, smartphones, tablets, and other smart devices have become indispensable electronic devices in users' daily lives. However, when using Android devices, users often encounter problems such as interface response delays, application crashes, and system lag.

[0003] Currently, troubleshooting lag issues in electronic devices typically relies on technicians capturing log data from the devices and then analyzing this data using their experience to identify lag events and their causes.

[0004] However, existing technical solutions rely heavily on manual processing when troubleshooting lag issues, resulting in low efficiency and accuracy in identifying lag events and their root causes. Summary of the Invention

[0005] This application provides a method, apparatus, and equipment for analyzing the root causes of lag events, in order to solve the technical problem of low efficiency and accuracy in determining lag events and their root causes.

[0006] In a first aspect, this application provides a method for analyzing the root causes of lag, comprising: converting first log data in a first format into second log data in a second format, wherein the second format is a preset standard log format;

[0007] Based on a preset stuttering rule base, at least one stuttering event is determined in the second log data. A stuttering event is a set of log entries in the second log data that match the target stuttering rule in the stuttering rule base. The target stuttering rule is any rule in the stuttering rule base.

[0008] Based on the first device operation data and the second log data corresponding to the target lag event, the root cause of the lag event is determined. The target lag event is any lag event among at least one lag event, and the first device operation data is the device operation data within the time window corresponding to the target lag event.

[0009] The first device operation data includes at least one of device resource usage information, process interaction information, system service information, application service information, and log context information. The root cause of the lag includes at least one of application anomaly, system anomaly, resource contention conflict, and others.

[0010] In one possible implementation of the first aspect, based on a preset stuttering rule base, at least one stuttering event in the second log data is determined, including:

[0011] Based on the parameter threshold rules and keyword rules in the stuttering rule base, determine that the log entries in the second log data that match the parameter threshold rules and / or keyword rules are at least one stuttering event;

[0012] The parameter threshold rule includes a target parameter identifier and a first threshold, which is used to determine whether the value of the target parameter in the second log data exceeds the first threshold.

[0013] Keyword rules include feature text and matching methods, used to determine whether the second log data contains text data that matches the feature text.

[0014] In one possible implementation of the first aspect, the method further includes:

[0015] Construct a corresponding timeline of lag events based on the timestamps of all lag events in at least one lag event;

[0016] Based on the timeline of the lag event, the first device operation data corresponding to the target lag event is determined. The timestamp of the first device operation data is within the target time window. The target time window is a time window determined on the lag event timeline based on the timestamp of the target lag event and the preset duration.

[0017] In one possible implementation of the first aspect, determining the root cause of the lag in the target lag event based on the first device operating data corresponding to the target lag event in at least one lag event includes:

[0018] Identify abnormal data in the first device's operating data. Abnormal data includes data whose values ​​exceed the second threshold range, whose status identifiers match a preset abnormal set, or whose data format conforms to a preset error pattern.

[0019] Based on the abnormal data, determine the root cause of the target lag event.

[0020] In one possible implementation of the first aspect, the root cause of the target lag event is determined based on the abnormal data, including:

[0021] A correlation graph is constructed based on the target lag event and abnormal data. The correlation graph includes the target lag node corresponding to the target lag event and multiple abnormal data nodes corresponding to the abnormal data.

[0022] The association weights between nodes in the association graph are determined using a graph neural network model.

[0023] Based on the association weights between each node, the association path between the target sluggish node and each abnormal data node is determined;

[0024] Based on the fault type corresponding to the target abnormal data node in the associated path, determine the root cause of the target lag event. The target abnormal data node is the abnormal data node with the highest contribution among multiple abnormal data nodes or the abnormal data node at the beginning of the path.

[0025] In one possible implementation of the first aspect, the method further includes:

[0026] The sum of the path propagation strengths of all associated paths of the first abnormal data node is determined as the path propagation strength of the first abnormal data node, where the first abnormal data node is any one of multiple abnormal data nodes.

[0027] The contribution of the first abnormal data node is determined by multiplying the path propagation strength of the first abnormal data node by the deviation of the first abnormal data node. The deviation is used to indicate the degree of deviation between the value of the first abnormal data corresponding to the abnormal data node and the preset benchmark value.

[0028] In one possible implementation of the first aspect, the graph neural network model includes an input layer, at least one graph convolutional layer, and an output layer;

[0029] The input layer is used to preprocess the node attributes of all nodes in the association graph and the connection relationships between all nodes to obtain the first feature vector.

[0030] At least one graph convolutional layer is used to perform at least one aggregation process on the first feature vector to obtain the second feature vector;

[0031] The output layer is used to map the second feature vector to obtain the association weights between nodes in the association graph.

[0032] In one possible implementation of the first aspect, the root cause of the target lag event is determined based on the fault type corresponding to the target abnormal data node in the associated path, including:

[0033] Based on the fault root cause mapping rule base, the root cause of the target lag event is determined according to the fault type corresponding to the target abnormal data node. The fault root cause mapping rule base includes multiple rules indicating the mapping relationship between the fault type corresponding to the data node and the lag root cause.

[0034] In one possible implementation of the first aspect, the method further includes:

[0035] Displays information about the root cause of the lag, including at least one of the following: a timeline of lag events, the root cause of the lag, and a suggested solution for the lag caused by the root cause.

[0036] Secondly, this application provides a calton root cause analysis device, comprising:

[0037] The conversion module is used to convert the first log data in the first format into the second log data in the second format, where the second format is a preset standard log format.

[0038] The first determining module is used to determine at least one lag event in the second log data based on a preset lag rule base. The lag event is a set of log entries in the second log data that match the target lag rule in the lag rule base. The target lag rule is any rule in the lag rule base.

[0039] The second determining module is used to determine the root cause of the lag in the target lag event based on the first device operation data and the second log data corresponding to the target lag event. The target lag event is any lag event among at least one lag event, and the first device operation data is the device operation data within the time window corresponding to the target lag event.

[0040] The first device operation data includes at least one of device resource usage information, process interaction information, system service information, application service information, and log context information. The root cause of the lag includes at least one of application anomaly, system anomaly, resource contention conflict, and others.

[0041] Thirdly, this application provides an electronic device, including: a processor and a memory communicatively connected to the processor;

[0042] The memory stores instructions that the computer executes;

[0043] The processor executes computer-executable instructions stored in memory to implement any of the methods of the first aspect.

[0044] Fourthly, this application provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, are used to implement the method of any one of the first aspects.

[0045] Fifthly, this application provides a computer program product, including a computer program that, when executed by a processor, implements the method of any one of the first aspects.

[0046] The lag root cause analysis method provided in this application automatically matches standardized logs with lag rules in a preset lag rule base to determine the set of log entries that match the lag rules as lag events. This eliminates the reliance on human experience in determining lag events and improves the efficiency and accuracy of lag event determination.

[0047] Moreover, it is not limited to determining the root cause of a lag event based solely on a single log data. It can also correlate and integrate the device operation data corresponding to the lag event as the basis for determining the root cause, thereby improving the richness of the basis for determining the root cause of the lag event, solving the problem of insufficient information in determining the root cause of the lag event, and improving the comprehensiveness and accuracy of determining the root cause of the lag event. Attached Figure Description

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

[0049] Figure 1 A schematic diagram illustrating a scenario for a calorie root cause analysis method provided in an embodiment of this application;

[0050] Figure 2 A flowchart illustrating a method for analyzing the root causes of catarrhal calculi provided in this application embodiment;

[0051] Figure 3 A schematic diagram of the structure of a calorie root cause analysis device provided in an embodiment of this application;

[0052] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application.

[0053] The accompanying drawings illustrate specific embodiments of this application, which will be described in more detail below. These drawings and descriptions are not intended to limit the scope of the concept in any way, but rather to illustrate the concept of this application to those skilled in the art through reference to particular embodiments. Detailed Implementation

[0054] Exemplary embodiments will now be described in detail, examples of which are illustrated in the accompanying drawings. When the following description relates to the drawings, unless otherwise indicated, the same numbers in different drawings denote the same or similar elements. The embodiments described in the following exemplary embodiments do not represent all embodiments consistent with this application. Rather, they are merely examples of apparatuses and methods consistent with some aspects of this application as detailed in the appended claims.

[0055] It should be noted that the calton root cause analysis method, apparatus and equipment provided in this application can be used in the field of data processing, or in any field other than data processing. The application field of the calton root cause analysis method, apparatus and equipment in this application is not limited.

[0056] Figure 1 This is a schematic diagram illustrating a scenario where the cascade root cause analysis method of this application is applied. For example... Figure 1As shown, the customer can interact with the electronic device, which can execute the lag root cause analysis method of this application embodiment to provide interactive services to the user. The electronic device can also interact with the server to obtain relevant data required to execute the lag root cause analysis method of this application embodiment.

[0057] With the rapid development of mobile internet technology, smartphones, tablets, and other smart devices have become indispensable electronic devices in users' daily lives. However, when using Android devices, users often encounter problems such as interface response delays, application crashes, and system lag.

[0058] Currently, troubleshooting lag issues in electronic devices typically relies on technicians capturing log data from the devices. This log data is then analyzed using the technicians' experience to identify lag events and their causes. For example, this often involves technicians manually capturing log data and analyzing key events in the log files (such as process startup / termination, peak resource usage, and error messages), combining this with their personal experience to determine the timing of the lag event and its potential causes.

[0059] However, existing technical solutions rely heavily on manual processing when troubleshooting lag issues, resulting in low efficiency and accuracy in identifying lag events and their root causes.

[0060] The methods, apparatus, devices, storage media, and products for analyzing the root causes of catarrh provided in this application are intended to solve the aforementioned technical problems of the prior art.

[0061] The technical solution of this application and how the technical solution of this application solves the above-mentioned technical problems are described in detail below with specific embodiments. These specific embodiments can be combined with each other, and the same or similar concepts or processes may not be described again in some embodiments. The embodiments of this application will be described below with reference to the accompanying drawings.

[0062] Figure 2 This is a flowchart illustrating a method for analyzing the root causes of catarrh in an embodiment of this application, as shown below. Figure 2 As shown, the method includes:

[0063] S201. The electronic device converts the first log data in the first format into the second log data in the second format, where the second format is a preset standard log format.

[0064] The first format of log data refers to raw logs generated by terminal devices of different brands, models, or system versions, which differ in field definitions, timestamp formats, and tag naming (heterogeneity). Examples include various types of log data from Android devices such as System Log, Event Log, Application Process Log, CPU / Memory / Disk I / O Usage Log, and Graphics Processing Unit (GPU) rendering logs.

[0065] Second-format log data refers to log data in a predefined, uniform standard format (such as a uniform JSON structure or fixed-width text), which includes standardized fields such as time, process ID, thread ID, log level, tag, and content.

[0066] For example, an electronic device can use a parsing adapter to identify the source type of the raw log, extract key information (such as time and error content), and map and fill it into a standard template to obtain log data in a standard format.

[0067] S202. The electronic device determines at least one lag event in the second log data based on a preset lag rule base. The lag event is a set of log entries in the second log data that match the target lag rule in the lag rule base. The target lag rule is any rule in the lag rule base.

[0068] The stuttering rule base stores a set of predefined logical conditions, each condition corresponding to a known stuttering feature (such as "main thread blocked for more than M milliseconds" or "a specific keyword appears").

[0069] A stuttering event refers to a group of consecutive or related log entries that together satisfy a stuttering rule or multiple stuttering rules and are marked as an independent fault unit.

[0070] For example, the electronic device can iterate through the second log data, comparing each log entry or log sequence with a "target stutter rule" in the rule base. Once a log sequence fully matches a rule (e.g., an input dispatching timeout is detected and its duration is >5 seconds), the electronic device can package and mark the sequence as a "stutter event." The target stutter rule is any stutter rule in the stutter rule base.

[0071] For example, the rule is: the log must contain the keyword "InputDispatching Timed out" with a time difference greater than 5 seconds. The electronic device finds lines 100 to 150 in the standard format log containing this keyword and related stack traces, with a time span of 6 seconds. Therefore, the electronic device can mark these lines 100 to 150 as "Event ID_001: Input event timeout".

[0072] S203. The electronic device determines the root cause of the lag in the target lag event based on the first device operation data and the second log data corresponding to the target lag event. The target lag event is any lag event among at least one lag event, and the first device operation data is the device operation data within the time window corresponding to the target lag event.

[0073] The first device operation data includes at least one of device resource usage information, process interaction information, system service information, application service information, and log context information. The root cause of the lag includes at least one of application anomaly, system anomaly, resource contention conflict, and others.

[0074] The device resource usage information may include CPU / memory / disk I / O usage data during the lag period; process interaction information may include data such as application process startup / exit and inter-process communication records before and after the lag; system service information may include system services (such as ActivityManager, WindowManager, and PackageManager) and hardware driver modules involved in the second log data, which can be used to determine whether there are system-level compatibility issues; application service information may include information such as the package name and version number of the lag application, extracting the time consumption data of key operations within the application (such as database queries, network requests, and UI rendering) to locate performance bottlenecks at the application code level. The device operation data in this embodiment may also include other information, which is not limited here.

[0075] The first device operation data refers to the dynamic status data recorded by the device within the time window of the lag event, excluding the log text. For example, it may include CPU / memory usage, inter-process communication frequency, lock contention status, service response latency, etc.

[0076] The root cause of a lag event refers to the essential reason for the event, such as application anomalies (e.g., insufficient application code optimization, memory leaks), system anomalies (e.g., system scheduling algorithm defects, driver incompatibility), resource contention conflicts (e.g., multiple applications simultaneously vying for core resources), and others. The root causes of lag events in this embodiment may also include other information, which is not limited here.

[0077] Electronic devices not only analyze log text (phenomena), but also extract "first device operation data" (environmental status) within the same time window. Through a pre-defined mapping logic or algorithm model, the "log phenomena" and "resource status" are cross-validated. For example, if the log shows lag, while the device operation data shows full CPU load and a non-critical process with extremely high resource consumption, it is determined to be "resource contention"; if the CPU is idle but the main thread is unresponsive, it is determined to be "application internal deadlock".

[0078] For example, log data indicates that the main thread is waiting for lock Lock_A. Device operation data indicates that another process holding Lock_A has a CPU utilization of 90% (high load) and less than 10% memory remaining. Electronic devices can combine the "waiting for lock" phenomenon in the logs with the "high load / low memory" state in the operation data to determine that the root cause of the stuttering event is "thread blocking caused by resource contention," rather than a simple application code logic error.

[0079] In this embodiment, the electronic device determines the root cause of the target lag event based on the first device operation data and the second log data corresponding to the target lag event. It can determine the root cause of the target lag event according to the mapping relationship between device operation data and lag root causes in the preset database; or it can determine it according to a trained machine learning model, which is a machine learning model that is trained on a large number of lag log samples and automatically learns lag features and root cause correlation rules.

[0080] In this embodiment of the application, the electronic device determines the lag event and its root cause either immediately when the device lags or afterward based on the device logs. The specific determination is not limited here.

[0081] In this possible implementation, standardized logs are automatically matched with lag rules in a pre-defined lag rule base to determine the set of log entries that match the lag rules as lag events. This eliminates the reliance on human experience in determining lag events and improves the efficiency and accuracy of lag event determination.

[0082] Moreover, it is not limited to determining the root cause of a lag event based solely on a single log data. It can also correlate and integrate the device operation data corresponding to the lag event as the basis for determining the root cause, thereby improving the richness of the basis for determining the root cause of the lag event, solving the problem of insufficient information in determining the root cause of the lag event, and improving the comprehensiveness and accuracy of determining the root cause of the lag event.

[0083] In some embodiments, the electronic device determines at least one stuttering event in the second log data based on a preset stuttering rule base, including:

[0084] The electronic device determines, based on the parameter threshold rules and keyword rules in the stuttering rule base, that the log entries in the second log data that match the parameter threshold rules and / or keyword rules are at least one stuttering event;

[0085] The parameter threshold rule includes a target parameter identifier and a first threshold, which is used to determine whether the value of the target parameter in the second log data exceeds the first threshold.

[0086] Understandably, parameter threshold rules are a quantitative judgment logic, composed of "target parameter identifiers" (such as CPU utilization, frame rate (FPS), memory usage, method execution time, etc.) and "first thresholds" (specific numerical limits, such as 80%, 16ms, 500MB). They can be used to capture performance anomalies that are numerically reflected in logs. Examples include sustained CPU utilization ≥80% for more than 3 seconds, memory leak rate ≥50MB / minute, GPU rendering frame time ≥16ms, and application process response timeout ≥2 seconds.

[0087] Keyword rules include feature text and matching methods, used to determine whether the second log data contains text data that matches the feature text.

[0088] Understandably, keyword rules are a qualitative text-based judgment logic, composed of "feature text" (such as specific error codes like ANR, exception stack traces like Deadlock, Timeout, and garbage collection overhead exceeding GC_OVERHEAD_LIMIT_EXCEEDED, resource contention, etc.) and "matching methods" (such as exact matching, regular expression matching, and fuzzy inclusion). They can be used to capture logical errors or status anomalies that are expressed in textual descriptions.

[0089] In this embodiment of the application, the stuttering rule base may include other rules in addition to parameter threshold rules and keyword rules, which are not limited here.

[0090] Electronic devices can use a dual-matching mechanism to determine at least one stuttering event in the second log data based on parameter threshold rules and keyword rules in the stuttering rule base. This dual-matching mechanism means that the electronic device has the ability to handle both numerical and textual anomalies, allowing the use of one rule alone or in combination of the two rules to define a stuttering event.

[0091] For example, when an electronic device traverses standardized second log data using an algorithm similar to regular expression matching, it can execute two types of detection logic in parallel. One is numerical detection, which extracts the performance metric values ​​carried in the logs and compares them with preset "parameter threshold rules." If the value exceeds (or falls below) the set "first threshold," the log entry is marked as a suspected lag point. The other is text detection, which scans the content fields of the logs and uses the matching method in the "keyword rules" to search for the existence of specific "feature text." If a match is found, the log entry is marked as a suspected lag point.

[0092] Then, the log entries marked as suspected lag points, i.e. log entries hit by any of the above rules or combinations of rules, are confirmed as "lag events".

[0093] For example, rule A is set as follows: target parameter identifier = FrameRenderTime (frame rendering time), with a first threshold of less than or equal to 16ms. The log data is: {"ts":"...","param":"FrameRenderTime","value":45}. Since 45ms > 16ms, the rule is triggered, and the electronic device can determine that this entry is a stuttering event (frame drop).

[0094] For example, rule B is set as follows: CPU_Usage > 90% and the keyword "GC overhead" must be present simultaneously. A certain log data entry shows that the CPU monitoring log shows 95% for a certain period, and the application log prints "GC overhead limit exceeded". Because this log data meets both numerical and textual conditions, the electronic device can confirm it as a stuttering event (resource exhaustion type).

[0095] This possible implementation avoids the limitations of a single detection method by introducing a two-dimensional rule of "parameter threshold" and "keyword". It can identify both lags with no obvious errors but deteriorating performance indicators and explicit lags with clear error logs. This solves the problem that traditional methods are prone to missing performance degradation without errors.

[0096] Furthermore, it allows for flexible configuration of quantitative indicators or qualitative text for different scenarios, making the definition of lag events more closely aligned with actual business scenarios and avoiding false alarms or missed alarms caused by overly rigid rules. Moreover, by complementing numerical and textual data (especially when used in combination), it can filter out occasional fluctuations in a single indicator or non-critical warning messages, ensuring the authenticity and severity of identified lag events.

[0097] In some embodiments, the method further includes:

[0098] S204. The electronic device constructs a corresponding lag event timeline based on the timestamps of all lag events in at least one lag event.

[0099] S205. The electronic device determines the first device operation data corresponding to the target lag event based on the lag event timeline. The timestamp of the first device operation data is within the target time window. The target time window is a time window determined on the lag event timeline based on the timestamp of the target lag event as the base point and according to the preset duration.

[0100] The stuttering event timeline is a continuous time series view that arranges all identified discrete stuttering events in chronological order of their occurrence timestamps. It can intuitively display the frequency, distribution, and timing of stuttering events. In addition, device operation data can also be displayed on the stuttering event timeline based on the timestamps of the device operation data.

[0101] The target time window is a specific time period defined by extending a preset duration (e.g., 5 seconds before and after) forward and backward from the time of occurrence of a specific "target lag event".

[0102] Electronic devices can avoid using fixed global data and instead dynamically extract device operation data within a time window around each stuttering event based on its specific position on the timeline.

[0103] For example, the electronic device can extract the timestamps of all identified stuttering events and construct a "stuttering event timeline" in chronological order, establishing the coordinates of each event in the time dimension. Then, when it is necessary to analyze a "target stuttering event", the electronic device can use the timestamp of the target stuttering event as the base point and combine it with a preset duration (such as advancing T1 seconds and advancing T2 seconds) to delineate a unique "target time window" on the timeline.

[0104] Then, the electronic device filters and extracts data (such as CPU, memory, and IO status) whose timestamps fall within the "target time window" from the device operation data, as the exclusive analysis basis for the target lag event (first device operation data).

[0105] For example, the timeline records three stuttering events, which occurred at 10:00:00, 10:05:00, and 10:10:00 respectively.

[0106] The target lag event occurring at 10:05:00 needs to be analyzed. The duration window is a preset 30 seconds before and after. The electronic device can determine the target time window as [10:04:30, 10:05:30]. Then, the electronic device only extracts CPU high load records and memory leak logs within this 30-second window, ignoring data from other times to avoid interference from irrelevant data.

[0107] In this embodiment, the first device operation data corresponding to the target lag event can be determined based on the lag event timeline, i.e., the data used to determine the root cause of the target lag event can be filtered. Alternatively, filtering can be performed in other ways, such as determining the corresponding log data based on the lag event scenario (e.g., startup lag, swiping lag, background running lag, etc.). Other filtering methods are also possible, and specific methods are not limited here.

[0108] This possible implementation achieves precise alignment of root cause analysis data by constructing a timeline of lag events and dynamically defining target time windows. This overcomes the limitations of traditional methods that use fixed time periods or global average data for analysis, ensuring that only equipment operating status data relevant to the moment the lag occurred is acquired, eliminating interference from data in irrelevant time periods. By strictly limiting equipment operating data to a specific window surrounding the lag event, a close connection between the "phenomenon" and the "state" in the time dimension is ensured, resolving the root cause misjudgment problem caused by mismatched data time spans. This improves the accuracy and timeliness of root cause localization.

[0109] In some embodiments, the electronic device determines the root cause of a target lag event based on first device operating data corresponding to the target lag event in at least one lag event, including:

[0110] The electronic device determines abnormal data in the first device's operating data. Abnormal data includes data whose values ​​exceed a second threshold range, whose status identifiers match a preset abnormal set, or whose data format conforms to a preset error pattern.

[0111] Electronic devices determine the root cause of the lag event based on abnormal data.

[0112] Abnormal data refers to a specific subset of data in the "first equipment operation data" (i.e., equipment status data within the target time window) that is identified as deviating from the normal baseline or meeting fault characteristics.

[0113] The second threshold range is a dynamic or static safety range set for numerical indicators (such as CPU utilization, memory availability, and I / O latency). Data exceeding this range (too high or too low) is considered abnormal.

[0114] The default set of exceptions is a list of illegal or high-risk states (such as Deadlock, Zombie, OOM_Killed) defined for status indicators (such as process status, lock status, network status).

[0115] Preset error modes are specific fault templates defined for data structures or sequences (such as "three consecutive packet losses", "the order of acquiring and releasing the lock is reversed", "null pointer reference format", etc.).

[0116] For example, an electronic device can first scan all device operation data within a target time window and filter out "abnormal data" using three filters:

[0117] One method is to filter values ​​by checking if they exceed a "second threshold range" (e.g., CPU > 95% or available memory < 50MB). Another method is to check if the status indicator falls into a "preset anomaly set" (e.g., detecting a WaitForGcToComplete state). A third method is to check if the data sequence or format conforms to a "preset error pattern" (e.g., detecting a specific deadlock stack arrangement pattern). These methods filter out anomalous data.

[0118] The selected abnormal data is then used as direct evidence to directly pinpoint the corresponding "root cause of the lag" through a pre-defined mapping rule base or inference engine. For example, if the abnormal data is "memory is below the threshold" and the status is "frequent GC", the mapped root cause is "resource contention".

[0119] For example, when a target lag event occurs and the application interface freezes, the device operation data within the time window includes: CPU utilization curve, thread lock status list, and memory reclamation log.

[0120] If an electronic device detects that the main thread has held the lock for 2500ms, exceeding the second threshold range (set to 500ms), it will mark it as abnormal data A. Furthermore, if it detects that a background process's status is Blocked, matching the preset exception set {Blocked, Waiting}, it will mark it as abnormal data B.

[0121] Then, the electronic device combines abnormal data A (long lock holding) and abnormal data B (thread blocking) and determines, according to the mapping rules, that the root cause of the lag is "resource deadlock caused by thread lock contention", that is, "resource contention conflict".

[0122] In this possible implementation, root cause analysis is automated and standardized by preprocessing complex equipment operation data into clearly defined "abnormal data." Specifically, massive amounts of raw operation data are compressed into a small amount of key "abnormal data," shielding the interference of normal fluctuation data. This allows the root cause determination logic to focus only on core fault characteristics, reducing the difficulty of calculation and analysis.

[0123] Furthermore, by replacing human experience-based judgment with a quantified "second threshold," a clearly defined "anomaly set," and a structured "error pattern," the subjective differences in human experience regarding "what is an anomaly" are eliminated, ensuring the consistency of anomaly data judgment standards. This improves the comprehensiveness and accuracy of root cause localization and reduces the occurrence of missed cases caused by single-dimensional analysis.

[0124] In some embodiments, the electronic device determines the root cause of a target lag event based on abnormal data, including:

[0125] The electronic device first constructs a correlation graph based on the target lag event and abnormal data. The correlation graph includes the target lag node corresponding to the target lag event and multiple abnormal data nodes corresponding to the abnormal data. Then, the electronic device determines the correlation weight between each node in the correlation graph through a graph neural network model. Based on the correlation weight between each node, the electronic device determines the correlation path between the target lag node and each abnormal data node. The electronic device then determines the root cause of the lag event based on the fault type corresponding to the target abnormal data node in the correlation path. The target abnormal data node is the abnormal data node with the highest contribution among multiple abnormal data nodes or the abnormal data node at the beginning of the path.

[0126] The electronic device uses the target lag event as the central node (target lag node) and all abnormal data detected within the time window as surrounding nodes to construct an initial correlation graph. This graph is then input into a pre-trained graph neural network model. The graph neural network model, combining historical fault databases and the current context, automatically calculates the correlation weight of each edge (connection between nodes), quantifying the probability that abnormal data causes lag. Based on the calculated weights, the graph neural network model searches for and determines the optimal correlation paths from the lag node to each abnormal node, identifying the main fault propagation chains. Finally, within the determined paths, the "target abnormal data node" with the highest contribution or located at the beginning of the path is located. The fault type represented by this node (such as "memory leak" or "disk I / O bottleneck") is directly determined as the root cause of the lag.

[0127] Among them, the correlation graph (causal correlation graph) is a graph structure data model that can abstract the "target lag event" into target lag nodes and the various types of "abnormal data" (such as high CPU, deadlock, IO blocking, etc.) into abnormal data nodes. The connections between nodes represent the potential causal or temporal relationships between them.

[0128] Graph Neural Networks (GNNs) are deep learning models specifically designed for processing graph-structured data. In this embodiment, they can be used to learn complex nonlinear relationships between nodes, calculating the association weights (i.e., the probability of causal relationships) between nodes through a message passing mechanism.

[0129] The association path is the connection link in the association graph that traces back from the "target lag node" to a certain "abnormal data node", representing the logical trajectory of the lag propagation.

[0130] The target abnormal data node is a key node that the model determines to have the highest contribution (the greatest impact on the lag) or is located at the beginning of the path (the source of the fault) in multiple related paths. The corresponding fault type is the root cause of the lag event.

[0131] For example, an application experiences severe lag. Electronic devices can construct a graph centered on the target lag event. This graph can include surrounding nodes, such as node A: CPU 99%, node B: disk I / O wait, and node C: database lock timeout.

[0132] Calculations using a graph neural network model revealed that the target lag node has a weight of 0.3 with node A, 0.4 with node B, but a high weight of 0.9 with node C. Further path analysis showed that node C caused IO congestion at node B (lock waiting leading to I / O buildup), which in turn triggered IO congestion at node A (resource contention causing CPU spikes), ultimately leading to the target lag node. The associated path is: Node C -> Node B -> Node A -> Lag. Since node C is at the beginning of the path and contributes the most to the overall chain, the electronic device can be identified as having a "database lock contention" fault type corresponding to node C, rather than the apparent high CPU usage.

[0133] In this possible implementation, a graph neural network is introduced to construct an association graph, achieving a leap from "rule matching" to "intelligent reasoning":

[0134] Solving the problem of multi-factor coupling: Traditional methods struggle to distinguish the true culprit among multiple concurrent anomalies. This solution uses GNN to calculate correlation weights, effectively separating accompanying "secondary anomalies" (such as high CPU usage caused by lock contention), accurately locating the source node, and solving the problem of root cause misjudgment in complex scenarios.

[0135] Uncovering hidden causal relationships: By leveraging the transitivity of graph structures, we can discover indirect, chain-like failure propagation paths (such as A->B->C->stuttering), capture deep logical connections that are difficult to define with manual rules, and significantly improve the depth of root cause analysis.

[0136] Adaptive learning capability: Graph neural networks can continuously optimize weight calculation strategies through training on historical data. As data accumulates, the model's ability to recognize new or complex stuttering patterns will automatically improve, eliminating the need for frequent manual updates to the rule base and enhancing the system's long-term maintainability and generalization ability.

[0137] In some embodiments, a graph neural network model may include an input layer, at least one graph convolutional layer, and an output layer;

[0138] The input layer of the graph neural network model can be used to preprocess the node attributes of all nodes in the association graph and the connection relationships between all nodes to obtain the first feature vector.

[0139] At least one graph convolutional layer of a graph neural network model can be used to perform at least one aggregation process on the first feature vector to obtain the second feature vector;

[0140] The output layer of the graph neural network model can be used to map the second feature vector to obtain the association weights between nodes in the association graph.

[0141] For example, an electronic device determines the association weights between nodes in an association graph using a graph neural network model, which may specifically include:

[0142] The electronic device first determines the initial feature vectors of all nodes in the association graph and the connection relationships between all nodes. Then, it inputs the initial feature vectors of all nodes in the association graph and the connection relationships between all nodes into the input layer of the graph neural network model. The graph neural network model performs input layer feature mapping to obtain the corresponding node feature matrix.

[0143] Then, based on at least one graph convolutional layer of the graph neural network model, a weighted fusion is performed according to the connection relationship between all nodes, the feature information of adjacent nodes, and the initial weights of the edges in the associated graph, so as to obtain the updated node feature matrix.

[0144] Finally, the updated node feature matrix is ​​input into the output layer of the graph neural network model, and the correlation weights between each node are output through the feature mapping of the output layer.

[0145] For example, electronic devices determine the association weights between nodes in an association graph using a graph neural network model, which may specifically include:

[0146] I. Input layer processing.

[0147] The electronic device first reads the raw data from all nodes in the correlation graph. These nodes include target lag nodes representing the "target lag event" and anomalous data nodes representing various system anomalies (such as CPU overload, memory leak, network latency, etc.). Each node carries a corresponding initial feature vector, such as the duration of the anomaly, the degree of numerical deviation, and the frequency of occurrence.

[0148] At the same time, electronic devices can also read the connection relationships between nodes (i.e., who is connected to whom) and the initial state of the edges. This can be used to determine the possible propagation paths of faults.

[0149] The electronic device then inputs the initial feature vectors of all nodes into the input layer of the graph neural network model.

[0150] This input layer can uniformly transform (map) different types of raw features (such as time in milliseconds, percentage values) into initial node feature representations with consistent dimensions that can be processed by the graph neural network model, thereby obtaining the initial node feature matrix.

[0151] II. Graph Convolution Layer Processing.

[0152] For each target node in the graph, the graph convolutional layer automatically identifies and locks all its neighbor nodes (i.e. directly connected nodes) based on the previously input connection relationships, and then obtains the neighbor feature information of these neighbor nodes in the previous layer and performs weighted fusion.

[0153] Then, the weighted and fused neighbor feature information of the previous layer is fused with the feature information of the target node itself in the previous round to obtain the updated feature vector of the target node.

[0154] After multiple layers of processing in the graph convolutional layer, a higher-order node feature matrix is ​​obtained, which is the updated node feature matrix.

[0155] III. Output layer processing.

[0156] After multi-layer processing in the graph convolutional layers, the updated node feature matrix is ​​input into the model's output layer. The model's output layer can compare the feature similarity between each node. This feature similarity can be used to indicate the connection strength between nodes, i.e., the strength of the causal relationship between them. For example, the feature similarity between the target sluggish node and each abnormal data node can be compared to determine the strength of the causal relationship between the target sluggish node and each abnormal data node.

[0157] In some embodiments, the target anomalous data node is the anomalous data node with the highest contribution among multiple anomalous data nodes or the anomalous data node located at the beginning of the path. Therefore, it is understood that the electronic device also needs to calculate the contribution of the anomalous data node, and thus the method further includes:

[0158] The electronic device determines the sum of the path transmission strengths of all associated paths of the first abnormal data node as the path transmission strength of the first abnormal data node, where the first abnormal data node is any one of multiple abnormal data nodes.

[0159] The electronic device determines the contribution of the first abnormal data node by multiplying the path transmission strength of the first abnormal data node by the deviation of the first abnormal data node. The deviation is used to indicate the degree of deviation between the value of the first abnormal data corresponding to the abnormal data node and a preset benchmark value.

[0160] That is, electronic devices accurately calculate the destructive power of each abnormal node through two dimensions (topology + numerical features).

[0161] Specifically, the electronic device first traverses the correlation graph to find all possible paths from the "first abnormal data node" to the "target sluggish node". The weights of the connections between each segment on each path are aggregated (e.g., accumulated or weighted summation) to obtain the sum of the path transmission strength of the node, i.e., the topological influence of the node.

[0162] Then, extract the original data value corresponding to the node, calculate the difference or ratio between it and the system's preset benchmark value, and obtain the deviation. Then multiply the above two indicators (contribution = path transmission strength × deviation) to obtain the node's contribution.

[0163] If a node is at the beginning of a path but its value fluctuates very little (low deviation), its contribution will be reduced and it will be considered a secondary factor. If a node has a very large value but is at the end of the propagation chain (weak transmission strength), its contribution will also be suppressed and it will be considered a secondary phenomenon.

[0164] Finally, the electronic device compares the contribution of all abnormal nodes and selects the one with the highest score as the target abnormal data node. The fault type corresponding to the target abnormal data node is the root cause.

[0165] For example, in the correlation graph, there are two candidate anomalous nodes. Node A (memory leak) is at the beginning of the path, with a high path propagation strength (0.9). Its current memory usage is 80%, the baseline is 40%, and the deviation is 2.0 times. Node B (CPU instantaneous spike) is in the middle of the path, with a medium path propagation strength (0.5). Its current CPU usage is 99%, the baseline is 30%, and the deviation is 3.3 times.

[0166] The electronic device can calculate the contribution of node A and node B. Specifically, the contribution of node A = 0.9 (intensity) × 2.0 (deviation) = 1.8; the contribution of node B = 0.5 (intensity) × 3.3 (deviation) = 1.65.

[0167] Although node B's values ​​deviate more drastically (higher CPU usage), node A has a greater logical weight in the fault propagation chain and a higher overall score (1.8 > 1.65). Therefore, electronic devices can target node A (memory leak) as the abnormal data node, i.e., the root cause of the lag, avoiding being misled by superficially severe CPU spikes.

[0168] In this possible implementation, a multiplicative mechanism of "path transmission strength" and "deviation" is introduced to achieve multidimensional quantification and false positive elimination of root cause determination. This prevents misjudgment based solely on large numerical fluctuations that are not the root cause (such as secondary resource contention), as well as "missed judgments" that are at the critical logical starting point but have small numerical fluctuations (such as early configuration errors or slow starts).

[0169] By strengthening the weights of starting nodes and key hub nodes in the graph through "path propagation strength," the algorithm is ensured to tend to trace the source of fault propagation, thus improving the root cause localization capability. Furthermore, the deviation calculation relies on the comparison between real-time data and baseline values, allowing the contribution assessment to dynamically adjust with changes in the system load baseline, adapting to anomaly judgment criteria under different operating environments, and improving the accuracy of root cause determination.

[0170] In some embodiments, the electronic device determines the root cause of the target lag event based on the fault type corresponding to the target abnormal data node in the associated path, including:

[0171] Electronic devices determine the root cause of a lag event based on a fault root cause mapping rule base and the fault type corresponding to the target abnormal data node. The fault root cause mapping rule base includes multiple rules indicating the mapping relationship between the fault type corresponding to the data node and the lag root cause.

[0172] For example, the electronic device can acquire the "target abnormal data node" determined in the previous steps and read its corresponding specific fault type label. Then, the electronic device queries the fault root cause mapping rule base to find mapping rules containing that fault type. It can be a one-to-one mapping, for example, a single severe abnormality directly corresponds to a root cause. It can also be a many-to-one mapping, where multiple concurrent minor abnormalities (such as high CPU + high memory) collectively point to a comprehensive root cause (such as resource exhaustion).

[0173] If a match is found, the electronic device immediately invokes the root cause of the lag defined in the rule as the final conclusion, and optionally includes a suggested repair strategy.

[0174] The root cause mapping rule base is a predefined, standardized knowledge base that stores the conversion logic from "lower-level anomaly characteristics" to "higher-level business root causes." It can transform technical data node labels into understandable fault conclusions.

[0175] Fault type refers to the technical state or indicator abnormality directly represented by the target abnormal data node (such as "thread pool full", "disk I / O latency > 500ms", "null pointer exception"). This is a fine-grained, specific description of the phenomenon.

[0176] The root cause of a bottleneck refers to the final diagnostic conclusion derived after mapping through a rule base (such as "concurrency resource exhaustion," "storage subsystem bottleneck," "code logic defect," etc.). This is a coarse-grained, general classification of causes, usually corresponding to specific optimization directions or responsible modules.

[0177] Mapping rules are specific entries in the rule base. They can define the logic to derive a specific "root cause of a block" from one or more combinations of "fault types". For example, if the fault type is lock wait or deadlock, the root cause is determined to be the failure of the thread synchronization mechanism.

[0178] For example, after analyzing the graph neural network model, the "target abnormal data node" was identified as Node_X. The fault types corresponding to Node_X are "main thread holds lock for more than 2 seconds" and "circular dependency wait detected".

[0179] The electronic device queries the root cause mapping rule base and determines that rule R-102 is matched: IF (lock holding timeout OR circular dependency) THEN stutter root cause = "multi-threaded deadlock or long lock contention". Therefore, the electronic device can determine that the root cause of this stutter is "multi-threaded deadlock or long lock contention", rather than the apparent "thread blocking".

[0180] This possible implementation achieves a closed loop from "data discovery" to "knowledge-based decision-making" by introducing a root cause mapping rule base. By determining a limited number of standardized business root cause categories based on underlying technical indicators (fault types), it eliminates the problem of inconsistent naming of the same phenomenon by human experience, facilitating fault statistics and integration with automated operation and maintenance.

[0181] In some embodiments, the method further includes:

[0182] S206. The electronic device displays the root cause information of the lag, which includes at least one of the following: a timeline of lag events, the root cause of the lag, and a lag resolution suggestion corresponding to the root cause of the lag.

[0183] Among them, the lag resolution suggestions are targeted optimization strategies or repair solutions (such as code snippets, configuration modification instructions, and architecture adjustment suggestions) retrieved from a pre-set knowledge base based on the identified "root cause of lag". These suggestions can be used to guide users to quickly eliminate the fault.

[0184] For example, if an application experiences frame drops during runtime, the system can analyze the data and display a timeline curve indicating FPS trends, marking the points where the stuttering occurred. It can also show the root cause of the stuttering as "main thread resource loading blocking." Furthermore, it can display suggested solutions, such as "Check the resource preloading strategy to avoid dynamically loading large images at runtime."

[0185] In this embodiment, standardized logs are automatically matched with lag rules in a preset lag rule base to determine the set of log entries matching the lag rules as lag events. Moreover, it is not limited to determining the root cause of a lag event based solely on a single log data; it can also associate and integrate the device operation data corresponding to the lag event as the basis for determining the root cause. This eliminates the reliance on human experience in determining lag events, enhances the richness of the basis for determining the root cause of lag events, solves the problem of insufficient information in determining the root cause of lag events, and improves the comprehensiveness and accuracy of determining lag events and their root causes.

[0186] Furthermore, by constructing a correlation graph and utilizing graph neural networks to deduce fault propagation paths, it overcomes the limitations of traditional rules and accurately traces the root causes of multi-factor coupled scenarios. It calculates contribution by multiplying "path propagation strength" and "numerical deviation," taking into account both logical importance and data severity, effectively eliminating secondary interference and improving the accuracy of root cause identification. Combined with a mapping rule base, technical features are transformed into standardized conclusions. This achieves automatic transformation from complex data to precise root causes, shortening the fault location and repair cycle.

[0187] Figure 3 This is a schematic diagram of the structure of a calorie root cause analysis device provided in an embodiment of this application, as shown below. Figure 3 As shown, the calorie root cause analysis device 300 provided in this embodiment includes:

[0188] The conversion module 301 is used to convert the first log data in the first format into the second log data in the second format, wherein the second format is a preset standard log format;

[0189] The first determining module 302 is used to determine at least one lag event in the second log data based on a preset lag rule library. The lag event is a set of log entries in the second log data that match the target lag rule in the lag rule library. The target lag rule is any rule in the lag rule library.

[0190] The second determining module 303 is used to determine the root cause of the lag in the target lag event based on the first device operation data and the second log data corresponding to the target lag event. The target lag event is any lag event among at least one lag event, and the first device operation data is the device operation data within the time window corresponding to the target lag event.

[0191] The first device operation data includes at least one of device resource usage information, process interaction information, system service information, application service information, and log context information. The root cause of the lag includes at least one of application anomaly, system anomaly, resource contention conflict, and others.

[0192] In one possible implementation, the first determining module 302 is specifically used to: determine, based on the parameter threshold rules and keyword rules in the stuttering rule base, that the log entries in the second log data that match the parameter threshold rules and / or keyword rules are at least one stuttering event; wherein, the parameter threshold rules include a target parameter identifier and a first threshold, used to determine whether the value of the target parameter in the second log data exceeds the first threshold; the keyword rules include feature text and a matching method, used to determine whether the second log data contains text data that matches the feature text.

[0193] In one possible implementation, the Karnone root cause analysis device further includes:

[0194] Module 304 is used to construct a corresponding timeline of stuttering events based on the timestamps of all stuttering events in at least one stuttering event.

[0195] The third determining module 305 is used to determine the first device operation data corresponding to the target lag event based on the lag event timeline. The timestamp of the first device operation data is within the target time window. The target time window is a time window determined on the lag event timeline based on the timestamp of the target lag event as the base point and according to the preset duration.

[0196] In one possible implementation, the second determining module 303 is specifically used to: determine abnormal data in the first device operation data, wherein the abnormal data includes data whose value exceeds the second threshold range, whose status identifier hits a preset abnormal set, or whose data format conforms to a preset error pattern; and determine the root cause of the target lag event based on the abnormal data.

[0197] In one possible implementation, the second determining module 303 is specifically used to: construct a correlation graph based on the target lag event and abnormal data, the correlation graph including the target lag node corresponding to the target lag event and multiple abnormal data nodes corresponding to the abnormal data; determine the correlation weights between each node in the correlation graph through a graph neural network model; determine the correlation path between the target lag node and each abnormal data node based on the correlation weights between each node; determine the lag root cause of the target lag event according to the fault type corresponding to the target abnormal data node in the correlation path, the target abnormal data node being the abnormal data node with the highest contribution among multiple abnormal data nodes or the abnormal data node at the beginning of the path.

[0198] In one possible implementation, the second determining module 303 is specifically used to: determine the sum of the path transmission strengths of all associated paths of the first abnormal data node as the path transmission strength of the first abnormal data node, wherein the first abnormal data node is any one of a plurality of abnormal data nodes; determine the product of the path transmission strength of the first abnormal data node and the deviation of the first abnormal data node as the contribution of the first abnormal data node, wherein the deviation is used to indicate the degree of deviation between the value of the first abnormal data corresponding to the abnormal data node and a preset benchmark value.

[0199] In one possible implementation, the graph neural network model includes an input layer, at least one graph convolutional layer, and an output layer;

[0200] The input layer is used to preprocess the node attributes of all nodes in the association graph and the connection relationships between all nodes to obtain the first feature vector.

[0201] At least one graph convolutional layer is used to perform at least one aggregation process on the first feature vector to obtain the second feature vector;

[0202] The output layer is used to map the second feature vector to obtain the association weights between nodes in the association graph.

[0203] In one possible implementation, the second determining module 303 is specifically used to: determine the root cause of the target lag event based on the fault type corresponding to the target abnormal data node, according to the fault root cause mapping rule library. The fault root cause mapping rule library includes multiple mapping relationship rules between the fault type corresponding to the data node and the lag root cause.

[0204] In one possible implementation, the Karnone root cause analysis device further includes:

[0205] The display module 306 is used to display the root cause information of the lag, which includes at least one of the following: a lag event timeline, the root cause of the lag, and a lag resolution suggestion corresponding to the root cause of the lag.

[0206] The calorie root cause analysis device provided in this embodiment can execute the method provided in the above method embodiment. Its implementation principle and technical effect are similar, and will not be described in detail here.

[0207] Figure 4 This is a schematic diagram of the structure of an electronic device provided in an embodiment of this application. Figure 4As shown, the electronic device 400 may include a memory 401 and a processor 402. Optionally, the electronic device may also include a transceiver 403, wherein the memory 401 and the processor 402 communicate with each other; for example, the memory 401, the processor 402 and the transceiver 403 may communicate via a communication bus 404, the memory 401 is used to store a computer program, and the processor 402 executes the computer program to implement the method of the above embodiments.

[0208] Optionally, the aforementioned processor can be a Central Processing Unit (CPU), or other general-purpose processors, digital signal processors (DSPs), application-specific integrated circuits (ASICs), etc. The general-purpose processor can be a microprocessor or any conventional processor. The steps in the method embodiments disclosed in this application can be directly implemented by a hardware processor, or implemented by a combination of hardware and software modules within the processor.

[0209] This application also provides a computer-readable storage medium storing computer-executable instructions, which, when executed by a processor, implement the methods in any of the above method embodiments.

[0210] This application also provides a computer program product, including a computer program that, when executed by a processor, implements the methods in any of the above method embodiments.

[0211] All or part of the steps in the above method embodiments can be implemented by hardware related to program instructions. The aforementioned program can be stored in a readable memory. When the program is executed, it performs the steps of the above method embodiments; and the aforementioned memory (storage medium) includes: read-only memory (ROM), RAM, flash memory, hard disk, solid-state drive, magnetic tape, floppy disk, optical disk, and any combination thereof.

[0212] This application describes embodiments with reference to flowchart illustrations and / or block diagrams of methods, apparatus (systems), and computer program products according to embodiments of this application. It should be understood that each block of the flowchart illustrations and / or block diagrams, and combinations of blocks in the flowchart illustrations and / or block diagrams, can be implemented by computer program instructions. These computer program instructions can be provided to a processing unit of a general-purpose computer, special-purpose computer, embedded processor, or other programmable data processing apparatus to produce a machine, such that the instructions, which execute via the processing unit of the computer or other programmable data processing apparatus, generate instructions for implementing the flowchart illustrations. Figure 1 One or more processes and / or boxes Figure 1 A device that provides the functions specified in one or more boxes.

[0213] These computer program instructions may also be stored in a computer-readable storage medium that can direct a computer or other programmable data processing device to function in a particular manner, such that the instructions stored in the computer-readable storage medium produce an article of manufacture including instruction means, which are implemented in a process Figure 1 One or more processes and / or boxes Figure 1 The function specified in one or more boxes.

[0214] These computer program instructions may also be loaded onto a computer or other programmable data processing equipment to cause a series of operational steps to be performed on the computer or other programmable equipment to produce a computer-implemented process, thereby providing instructions that execute on the computer or other programmable equipment for implementing the process. Figure 1 One or more processes and / or boxes Figure 1 The steps of the function specified in one or more boxes.

[0215] Obviously, those skilled in the art can make various modifications and variations to the embodiments of this application without departing from the spirit and scope of this application. Therefore, if these modifications and variations to the embodiments of this application fall within the scope of the claims of this application and their equivalents, this application also intends to include these modifications and variations.

[0216] In this application, the term "comprising" and its variations can refer to non-limiting inclusion; the term "or" and its variations can refer to "and / or". The terms "first", "second", etc., in this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. In this application, "multiple" refers to two or more. "And / or" describes the relationship between related objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, and B existing alone. The character " / " generally indicates that the preceding and following related objects have an "or" relationship.

[0217] It should be noted that, for the sake of simplicity, the foregoing method embodiments are all described as a series of actions. However, those skilled in the art should understand that this application is not limited to the described order of actions, as some steps may be performed in other orders or simultaneously according to this application. Furthermore, those skilled in the art should also understand that the embodiments described in the specification are all optional embodiments, and the actions and modules involved are not necessarily essential to this application.

[0218] It should be further noted that although the steps in the flowchart are shown sequentially according to the arrows, these steps are not necessarily executed in the order indicated by the arrows. Unless explicitly stated herein, there is no strict order restriction on the execution of these steps, and they can be executed in other orders. Moreover, at least some steps in the flowchart may include multiple sub-steps or multiple stages. These sub-steps or stages are not necessarily completed at the same time, but can be executed at different times. The execution order of these sub-steps or stages is not necessarily sequential, but can be performed alternately or in turn with other steps or at least some of the sub-steps or stages of other steps.

[0219] It should be understood that the above-described device embodiments are merely illustrative, and the device of this application can also be implemented in other ways. For example, the division of units / modules in the above embodiments is only a logical functional division, and there may be other division methods in actual implementation. For example, multiple units, modules, or components may be combined, or integrated into another system, or some features may be ignored or not executed.

[0220] Furthermore, unless otherwise specified, the functional units / modules in the various embodiments of this application can be integrated into one unit / module, or each unit / module can exist physically separately, or two or more units / modules can be integrated together. The integrated units / modules described above can be implemented in hardware or as software program modules.

[0221] When integrated units / modules are implemented in hardware, the hardware can be digital circuits, analog circuits, etc. The physical implementation of the hardware structure includes, but is not limited to, transistors, memristors, etc. Unless otherwise specified, the processor can be any suitable hardware processor, such as a CPU, GPU, FPGA, DSP, and ASIC, etc. Unless otherwise specified, the storage unit can be any suitable magnetic or magneto-optical storage medium, such as Resistive Random Access Memory (RRAM), Dynamic Random Access Memory (DRAM), Static Random Access Memory (SRAM), Enhanced Dynamic Random Access Memory (EDRAM), High-Bandwidth Memory (HBM), Hybrid Memory Cube (HMC), etc.

[0222] If the integrated unit / module is implemented as a software program module and sold or used as an independent product, it can be stored in a computer-readable storage device (CMD). Based on this understanding, the technical solution of this application, in essence, or the part that contributes to the prior art, or all or part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a memory and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute all or part of the steps of the methods of the various embodiments of this application. The aforementioned memory includes various media capable of storing program code, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard drive, magnetic disk, or optical disk.

[0223] In the above embodiments, the descriptions of each embodiment have their own emphasis. For parts not described in detail in a certain embodiment, please refer to the relevant descriptions of other embodiments. The technical features of the above embodiments can be combined arbitrarily. For the sake of brevity, not all possible combinations of the technical features in the above embodiments are described. However, as long as the combination of these technical features does not contradict each other, it should be considered within the scope of this specification.

[0224] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the following claims.

[0225] It should be understood that this application is not limited to the precise structure described above and shown in the accompanying drawings, and various modifications and changes can be made without departing from its scope. The scope of this application is limited only by the appended claims.

Claims

1. A method of analyzing a cause of a stall, characterized by, The method includes: Convert the first log data in the first format into the second log data in the second format, where the second format is a preset standard log format; Based on a preset stuttering rule base, at least one stuttering event in the second log data is determined. The stuttering event is a set of log entries in the second log data that match the target stuttering rule in the stuttering rule base. The target stuttering rule is any rule in the stuttering rule base. Based on the first device operation data and the second log data corresponding to the target lag event, the root cause of the lag event is determined. The target lag event is any one of the at least one lag event. The first device operation data is the device operation data within the time window corresponding to the target lag event. The first device operation data includes at least one of device resource usage information, process interaction information, system service information, application service information, and log context information, and the root cause of the lag includes at least one of application anomaly, system anomaly, resource contention conflict, and others.

2. The method of claim 1, wherein, The determination of at least one stuttering event in the second log data based on a preset stuttering rule base includes: Based on the parameter threshold rules and keyword rules in the lag rule base, determine the log entries in the second log data that match the parameter threshold rules and / or the keyword rules as at least one lag event; The parameter threshold rule includes a target parameter identifier and a first threshold, which is used to determine whether the value of the target parameter in the second log data exceeds the first threshold. The keyword rules include feature text and matching methods, used to determine whether the second log data contains text data that matches the feature text.

3. The method of claim 1, wherein, The method further includes: Construct a corresponding timeline of lag events based on the timestamps of all lag events in the at least one lag event; Based on the timeline of the lag event, the first device operation data corresponding to the target lag event is determined. The timestamp of the first device operation data is within the target time window. The target time window is a time window determined on the timeline of the lag event based on the timestamp of the target lag event and according to a preset duration.

4. The method according to any one of claims 1 to 3, characterized in that, The step of determining the root cause of the lag in the target lag event based on the first device operation data corresponding to the target lag event in the at least one lag event includes: Determine abnormal data in the first device operation data. The abnormal data includes data whose value exceeds the second threshold range, whose status identifier matches a preset abnormal set, or whose data format conforms to a preset error pattern. Based on the abnormal data, determine the root cause of the target lag event.

5. The method of claim 4, wherein, The step of determining the root cause of the target lag event based on the abnormal data includes: A correlation graph is constructed based on the target lag event and the abnormal data. The correlation graph includes the target lag node corresponding to the target lag event and multiple abnormal data nodes corresponding to the abnormal data. The association weights between nodes in the association graph are determined using a graph neural network model. Based on the association weights between the nodes, the association path between the target sluggish node and each abnormal data node is determined; Based on the fault type corresponding to the target abnormal data node in the associated path, the root cause of the target lag event is determined. The target abnormal data node is the abnormal data node with the highest contribution among the multiple abnormal data nodes or the abnormal data node at the beginning of the path.

6. The method of claim 5, wherein, The graph neural network model includes an input layer, at least one graph convolutional layer, and an output layer; The input layer is used to preprocess the node attributes of all nodes in the association graph and the connection relationships between all nodes to obtain a first feature vector. The at least one graph convolutional layer is used to perform at least one aggregation process on the first feature vector to obtain the second feature vector; The output layer is used to map the second feature vector to obtain the association weights between each node in the association graph.

7. The method of claim 6, wherein, The method further includes: The sum of the path propagation strengths of all associated paths of the first abnormal data node is determined as the path propagation strength of the first abnormal data node, where the first abnormal data node is any one of the plurality of abnormal data nodes. The contribution of the first abnormal data node is determined by multiplying the path propagation strength of the first abnormal data node by the deviation of the first abnormal data node. The deviation is used to indicate the degree of deviation between the value of the first abnormal data corresponding to the abnormal data node and a preset benchmark value.

8. The method of claim 7, wherein, The step of determining the root cause of the target lag event based on the fault type corresponding to the target abnormal data node in the associated path includes: Based on the fault root cause mapping rule library, the root cause of the target lag event is determined according to the fault type corresponding to the target abnormal data node. The fault root cause mapping rule library includes multiple rules indicating the mapping relationship between the fault type corresponding to the data node and the lag root cause.

9. The method of claim 1, wherein, The method further includes: Display the root cause information of the lag, which includes at least one of the following: a lag event timeline, the root cause of the lag, and a lag resolution suggestion corresponding to the root cause of the lag.

10. A stuck root cause analysis apparatus, characterized by, The device includes: The conversion module is used to convert first log data in a first format into second log data in a second format, wherein the second format is a preset standard log format. The first determining module is used to determine at least one lag event in the second log data based on a preset lag rule library. The lag event is a set of log entries in the second log data that match a target lag rule in the lag rule library. The target lag rule is any rule in the lag rule library. The second determining module is used to determine the root cause of the lag in the target lag event based on the first device operation data corresponding to the target lag event and the second log data. The target lag event is any one of the at least one lag event, and the first device operation data is the device operation data within the time window corresponding to the target lag event. The first device operation data includes at least one of device resource usage information, process interaction information, system service information, application service information, and log context information, and the root cause of the lag includes at least one of application anomaly, system anomaly, resource contention conflict, and others.

Images