Equipment fault diagnosis method and system, equipment and medium

Abstract

The invention provides an equipment fault diagnosis method and system, equipment and a medium, and the method comprises the steps: obtaining full-stack monitoring data of target equipment, the full-stack monitoring data being from at least two different technology stack levels of the target equipment; abnormal events in the full-stack monitoring data are detected; a propagation path of the abnormal event in a topological graph is analyzed, a starting node of the propagation path is used as a root cause node, and the topological graph is constructed based on the monitoring objects in the target equipment and the dependency relationship between the monitoring objects; and matching the abnormal features of the root cause node with known fault features in an equipment knowledge base to obtain a fault diagnosis result of the target equipment. According to the method, the starting node of the propagation path can be traced to position the root cause, and accurate matching is carried out in combination with the equipment knowledge base, so that deep faults which cannot be identified by a traditional method can be accurately positioned and diagnosed, and the problems of inaccurate root cause positioning and low efficiency caused by incomplete monitoring data and unmatched analysis models are avoided.

Description

Technical Field

[0001] This invention relates to the field of information technology operation and maintenance technology, and in particular to a method, system, device and medium for diagnosing equipment faults. Background Technology

[0002] The information technology application innovation (hereinafter referred to as "IT innovation") industry is developing on a large scale, but the heterogeneity and complexity of its technology stack pose a severe challenge to the stable and reliable operation of equipment.

[0003] Currently, performance data from the application layer and general operating system layer is collected and uploaded for analysis by deploying agents on the device side. However, this method cannot identify domestically produced hardware, deeply customized domestic operating systems, and domestic applications. It suffers from fundamental defects such as lack of hardware-level monitoring, failure of system-level monitoring, and blind spots in application-level monitoring, making it difficult to accurately locate faults unique to the domestic IT innovation environment. Summary of the Invention

[0004] This invention provides a method, system, device, and medium for diagnosing equipment faults, in order to overcome the deficiencies existing in the prior art.

[0005] This invention provides a method for diagnosing equipment faults, comprising the following steps: Acquire full-stack monitoring data of the target device, wherein the full-stack monitoring data comes from at least two different technology stack layers of the target device; Detect abnormal events in the full-stack monitoring data; The propagation path of the abnormal event in the topology graph is analyzed, and the starting node of the propagation path is taken as the root cause node. The topology graph is constructed based on the monitoring objects in the target device and the dependencies between the monitoring objects. The abnormal features of the root cause node are matched with known fault features in the device knowledge base to obtain the fault diagnosis result of the target device.

[0006] According to a device fault diagnosis method provided by the present invention, the detection of abnormal events in the full-stack monitoring data includes: When the real-time value of any monitoring indicator in the full-stack monitoring data exceeds the corresponding dynamic baseline, the monitoring object corresponding to the monitoring indicator is determined to have experienced an abnormal event. The dynamic baseline of the monitoring indicator is the fluctuation range of the monitoring indicator when the corresponding monitoring object is in normal operation.

[0007] According to a device fault diagnosis method provided by the present invention, the dynamic baseline of any monitoring indicator is determined based on the following steps: Obtain the historical value of any of the monitoring indicators under the normal operating conditions of the corresponding monitored object; Analyze the statistical characteristics of the historical data collected to determine the normal fluctuation pattern of any one of the monitoring indicators. The normal fluctuation pattern is used to characterize the numerical distribution pattern of any one of the monitoring indicators. Based on the normal fluctuation pattern, the allowable fluctuation boundary of any of the monitoring indicators is extracted, and the allowable fluctuation boundary is used as the dynamic baseline.

[0008] According to a device fault diagnosis method provided by the present invention, the step of analyzing the propagation path of the abnormal event in the topology graph and taking the starting node of the propagation path as the root cause node includes: The nodes mapped to the monitoring objects corresponding to the abnormal events in the topology graph are marked as abnormal nodes; Tracing back along the directed edges of the topology graph, the running status of upstream nodes that are dependent on the abnormal node is detected, and upstream nodes in abnormal running status are added to the upstream node sequence in sequence to form a propagation path from the abnormal node to each upstream abnormal node. The node in the propagation path that has no upstream dependency is taken as the root cause node.

[0009] According to a device fault diagnosis method provided by the present invention, the step of detecting the operating status of upstream nodes that are dependent on the abnormal node includes: Obtain the monitoring metrics of the monitoring object corresponding to the upstream node; If the real-time value of the monitoring indicator corresponding to the upstream node exceeds the corresponding dynamic baseline, the upstream node is determined to be in an abnormal operating state.

[0010] According to a device fault diagnosis method provided by the present invention, the step of matching the abnormal features of the root cause node with known fault features in a device knowledge base to obtain the fault diagnosis result of the target device includes: Extract the abnormal features of the root cause node; Calculate the similarity between the abnormal features and each known fault feature in the equipment knowledge base; The known fault feature with the highest similarity is used as the matching result, and the fault type corresponding to the matching result is used as the fault diagnosis result.

[0011] According to a device fault diagnosis method provided by the present invention, the step of acquiring full-stack monitoring data of the target device includes: Hardware layer data of the target device is collected using a hardware probe. The system probe collects operating system layer data of the target device; The platform software layer data of the target device is collected using a software probe. The target device's business application layer data is collected using a software probe; The full-stack monitoring data includes at least two of the hardware layer data, the operating system layer data, the platform software layer data, and the business application layer data.

[0012] According to a device fault diagnosis method provided by the present invention, when the full-stack monitoring data includes the business application layer data, it further includes: Based on the data analysis of the aforementioned business application layer, operational issues of the business application are identified; Generate an application diagnostic report that includes the aforementioned operational issues; The application diagnostic report will be sent to the software developer of the corresponding business application.

[0013] According to a device fault diagnosis method provided by the present invention, the step of detecting abnormal events in the full-stack monitoring data further includes: Identify monitoring data from different technology stack layers that are related within the full-stack monitoring data; Timestamp alignment is performed on related monitoring data; Perform data cleaning on the timestamp-aligned full-stack monitoring data.

[0014] According to a device fault diagnosis method provided by the present invention, after obtaining the fault diagnosis result of the target device, the method further includes: The fault diagnosis results are presented in a visualization interface, which also includes at least one of the topology diagram, alarm information, and health report of the target device.

[0015] The present invention also provides a device fault diagnosis system, comprising: The data acquisition layer is used to acquire full-stack monitoring data of the target device, wherein the full-stack monitoring data comes from at least two different technology stack layers of the target device; The cloud-based analysis layer is used to detect abnormal events in the full-stack monitoring data; analyze the propagation path of the abnormal events in the topology graph, and take the starting node of the propagation path as the root cause node. The topology graph is constructed based on the monitoring objects within the target device and the dependencies between the monitoring objects; and match the abnormal characteristics of the root cause node with the known fault characteristics in the device knowledge base to obtain the fault diagnosis result of the target device.

[0016] The equipment fault diagnosis system provided by the present invention further includes: The data transmission layer is used to identify monitoring data from different technology stack levels that are related in the full-stack monitoring data, to align the related monitoring data with timestamps, to clean the time-stamp aligned full-stack monitoring data, and to transmit the cleaned full-stack monitoring data to the cloud analysis layer.

[0017] The present invention also provides an electronic device, including a memory, a processor, and a computer program stored in the memory and executable on the processor, wherein the processor executes the program to implement the device fault diagnosis method as described above.

[0018] The present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, implements the device fault diagnosis method as described above.

[0019] The present invention also provides a computer program product, including a computer program that, when executed by a processor, implements the device fault diagnosis method as described above.

[0020] The equipment fault diagnosis method, system, equipment, and medium provided by this invention achieve effective analysis of the propagation path of abnormal events by acquiring full-stack monitoring data and constructing a topology graph that reflects the internal dependencies of the equipment. Because this invention can trace the starting node of the propagation path to locate the root cause and perform precise matching with the equipment knowledge base, it can accurately locate and diagnose deep-seated faults that traditional methods cannot identify, avoiding the problems of inaccurate root cause location and low efficiency caused by incomplete monitoring data and unsuitable analysis models. Attached Figure Description

[0021] To more clearly illustrate the technical solutions in this invention or the prior art, the drawings used in the description of the embodiments or the prior art will be briefly introduced below. Obviously, the drawings described below are some embodiments of this invention. For those skilled in the art, other drawings can be obtained from these drawings without creative effort.

[0022] Figure 1 This is a flowchart illustrating the equipment fault diagnosis method provided by the present invention.

[0023] Figure 2 This is a schematic diagram of the equipment fault diagnosis system provided by the present invention.

[0024] Figure 3 This is a schematic diagram of the structure of the electronic device provided by the present invention. Detailed Implementation

[0025] To make the objectives, technical solutions, and advantages of this invention clearer, the technical solutions of this invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some, not all, of the embodiments of this invention. All other embodiments obtained by those skilled in the art based on the embodiments of this invention without creative effort are within the scope of protection of this invention.

[0026] To achieve device monitoring, related technologies typically deploy agents on the device side to collect performance data at the application layer and general operating system layer, and then upload it to a cloud platform for analysis and alerting. However, this method cannot identify and collect the unique status indicators of domestically produced hardware (such as domestic CPUs and hard drives), resulting in a lack of hardware-level monitoring. Furthermore, it cannot be adapted to deeply customized and kernel-hardened domestic operating systems, leading to system-level monitoring failure. In addition, this method lacks dedicated monitoring probes for domestic application software (such as domestic databases and middleware), creating blind spots in application-level monitoring. These missing and inaccurate monitoring data ultimately make it difficult to identify the unique fault modes of the domestic IT innovation environment, resulting in inaccurate root cause localization and low efficiency.

[0027] To address this issue, this invention provides a device fault diagnosis method. It aims to acquire full-stack monitoring data of the device, analyze the anomaly propagation path based on the monitored object's topology to locate the root cause, and then perform precise matching using a knowledge base to determine the final fault. This achieves full-stack, blind-spot-free monitoring from hardware and system to application, significantly improving the accuracy of fault diagnosis and the efficiency of root cause location. The method provided by this invention can be applied to domestically produced servers or smart terminals in a domestically developed IT environment, as well as to traditional data center equipment and heterogeneous computing scenarios such as the Internet of Things or edge computing. This invention does not specifically limit its application to these applications. For ease of explanation, the following embodiments use domestically produced servers in a domestically developed IT environment as an example; that is, the target device in the following embodiments is this domestically produced server.

[0028] in, Figure 1 This is a flowchart illustrating the equipment fault diagnosis method provided by the present invention, as shown below. Figure 1 As shown, the method includes steps 110, 120, 130 and 140.

[0029] Step 110: Obtain full-stack monitoring data of the target device. The full-stack monitoring data comes from at least two different technology stack layers of the target device.

[0030] Here, the target device can be understood as any hardware or software entity that needs to be diagnosed, such as the domestically produced server in this embodiment, which can be equipped with a domestic CPU, a domestic operating system, and domestic application software.

[0031] Full-stack monitoring data can be understood as a series of metrics that characterize the complete operational status of a target device, from its underlying hardware to its upper-layer applications. Technology stack layers refer to different technical levels divided according to computer architecture. These layers can include hardware, operating system, and application layers, and can be further subdivided into more specific levels. For example, the hardware layer can be divided into sub-layers such as CPU, memory, disk, and network; the application layer can be divided into middleware, database, and business application layers. This invention does not impose specific limitations on these layers.

[0032] When acquiring full-stack monitoring data from the hardware layer, this may include, but is not limited to, collecting chip temperature, power consumption, instruction cycle count of domestic CPUs, lifespan of non-volatile memory controllers of domestic hard drives, and memory status of domestic GPUs. This data can be obtained by calling dedicated driver interfaces or performance counters provided by hardware manufacturers, which makes up for the deficiency that related technologies cannot collect domestic hardware indicators through standardized interfaces (such as SMBIOS).

[0033] When acquiring full-stack monitoring data from the operating system layer, this may include, but is not limited to, collecting kernel scheduling events, security audit logs, and the status of national cryptographic protocol stacks specific to domestic operating systems. Since domestic operating systems are typically deeply customized and security-hardened based on the Linux kernel, probes adapted to their unique system call interfaces can be deployed to obtain data that standard Linux monitoring tools cannot access.

[0034] When acquiring full-stack monitoring data from the application layer, this may include, but is not limited to, collecting performance metrics of domestically developed basic software. For example, for the DM database, its SQL execution plan and lock wait information can be collected; for WPS Office, its document loading time and rendering thread status can be collected. This data can be obtained through monitoring probes specific to each type of domestic software or through bytecode instrumentation.

[0035] It should be noted that the full-stack monitoring data comes from at least two different technology stack layers of the target device, thereby breaking down data barriers between different technology layers, constructing a complete status view of the device, and avoiding misjudgments of faults or failures in root cause localization due to the limitations of data from a single layer. In order to comprehensively and without blind spots grasp the device's operating status, this embodiment preferably collects monitoring data covering three layers: the hardware layer, the operating system layer, and the application layer as full-stack monitoring data.

[0036] Step 120: Detect abnormal events in the full-stack monitoring data.

[0037] Specifically, an anomaly can be understood as a data point or data sequence in the monitoring data that deviates from the normal or expected behavior pattern. For example, an anomaly could be a CPU temperature suddenly exceeding a preset threshold of 95°C, or an application's API response time averaging 300% over the past 5 minutes compared to the previous period.

[0038] As an optional implementation, a fixed normal range can be pre-defined for the monitoring indicators in the full-stack monitoring data. Once the real-time value of the corresponding monitoring indicator exceeds this range, it is judged as abnormal. Alternatively, a statistical model of the normal behavior of the monitoring indicators can be established by analyzing the historical values ​​of the monitoring indicators. When the real-time value deviates significantly from the model, it is judged as abnormal. Furthermore, unsupervised learning algorithms such as Isolation Forest and Single-Class Support Vector Machine can be used to automatically learn normal patterns from high-dimensional data and identify anomalies.

[0039] Considering the complexity of the domestic IT innovation environment and the diversity of fault modes, in order to improve the accuracy of detection and reduce the false alarm rate, this embodiment can combine multiple methods for detection. For example, static threshold detection is used for indicators with clear physical or logical boundaries, such as CPU temperature and disk usage; statistical model detection is used for indicators with dynamic baselines, such as network throughput and API response time; and machine learning models are used to identify complex anomaly patterns generated by the linkage of multiple indicators.

[0040] Step 130: Analyze the propagation path of abnormal events in the topology diagram and take the starting node of the propagation path as the root cause node. The topology diagram is constructed based on the monitoring objects within the target device and the dependencies between the monitoring objects.

[0041] Specifically, the monitored object refers to the smallest unit in the device that is being monitored, which can be a hardware component, an operating system process, a database instance, or an application programming interface, etc.

[0042] A topology graph is a directed graph used to describe the logical and physical relationships between monitored objects within a device. In a topology graph, nodes represent individual monitored objects, and directed edges represent the dependencies between these objects. For example, the WPS application (node ​​A) depends on the file system services provided by the operating system M (node ​​B), therefore, there is a directed edge in the topology graph pointing from node A to node B.

[0043] The propagation path of an anomaly refers to how, after a root cause failure occurs, its impact propagates backward along the dependency chain in the topology graph, triggering a series of chain reactions of anomalies. For example, if the CPU (node ​​C) overheats and reduces its frequency due to a cooling fan failure, it will first cause an increase in the CPU scheduling latency of the operating system (node ​​B), which in turn will cause the upper-layer WPS application (node ​​A) to lag. Monitoring metrics will detect abnormal CPU temperature, abnormal system scheduling latency, and abnormal application response time in sequence. This anomaly sequence of "application lag → system latency → CPU overheating" corresponds to the path A→B→C in the topology graph. The root cause node is the starting node of the propagation path, i.e., node C in the example.

[0044] This embodiment can effectively separate surface-level, passive anomalies from underlying, active fault sources by tracing the anomaly propagation chain, thereby accurately locating the initial source of the problem, rather than remaining at the level of application lag.

[0045] Step 140: Match the abnormal features of the root cause node with the known fault features in the device knowledge base to obtain the fault diagnosis results of the target device.

[0046] Specifically, the abnormal characteristics of a root cause node refer to the specific performance of its own and its neighboring nodes' related monitoring indicators when an anomaly occurs. The abnormal characteristics of a root cause node can be a set of feature vectors, such as {node type: CPU, manufacturer: N, model: 2000, abnormal indicator: temperature = 98℃, power consumption: reduced by 30%, associated anomaly: fan speed = 0 RPM}.

[0047] The device knowledge base stores a large number of known "fault mode-fault characteristic" mapping relationships, especially for the domestic IT innovation environment. For example, the device knowledge base may contain a record that reads: "Fault name: Processor refresh defect; Fault characteristics: {Node type: CPU, Manufacturer: N, Anomaly indicators: TLB Miss rate surge, frequent specific system calls}; Solution: Upgrade kernel patch." This device knowledge base can be continuously built and updated through expert experience, historical fault review, and model training.

[0048] This embodiment calculates the similarity or pattern matching between the actual abnormal features of the located root cause node and the known fault features in the device knowledge base, finds the most matching one or more known fault records, and thus obtains the final fault diagnosis result.

[0049] The device fault diagnosis method provided in this embodiment acquires full-stack monitoring data and constructs a topology graph that reflects the internal dependencies of the device, thereby achieving effective analysis of the propagation path of abnormal events. Because this embodiment can trace the starting node of the propagation path to locate the root cause and perform precise matching using the device knowledge base, it can accurately locate and diagnose deep-seated faults that traditional methods cannot identify. This avoids the problems of inaccurate root cause location and low efficiency caused by incomplete monitoring data and unsuitable analysis models.

[0050] Based on the above embodiments, detecting abnormal events in full-stack monitoring data includes: When the real-time value of any monitoring indicator in the full-stack monitoring data exceeds the corresponding dynamic baseline, the monitoring object corresponding to that monitoring indicator is identified as having an abnormal event. The dynamic baseline of any monitoring indicator is the fluctuation range of that monitoring indicator under the normal operating state of the corresponding monitoring object.

[0051] Specifically, a dynamic baseline can be understood as a fluctuation range that represents the normal behavior of a monitoring metric, dynamically calculated based on its historical values. For the same monitoring metric, the corresponding dynamic baseline may differ at different times or under different workloads. For example, the number of concurrent users of a web application is higher during the daytime on weekdays and lower at night, and consequently, the dynamic range of the monitoring metric "CPU utilization" will also be dynamically adjusted accordingly, meaning that the normal fluctuation range during the day will be generally higher than at night.

[0052] Normal operation can be understood as the monitored object not experiencing any faults and its performance meeting expectations. The fluctuation range is the interval calculated based on the values ​​of the monitored indicator under normal operation conditions. As an optional implementation, at each time point t, the moving average μ(t) and moving standard deviation σ(t) of a certain monitored indicator over a past period (e.g., N data points) can be calculated. Subsequently, the fluctuation range of the dynamic baseline can be defined as [μ(t) - kσ(t), μ(t) + kσ(t)], where k is a configurable multiplier parameter, such as 3. Therefore, the upper limit of the dynamic baseline for this monitored indicator is μ(t) + 3σ(t).

[0053] For example, suppose the monitored object is a domestic database, and the monitored metric is the database's "Transactions Per Second (TPS)". First, the historical TPS values ​​of the database under normal operating conditions are collected and stored. During real-time monitoring, for the current time point t, the moving average μ(t) and moving standard deviation σ(t) over the past hour (N=3600 seconds) are calculated. Assume that at time t, μ(t) = 1000 times / second and σ(t) = 50 times / second. If k=3, the upper limit of the dynamic baseline is 1000 + 3 × 50 = 1150 times / second. When the real-time TPS value collected in the next second is 1200 times / second, since this real-time value 1200 > 1150, exceeding the upper limit of the dynamic baseline, the TPS metric of the domestic database is determined to be abnormal, and the monitored object "domestic database" is marked as having experienced an abnormal event.

[0054] In this embodiment, anomaly detection is achieved by employing a dynamic baseline, enabling anomaly detection to adapt to normal fluctuations in monitoring metrics over different time periods. Compared to methods using fixed static thresholds, this approach automatically learns normal patterns based on the historical behavior of the monitored object, significantly improving the accuracy and sensitivity of anomaly detection. This effectively reduces false alarms caused by normal changes such as periodic business fluctuations, and enhances the signal-to-noise ratio of the entire fault diagnosis system.

[0055] Based on any of the above embodiments, the dynamic baseline of any monitoring indicator is determined based on the following steps: Obtain the historical value of any monitoring indicator under the normal operating condition of the corresponding monitored object; Analyze the statistical characteristics of historical data to determine the normal fluctuation pattern of any monitoring indicator. The normal fluctuation pattern is used to characterize the numerical distribution pattern of any monitoring indicator. Based on the normal fluctuation pattern, the allowable fluctuation boundary of any monitoring indicator is extracted, and the allowable fluctuation boundary is used as the dynamic baseline.

[0056] Specifically, historical values ​​can be understood as a data sequence arranged in chronological order, recording the values ​​of monitoring indicators over a past period. For example, for CPU utilization, one data point can be collected every minute for a week, forming a historical value sequence containing 10,080 data points. Historical values ​​under normal operating conditions refer to the monitoring indicator values ​​collected during a period when the corresponding monitored object is functionally sound and performs as expected. To ensure the accuracy of subsequently determined normal fluctuation patterns, historical values ​​under normal operating conditions typically represent the monitoring indicator values ​​for a period when the equipment has not experienced any known faults and its performance is stable.

[0057] Given that historical values ​​typically contain complex components such as trends, periods, and random noise, these complexities can render simple statistical values ​​(like the global average) unrepresentative when analyzing the normal fluctuation range of monitoring indicators. This makes it difficult to accurately define what constitutes "normal." Therefore, it is necessary to extract the inherent, regular behavioral characteristics from historical values ​​to construct a benchmark model that reflects their dynamic changes. Furthermore, since the statistical characteristics of historical values ​​can quantitatively describe the central tendency, dispersion, and distribution pattern of data, the changing patterns of monitoring indicators can be modeled based on these characteristics, i.e., the normal fluctuation pattern of any monitoring indicator can be determined. These statistical characteristics include, but are not limited to, the mean, median, variance, standard deviation, and quantiles of the data distribution. The normal fluctuation pattern is a mathematical description of the inherent regularity of the data based on these statistical characteristics.

[0058] As an optional implementation, the historical value sequence can be decomposed into trend components, periodic components, and residual components. The superposition of the trend components and periodic components can be used as the normal fluctuation pattern of the indicator, which reflects the ideal change trajectory of the indicator after removing random noise.

[0059] The normal fluctuation pattern itself only provides a prediction of the center point of the indicator value at future times, without considering the reasonable random fluctuations of the indicator around that center point. However, when identifying abnormal events, it is necessary to distinguish between normal random disturbances and genuine abnormal deviations, thus requiring the determination of the reasonable random fluctuations of the indicator. Based on this, this embodiment extracts the allowable fluctuation boundary of any monitoring indicator according to the normal fluctuation pattern and uses the allowable fluctuation boundary as a dynamic baseline, thereby tolerating random fluctuations of the indicator within the normal range and avoiding false alarms triggered by minor, harmless fluctuations.

[0060] As an optional implementation, the permissible fluctuation boundary of any monitoring indicator can be determined based on the predicted value of the normal fluctuation pattern and the statistical characteristics of the residual components. For example, the standard deviation of the residual components can be calculated, and the permissible fluctuation boundary can be defined as the interval formed by floating up or down by k times the standard deviation based on the predicted value of the normal fluctuation pattern.

[0061] This embodiment provides a systematic method for generating dynamic baselines through three steps: acquiring historical values, analyzing fluctuation patterns, and extracting fluctuation boundaries. Because this method not only considers the average level of the indicator but also constructs normal fluctuation patterns by analyzing its inherent laws such as trends and periodicity, the generated dynamic baseline can more accurately match the actual operating rhythm of the indicator.

[0062] Based on any of the above embodiments, step 130 analyzes the propagation path of the abnormal event in the topology graph and takes the starting node of the propagation path as the root cause node, including: Step 131: Mark the nodes mapped to the monitoring objects corresponding to the abnormal events in the topology diagram as abnormal nodes.

[0063] When any abnormal event is detected in step 120, the monitoring object to which the abnormal event belongs must first be determined. For example, if the detected abnormal event is "WPS application document opening response time exceeds 5 seconds", then the corresponding monitoring object is "WPS application". Subsequently, the node representing "WPS application" is found in the pre-built topology map and marked as the initial abnormal node.

[0064] Step 132: Traverse backwards along the directed edges of the topology graph, detect the running status of upstream nodes that are dependent on the abnormal node, and add the upstream nodes in the abnormal running state to the upstream node sequence in sequence, forming a propagation path from the abnormal node to each abnormal upstream node. Specifically, backtracking refers to traversing along the opposite direction of the directed edges in the topological graph. Since the directed edge (A→B) in the topological graph represents "node A depends on node B", the direction of fault propagation is usually from node B to node A, while analyzing the root cause requires tracing back from node A to node B.

[0065] Specifically, starting with the anomalous node, we find all upstream nodes in the topology graph that have a dependency relationship with it. These upstream nodes are those to which there is a directed edge in the topology graph. For each upstream node, we retrieve and check the running status of its corresponding monitoring object within the same time window.

[0066] If an upstream node's operational status is also abnormal, it indicates that the anomaly may have originated from that upstream node or a node further upstream. In this case, the upstream node is marked as an abnormal node and added to the "upstream node sequence." Then, starting from that upstream node, the above reverse tracing and detection process is recursively repeated. If an upstream node's operational status is normal, it means that the anomaly propagation chain has not continued to extend along that branch, and the tracing process terminates at that branch.

[0067] Through this recursive tracing process, one or more upstream node sequences are eventually formed, extending from the initial abnormal node to deeper-level abnormal nodes. This sequence constitutes the propagation path of the abnormal event.

[0068] For example, the initial anomalous node is the "WPS application" (node ​​A). Tracing back its upstream dependent nodes, we find the "operating system" (node ​​B). Checking the state of node B reveals an anomaly in its "kernel scheduling latency" metric. Therefore, node B is added to the sequence, and the current propagation path is A→B.

[0069] Continuing the reverse tracing from node B, we find its upstream dependent node "CPU" (node ​​C). Checking the state of node C reveals an abnormal "chip temperature" indicator. Therefore, node C is added to the sequence, and the current propagation path is updated to A→B→C. Continuing the reverse tracing from node C, if node C has no upstream dependency in the topology graph, the tracing process terminates.

[0070] Step 133: Select the nodes in the propagation path that do not have upstream dependencies as root cause nodes.

[0071] Specifically, a node without upstream dependencies can be understood as the node at the very end of the propagation path. This node itself is an abnormal node; either all upstream dependent nodes of this node in the topology graph are in normal state, or this node is at the most basic level in the topology graph and has no upstream dependent nodes.

[0072] For example, if the propagation path is A→B→C, node C has no upstream dependent nodes in this propagation path, so node C is determined to be the root cause node.

[0073] As an optional embodiment, when a node has multiple upstream dependent nodes, such as an application that depends on both the operating system and the database, the tracing process in this embodiment will detect all upstream branches in parallel, that is, perform status checks on all upstream dependent nodes of the node simultaneously or sequentially, and continue to trace back all branches that are detected as abnormal. This enables the handling of complex fault scenarios caused by multiple different dependencies, either jointly or independently, and improves the comprehensiveness of the analysis.

[0074] This embodiment maps abnormal events to nodes in the topology graph and performs systematic reverse tracing and status detection along the dependencies, traversing the complete path of fault propagation in a structured manner until the source without upstream abnormal dependencies is found. This enables efficient and accurate identification of the root cause of the fault, avoiding the inefficiency and uncertainty of relying on manual experience and repeated trial and error in traditional operation and maintenance.

[0075] Based on any of the above embodiments, detecting the running status of upstream nodes that have a dependency relationship with abnormal nodes includes: Obtain the monitoring metrics of the monitoring objects corresponding to the upstream nodes; If the real-time value of the monitoring indicator of the upstream node exceeds the corresponding dynamic baseline, the upstream node is determined to be in an abnormal operating state.

[0076] When the tracing process locates an upstream node, it automatically retrieves the real-time values ​​of one or more sets of monitoring indicators that are bound to that node and can reflect its operational health status.

[0077] For example, when tracing back from the "operating system" node to its upstream dependent "CPU" node, a series of key performance indicators of the CPU within the current time window can be obtained, such as CPU utilization, context switch count, chip temperature, and number of instruction cycles.

[0078] If the real-time value of the monitoring indicator for an upstream node exceeds the corresponding dynamic baseline, the upstream node is determined to be in an abnormal operating state. Here, the dynamic baseline is not a fixed value, but a dynamically changing predictive model of normal behavior established by learning the historical values ​​of the monitoring indicator. This model can reflect the normal fluctuation range of the monitoring indicator under different time periods and loads.

[0079] This embodiment uses a dynamic baseline to determine the operating status of upstream nodes. Since the dynamic baseline can accurately depict the normal behavior pattern of each indicator at different times, it can effectively filter out false alarms caused by fluctuations in normal indicators due to business peaks, planned tasks, etc. At the same time, it is more sensitive to minor anomalies that deviate from their normal patterns but have not yet reached the static threshold, which significantly improves the accuracy and reliability of the status judgment of each link in the root cause tracing process.

[0080] Based on any of the above embodiments, step 140 matches the abnormal features of the root cause node with known fault features in the device knowledge base to obtain the fault diagnosis result of the target device, including: Step 141: Extract the abnormal features of the root cause node. The abnormal features are used to characterize the abnormal state features of the root cause node.

[0081] Specifically, anomaly features can be understood as structured, computationally usable data formats, obtained by quantifying and encoding the multivariate information of the root cause node at the moment of an anomaly occurrence. Anomaly features not only include the attributes and anomaly indicators of the root cause node itself, but also the associated anomaly information of its neighboring nodes in the topology graph.

[0082] The construction of anomalous features can include encoding different types of features. For example, for categorical features, such as node type and manufacturer, one-hot encoding or tag encoding can be used; for numerical features, such as temperature and power consumption change rate, normalized values ​​can be used directly.

[0083] Step 142: Calculate the similarity between the abnormal features and the known fault features in the equipment knowledge base.

[0084] Specifically, similarity is used to measure the distance between the unknown fault corresponding to the root cause node and each known fault in the knowledge base in the feature space. The higher the similarity, the more closely the unknown fault corresponding to the root cause node matches the corresponding known fault in terms of feature representation. The similarity can be represented by cosine similarity between features, or by Euclidean distance or Pearson correlation coefficient; this embodiment does not impose any specific limitations on this.

[0085] Step 143: Take the known fault feature with the highest similarity as the matching result, and take the fault type corresponding to the matching result as the fault diagnosis result.

[0086] Specifically, the highest similarity indicates that the unknown fault corresponding to the root cause node best matches the fault mode represented by the corresponding known fault feature. Therefore, the corresponding known fault feature is used as the matching result. This matching result can be understood as the known fault feature in the device knowledge base that is most similar to the unknown fault corresponding to the root cause node.

[0087] Furthermore, the fault type corresponding to the matching result can be understood as a semantic label or name in the device knowledge base associated with the best-matched known fault feature, used to describe the essence of the fault. Since this fault type is a clear fault conclusion that can be understood and referenced by maintenance personnel, and not just a machine-readable feature vector, this embodiment uses the fault type corresponding to the matching result as the fault diagnosis result.

[0088] Based on any of the above embodiments, the full-stack monitoring data of the target device is obtained, including: Collect hardware layer data of the target device using hardware probes; Collect operating system layer data of the target device using system probes; Collect platform software layer data of the target device using a software probe; Collect business application layer data from the target device using a software probe; Use at least two of the following as full-stack monitoring data: hardware layer data, operating system layer data, platform software layer data, and business application layer data.

[0089] Specifically, a hardware probe is a data acquisition module specifically adapted to the underlying hardware interface. Since domestically produced hardware in the IT innovation environment typically does not follow the common SMBIOS or ACPI standards, but instead provides unique driver interfaces and performance counters, the hardware probe is designed to directly call these dedicated interfaces. For example, a hardware probe can call the manufacturer's driver for a specific domestic processor to obtain refined metrics such as its core temperature, power consumption, and CPI.

[0090] System probes are data acquisition modules deeply adapted to specific operating systems. For domestically developed operating systems that have undergone kernel hardening and deep customization, system probes can interact with these operating systems' unique system calls and kernel event interfaces to obtain data that standard monitoring tools cannot collect. For example, specific task switching events in the kernel scheduler, the running status of the Chinese cryptographic algorithm protocol stack, and audit logs generated by the security hardening module.

[0091] Software probes are modules used to collect the operational status of upper-layer software. They can be further subdivided into platform software probes and business application probes, depending on the monitored object. Platform software probes are used to collect platform software layer data of the target device, while business application probes are used to collect business application layer data of the target device.

[0092] The platform software layer typically refers to software that provides basic services to upper-layer applications, such as databases and middleware. For this layer, platform software probes can collect data such as SQL execution plans, lock wait details, and transaction processing times for domestic databases. The business application layer refers to applications that users directly interact with, such as office software and design software. For this layer, business application probes can collect data such as the document rendering thread status of WPS Office and the graphic loading time of CAD software.

[0093] It should be noted that the combination of monitoring layers in this embodiment is flexible. For example, for a dedicated database server, hardware probes, system probes, and platform software probes can be deployed to collect data from these three layers as full-stack monitoring data. For office terminals, system probes and business application probes may be deployed. This embodiment does not impose specific limitations on this. To achieve the most comprehensive fault diagnosis capability, it is preferable to deploy all probes to collect complete data covering the hardware layer, operating system layer, platform software layer, and business application layer.

[0094] This embodiment achieves refined and targeted collection of monitoring data at different technology stack levels by setting dedicated hardware probes, system probes, and software probes for the hardware layer, operating system layer, platform software layer, and business application layer, respectively. Because each probe is deeply adapted to the specific hardware and software of the domestic IT innovation environment, it effectively solves the problems of missing hardware layer monitoring, ineffective system layer monitoring, and blind spots in monitoring domestic applications caused by the use of general monitoring interfaces in related technologies, ensuring the completeness and accuracy of the acquired full-stack monitoring data.

[0095] Based on any of the above embodiments, when the full-stack monitoring data includes business application layer data, it further includes: Based on data analysis at the business application layer, analyze the operational issues of business applications; Generate application diagnostic reports that include runtime issues; Send the application diagnostic report to the software developer of the corresponding business application.

[0096] Specifically, operational problems of business applications can be understood as various abnormal events occurring at the business application layer that affect user experience or the normal functioning of the software. Operational problems of business applications can include application crashes, application unresponsiveness, UI lag or frame drops, memory leaks or excessive memory usage, network request errors or timeouts, etc.

[0097] In this embodiment, the business application can be used as the monitoring object. The method of the above embodiment is used to determine the root cause node corresponding to the abnormality of the monitoring object. The abnormal characteristics of the root cause node are matched with the known fault characteristics in the device knowledge base to obtain the fault diagnosis result. The fault diagnosis result includes the operational problems of the business application.

[0098] The application diagnostic report can be understood as a structured report file containing detailed scenarios of operational problems. It can structure and encapsulate fault diagnosis results corresponding to business applications, as well as anomaly propagation paths, related multi-level monitoring data snapshots, and hardware and software environment information obtained during the analysis process, to generate the application diagnostic report.

[0099] After generating the application diagnostic report, it is sent to the software developer of the corresponding business application. This allows the software developer to not only understand the specific performance or stability issues their application is experiencing, but also to understand the deeper root causes of these issues, stemming from the underlying hardware or operating system. This enables them to perform targeted code optimization or collaborate with other vendors in the domestic IT innovation ecosystem to resolve cross-level compatibility and stability issues. Here, "software developer" refers to the vendor that developed or maintains the business application software.

[0100] This embodiment performs in-depth analysis of data from the business application layer and generates structured application diagnostic reports, which are then automatically sent to the corresponding software developers. This establishes an automated closed-loop feedback mechanism from problem discovery to developer awareness. Because this mechanism allows software developers to proactively and quickly obtain performance and stability data of their applications running in real, complex IT innovation environments, it effectively replaces the inefficient traditional model that relies on user feedback, significantly shortening the problem localization and repair cycle.

[0101] Based on any of the above embodiments, detecting abnormal events in full-stack monitoring data further includes: Identify monitoring data from different technology stack layers that are related within the full-stack monitoring data; Timestamp alignment is performed on related monitoring data; Perform data cleaning on the timestamp-aligned full-stack monitoring data.

[0102] Specifically, correlations can be understood as the temporal and logical connections between monitored objects at different technology stack levels caused by a user request, a system call, or a background task. Since the sources of the acquired full-stack monitoring data are wide-ranging, encompassing multiple levels such as hardware, system, and applications, this data does not exist in isolation. Identifying the correlations between them is the foundation for constructing complete fault scenarios and conducting cross-level root cause analysis.

[0103] For example, a user's click on the front-end page may trigger an API request at the application layer. This API request will then call the database layer to execute an SQL query. The SQL query will ultimately consume CPU and I / O resources at the hardware layer. The monitoring data generated by this series of operations (such as API response time, SQL execution time, and CPU utilization) are related.

[0104] As an optional implementation, a globally unique tracking ID can be generated at the initial stage of the request and then passed along the request call chain through the application layer, middleware layer, database layer, and even the operating system kernel, thereby associating various monitoring data belonging to the same business process.

[0105] Because clock drift may occur between different probes and components within the target device, the collected monitoring data with related relationships may not be strictly synchronized in terms of timestamps. Direct analysis may lead to incorrect causal relationships. Therefore, this embodiment aligns the timestamps of the monitoring data with related relationships to eliminate the impact of clock drift between different data sources and ensure the comparability of related events in the time dimension and the correctness of the timing relationship.

[0106] As an optional implementation, the timestamps of the monitoring data with correlation can be calibrated using algorithms such as linear interpolation or spline interpolation, based on a reference clock source, so that they are unified on a common time axis to truly reflect the chronological order of events.

[0107] Furthermore, considering that the timestamp-aligned data may still contain noise, missing values, duplicate values, or anomalous spikes, which can interfere with the accuracy of subsequent anomaly detection models, this embodiment performs data cleaning on the timestamp-aligned full-stack monitoring data to further improve data quality and provide clean and well-organized data input for subsequent anomaly detection.

[0108] Specifically, when cleaning data, missing values ​​can be imputed using methods such as filling with preceding values, filling with following values, or filling with the mean / median. Noisy or volatile data can be smoothed using algorithms such as moving averages or Gaussian filtering. Duplicate data is simply removed.

[0109] This embodiment adds preprocessing steps such as identifying related data, aligning timestamps, and cleaning data before detecting abnormal events. This ensures that the data used for analysis is logically related, time-synchronized, and reliable in quality. It can effectively avoid misjudgment of causal relationships caused by inconsistent data sources or poor data quality, and significantly improve the accuracy and reliability of fault diagnosis.

[0110] Based on any of the above embodiments, the fault diagnosis result of the target device is obtained, and then the process further includes: The fault diagnosis results are presented in a visualization interface, which also includes at least one of the following: topology diagram, alarm information, and health report of the target device.

[0111] Specifically, a visualization interface can be understood as a graphical user interface for human-computer interaction. The purpose of setting up this visualization interface is to present complex and multi-dimensional diagnostic information to users in an intuitive and easy-to-understand way, thereby improving the efficiency of fault handling.

[0112] In this embodiment, the visualization interface not only displays the fault diagnosis results, but also displays at least one of the following: topology diagram, alarm information, and health report of the target device.

[0113] The fault diagnosis results can be displayed prominently on the visualization interface, such as through highlighted cards, pop-ups, or top information bars. Optionally, the presentation can also include fault descriptions, potential impacts, and suggested solutions matched from the device knowledge base, providing users with direct action guidance.

[0114] Root cause nodes in the topology graph can be augmented with reality features, such as being highlighted with special colors and blinking effects. The propagation paths of anomalous events can be marked with bold lines featuring dynamic flow arrows. Through this interactive diagram, users can visually see the source of a fault and how it affects upper-layer applications, greatly improving the understandability of the fault scenario.

[0115] Alarm information can include a series of abnormal events detected related to the current fault. Alarm information can be presented in the form of an alarm list or a timeline. Each alarm can detail its occurrence time, the monitored object it belongs to, the name of the abnormal metric, the abnormal value, and the normal threshold range. Optionally, alarm information can be linked with a visual topology map. For example, when a user clicks on an alarm, the corresponding application node in the topology map will be highlighted, helping the user establish a direct association between alarm events and device components.

[0116] The health report for the target device can include a quantified device health score, which can be obtained by weighted calculation of the abnormal states of all monitored objects within the device. In addition, the health report can also include dashboard displays of key performance indicators at each technology stack level, historical trend graphs of resource utilization, etc., providing data support for users to comprehensively assess device status and predict potential risks.

[0117] This embodiment can not only accurately diagnose faults, but also present the complex diagnostic process and results to users in a highly visualized, information-rich and easy-to-interact manner. This presentation method transforms abstract data relationships and propagation paths into intuitive graphical elements, significantly reducing the cognitive threshold for users to understand the root cause of faults. This allows maintenance personnel to quickly locate problems and take action based on recommendations without having to deeply analyze massive logs and indicators, thereby greatly shortening the average fault repair time and improving the overall efficiency and intelligence level of equipment maintenance.

[0118] The equipment fault diagnosis system provided by the present invention is described below. The equipment fault diagnosis system described below can be referred to in correspondence with the equipment fault diagnosis method described above.

[0119] Based on any of the above embodiments Figure 2 This is a schematic diagram of the equipment fault diagnosis system provided by the present invention, as shown below. Figure 2 As shown, the system includes a data acquisition layer, a data transmission layer, and a cloud analysis layer.

[0120] The data acquisition layer is used to acquire full-stack monitoring data from the target device, which comes from at least two different technology stack layers. The data acquisition layer integrates multiple probe clusters to acquire data from different technology stack layers.

[0121] Specifically, at the hardware layer, the hardware resource monitoring probe cluster is responsible for collecting physical indicators of domestically produced hardware. This cluster includes a domestic computing unit monitoring module, a domestic storage unit monitoring module, and a domestic network unit monitoring module. The domestic computing unit monitoring module collects real-time monitoring data such as CPU / GPU temperature, power consumption, and cache error rate through CPU status probes; the domestic storage unit monitoring module collects real-time monitoring data such as NAND flash memory cycles, remaining lifetime, and bad block counts through SSD health probes and RAID controller probes; and the domestic network unit monitoring module collects real-time monitoring data such as packet loss rate, packet error rate, and RDMA status through NIC status probes and switch interface probes.

[0122] At the operating system layer, the system-level monitoring probe cluster is responsible for in-depth collection of kernel data from domestic operating systems. This cluster includes kernel-mode eBPF probes, a Hardware Abstraction Layer (HAL) interface, and system service status probes. The kernel-mode eBPF probes dynamically attach to kernel functions of the domestic operating system without requiring kernel recompilation, securely collecting critical performance data such as kernel scheduling latency and system call latency with minimal overhead. The HAL interface encapsulates the access interfaces of different domestic chips, providing a unified query service for upper layers. The system service status probes monitor the running status and resource usage of critical services in the domestic OS.

[0123] At the application layer, full-stack monitoring data is collected through platform software monitoring probe clusters and business application monitoring probe clusters. The platform software monitoring probe cluster includes domestic database probes, domestic middleware probes, and national cryptographic protocol stack probes. The domestic database probes monitor key indicators such as SQL execution plans, lock waits, and buffer hit rates by extending system views and parsing slow SQL logs. The domestic middleware probes monitor thread pool utilization, JVM GC efficiency, and JDBC connection pool status through JMX APIs and custom hooks. The national cryptographic protocol stack probes collect performance data of the SM2 / SM4 algorithm (such as the previously verified time consumption and success rate) by hooking the national cryptographic algorithm library.

[0124] The business application monitoring probe cluster includes office software probes, design and development application probes, and industry-specific application probes. Office software probes monitor document rendering time, plugin loading status, and application unresponsiveness (ANR) events. Design and development application probes monitor drawing loading time, graphics rendering frame rate, and license status. Industry-specific application probes provide monitoring point SDKs for customized applications in specific industries.

[0125] Through the collaborative work of the aforementioned multi-level and multi-dimensional probe clusters, full-stack monitoring data from three different technology stack levels—hardware layer, operating system layer, and application layer—was obtained.

[0126] In addition, the data transmission layer deployed at the network edge is used to identify monitoring data from different technology stack levels that are related in the full-stack monitoring data, to align the related monitoring data with timestamps, to clean the time-stamped full-stack monitoring data, and to transmit the cleaned full-stack monitoring data to the cloud analysis layer.

[0127] Specifically, the data transmission layer includes a data processing and aggregation unit, a secure communication and protocol conversion gateway, and a policy execution and control center. The data cleaning module in the data processing and aggregation unit cleans the data, filters out invalid values, and performs preliminary aggregation through an indicator calculation engine, such as aggregating second-level CPU temperature data into a one-minute average. If the network connection to the cloud is interrupted at this time, the edge cache temporarily stores this data, and resumes transmission after the network is restored to ensure no data loss. Furthermore, the secure communication module in the secure communication and protocol conversion gateway uses the national cryptographic algorithm SM4 to encrypt the aggregated data and achieves two-way authentication through device identity certificates. Finally, the protocol converter converts the internal protocol to the standard HTTPS protocol and reports the encrypted data to the cloud analysis layer. The policy parser in the policy execution and control center receives monitoring policies issued by the cloud analysis layer, parses the JSON-formatted control instructions in the monitoring policies to obtain control tasks, and the task dispatcher distributes the control tasks to the corresponding devices based on device fingerprints.

[0128] Deployed in the cloud or local data center, the cloud analytics layer receives and processes data reported from the data transmission layer, performing core analysis and diagnostic tasks to obtain fault diagnosis results for the target device. Specifically, the cloud analytics layer detects abnormal events in the full-stack monitoring data; analyzes the propagation path of abnormal events in the topology graph, and takes the starting node of the propagation path as the root cause node. The topology graph is constructed based on the monitored objects within the target device and the dependencies between the monitored objects; and matches the abnormal characteristics of the root cause node with known fault characteristics in the device knowledge base to obtain the fault diagnosis results for the target device.

[0129] In addition, the unified data access and governance center in the cloud analytics layer receives data through the data access gateway, the streaming engine cleans and formats the data in real time, and the spatiotemporal alignment module uses the dynamic time warping (DTW) algorithm to accurately align hardware events and software events from different sources and with different sampling frequencies on the timeline for correlation analysis.

[0130] Subsequently, the intelligent analysis and diagnostic engine in the cloud analytics layer begins to operate. First, the dynamic baseline engine within the intelligent analysis and diagnostic engine automatically learns the normal fluctuation patterns of each indicator under different times and scenarios through machine learning, generating a dynamic baseline to reduce false alarms.

[0131] Then, the GNN root cause localization model initiates analysis. This model has pre-constructed a topology graph of the dependencies between devices, services, and metrics, and uses graph neural networks to analyze the anomaly propagation path to accurately locate the root cause node, rather than the surface phenomenon.

[0132] Finally, the knowledge base-driven engine quickly matches the anomaly characteristics of the root cause node with the built-in device knowledge base. Based on the matching results, it generates fault diagnosis results and presents them along with a global topology view through a visual interactive interface and operations portal. Furthermore, the real-time alarm center within the visual interactive interface and operations portal provides alarm management, suppression, and push functions based on tags and levels. The health and reporting system comprehensively calculates the health scores of devices and applications and generates multi-dimensional performance reports.

[0133] In summary, the equipment fault diagnosis system provided in this embodiment, through the collaborative work of various modules, automatically completes the entire process from data collection, anomaly detection, root cause localization to accurate diagnosis within minutes for potential hardware faults that originally required several hours of manual troubleshooting.

[0134] Figure 3 This is a schematic diagram of the structure of the electronic device provided by the present invention, such as... Figure 3 As shown, the electronic device may include a processor 310, a communications interface 320, a memory 330, and a communication bus 340. The processor 310, communications interface 320, and memory 330 communicate with each other via the communication bus 340. The processor 310 can call logical instructions from the memory 330 to execute device fault diagnosis methods.

[0135] Furthermore, the logical instructions in the aforementioned memory 330 can be implemented as software functional units and, when sold or used as independent products, can be stored in a computer-readable storage medium. Based on this understanding, the technical solution of the present invention, essentially, or the part that contributes to the prior art, or a part of the technical solution, can be embodied in the form of a software product. This computer software product is stored in a storage medium 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 described in the various embodiments of the present invention. The aforementioned storage medium includes various media capable of storing program code, such as USB flash drives, portable hard drives, read-only memory (ROM), random access memory (RAM), magnetic disks, or optical disks.

[0136] On the other hand, the present invention also provides a computer program product, which includes a computer program that can be stored on a non-transitory computer-readable storage medium. When the computer program is executed by a processor, the computer is able to perform the device fault diagnosis methods provided by the above methods.

[0137] In another aspect, the present invention also provides a non-transitory computer-readable storage medium having a computer program stored thereon, which, when executed by a processor, is implemented to perform the device fault diagnosis methods provided by the methods described above.

[0138] The device embodiments described above are merely illustrative. The units described as separate components may or may not be physically separate, and the components shown as units may or may not be physical units; that is, they may be located in one place or distributed across multiple network units. Some or all of the modules can be selected to achieve the purpose of this embodiment according to actual needs. Those skilled in the art can understand and implement this without any creative effort.

[0139] Through the above description of the embodiments, those skilled in the art can clearly understand that each embodiment can be implemented by means of software plus necessary general-purpose hardware platforms, and of course, it can also be implemented by hardware. Based on this understanding, the above technical solutions, in essence or the part that contributes to the prior art, can be embodied in the form of a software product. This computer software product can be stored in a computer-readable storage medium, such as ROM / RAM, magnetic disk, optical disk, etc., and includes several instructions to cause a computer device (which may be a personal computer, server, or network device, etc.) to execute the methods described in the various embodiments or some parts of the embodiments.

[0140] Finally, it should be noted that the above embodiments are only used to illustrate the technical solutions of the present invention, and not to limit them; although the present invention has been described in detail with reference to the foregoing embodiments, those skilled in the art should understand that modifications can still be made to the technical solutions described in the foregoing embodiments, or equivalent substitutions can be made to some of the technical features; and these modifications or substitutions do not cause the essence of the corresponding technical solutions to deviate from the spirit and scope of the technical solutions of the embodiments of the present invention.

Claims

1. A method for diagnosing equipment faults, characterized in that, include: Acquire full-stack monitoring data of the target device, wherein the full-stack monitoring data comes from at least two different technology stack layers of the target device; Detect abnormal events in the full-stack monitoring data; The propagation path of the abnormal event in the topology graph is analyzed, and the starting node of the propagation path is taken as the root cause node. The topology graph is constructed based on the monitoring objects in the target device and the dependencies between the monitoring objects. The abnormal features of the root cause node are matched with known fault features in the device knowledge base to obtain the fault diagnosis result of the target device.

2. The equipment fault diagnosis method according to claim 1, characterized in that, The detection of abnormal events in the full-stack monitoring data includes: When the real-time value of any monitoring indicator in the full-stack monitoring data exceeds the corresponding dynamic baseline, the monitoring object corresponding to the monitoring indicator is identified as having an abnormal event. The dynamic baseline of the monitoring indicator is the fluctuation range of the monitoring indicator when the corresponding monitoring object is in normal operation.

3. The equipment fault diagnosis method according to claim 2, characterized in that, The dynamic baseline of any of the monitoring indicators is determined based on the following steps: Obtain the historical value of any of the monitoring indicators under the normal operating conditions of the corresponding monitored object; Analyze the statistical characteristics of the historical data collected to determine the normal fluctuation pattern of any one of the monitoring indicators. The normal fluctuation pattern is used to characterize the numerical distribution pattern of any one of the monitoring indicators. Based on the normal fluctuation pattern, the allowable fluctuation boundary of any of the monitoring indicators is extracted, and the allowable fluctuation boundary is used as the dynamic baseline.

4. The equipment fault diagnosis method according to any one of claims 1 to 3, characterized in that, The analysis of the propagation path of the abnormal event in the topology graph, and the determination of the starting node of the propagation path as the root cause node, includes: The nodes mapped to the monitoring objects corresponding to the abnormal events in the topology graph are marked as abnormal nodes; Tracing back along the directed edges of the topology graph, the running status of upstream nodes that are dependent on the abnormal node is detected, and upstream nodes in abnormal running status are added to the upstream node sequence in sequence to form a propagation path from the abnormal node to each upstream abnormal node. The node in the propagation path that has no upstream dependency is taken as the root cause node.

5. The equipment fault diagnosis method according to claim 4, characterized in that, The detection of the operating status of upstream nodes that are dependent on the abnormal node includes: Obtain the monitoring metrics of the monitoring object corresponding to the upstream node; If the real-time value of the monitoring indicator corresponding to the upstream node exceeds the corresponding dynamic baseline, the upstream node is determined to be in an abnormal operating state.

6. The equipment fault diagnosis method according to any one of claims 1 to 3, characterized in that, The step of matching the abnormal features of the root cause node with known fault features in the device knowledge base to obtain the fault diagnosis result of the target device includes: Extract the abnormal features of the root cause node; Calculate the similarity between the abnormal features and each known fault feature in the equipment knowledge base; The known fault feature with the highest similarity is used as the matching result, and the fault type corresponding to the matching result is used as the fault diagnosis result.

7. The equipment fault diagnosis method according to any one of claims 1 to 3, characterized in that, The acquisition of full-stack monitoring data of the target device includes: Hardware layer data of the target device is collected using a hardware probe. The system probe collects operating system layer data of the target device; The platform software layer data of the target device is collected using a software probe. The target device's business application layer data is collected using a software probe; The full-stack monitoring data includes at least two of the hardware layer data, the operating system layer data, the platform software layer data, and the business application layer data.

8. The equipment fault diagnosis method according to claim 7, characterized in that, If the full-stack monitoring data includes the business application layer data, it also includes: Based on the data analysis of the aforementioned business application layer, operational issues of the business application are identified; Generate an application diagnostic report that includes the aforementioned operational issues; The application diagnostic report will be sent to the software developer of the corresponding business application.

9. The equipment fault diagnosis method according to any one of claims 1 to 3, characterized in that, The detection of abnormal events in the full-stack monitoring data also includes, prior to: Identify monitoring data from different technology stack layers that are related within the full-stack monitoring data; Timestamp alignment is performed on related monitoring data; Perform data cleaning on the timestamp-aligned full-stack monitoring data.

10. The equipment fault diagnosis method according to any one of claims 1 to 3, characterized in that, After obtaining the fault diagnosis result of the target device, the process further includes: The fault diagnosis results are presented in a visualization interface, which also includes at least one of the topology diagram, alarm information, and health report of the target device.

11. A device fault diagnosis system, characterized in that, include: The data acquisition layer is used to acquire full-stack monitoring data of the target device, wherein the full-stack monitoring data comes from at least two different technology stack layers of the target device; The cloud-based analytics layer is used to detect abnormal events in the full-stack monitoring data; The propagation path of the abnormal event in the topology graph is analyzed, and the starting node of the propagation path is taken as the root cause node. The topology graph is constructed based on the monitored objects in the target device and the dependencies between the monitored objects. The abnormal characteristics of the root cause node are matched with the known fault characteristics in the device knowledge base to obtain the fault diagnosis result of the target device.

12. The equipment fault diagnosis system according to claim 11, characterized in that, Also includes: The data transmission layer is used to identify monitoring data from different technology stack levels that are related in the full-stack monitoring data, to align the related monitoring data with timestamps, to clean the time-stamp aligned full-stack monitoring data, and to transmit the cleaned full-stack monitoring data to the cloud analysis layer.

13. An electronic device comprising a memory, a processor, and a computer program stored in the memory and running on the processor, characterized in that, When the processor executes the computer program, it implements the device fault diagnosis method as described in any one of claims 1 to 10.

14. A non-transitory computer-readable storage medium having a computer program stored thereon, characterized in that, When the computer program is executed by the processor, it implements the device fault diagnosis method as described in any one of claims 1 to 10.

Images