Method for discovering and handling faults of xinchuang terminal based on knowledge graph
By constructing a knowledge graph-based fault prediction and historical fault knowledge graph, intelligent discovery and handling of faults in domestically developed IT terminals are achieved, solving the operation and maintenance problems of domestically developed IT platforms and improving the accuracy of fault prediction and operation and maintenance efficiency.
Patent Information
- Authority / Receiving Office
- CN · China
- Patent Type
- Patents(China)
- Current Assignee / Owner
- INSPUR QILU SOFTWARE IND
- Filing Date
- 2022-11-21
- Publication Date
- 2026-08-04
AI Technical Summary
The increasing complexity of IT innovation platform services has led to greater difficulty in operation and maintenance, making the system more complex and difficult for existing technologies to effectively monitor and detect system failures in a timely manner.
By employing a knowledge graph-based approach, a fault prediction knowledge graph and a historical fault knowledge graph are constructed. Through intelligent means of data processing, fault detection, and fault handling, automated fault diagnosis and processing are achieved.
It improves the accuracy and reliability of fault prediction, reduces fault handling time, helps system personnel understand the operating status in a timely manner, optimizes system configuration, and provides a basis for upgrades and expansion.
Smart Images

Figure CN115809183B_ABST
Abstract
Description
Technical Field
[0001] This invention relates to the field of fault handling technology, and in particular to a method for fault detection and handling of domestically developed IT terminals based on knowledge graphs. Background Technology
[0002] Currently, software and hardware are developing rapidly, and application systems based on domestically developed basic software and hardware are also developing rapidly. More and more customers are considering or adopting centralized business solutions. However, with the rapid development of domestic IT platform businesses, the complexity of these businesses is increasing, which not only increases the workload of operation and maintenance but also makes the system more complex. An effective system and application monitoring system is crucial for understanding the usage of business resources and promptly detecting potential system failures, thus ensuring system operation and security.
[0003] With the increasing centralization and complexity of business systems under the current domestic IT innovation platform, the difficulty of operation and maintenance has also increased accordingly. An effective system and application monitoring system is crucial for understanding the usage status of business resources on the domestic IT innovation platform, promptly identifying potential system failures, and ensuring system operation.
[0004] Based on the above, this invention proposes a method for fault detection and handling of domestically developed IT terminals based on knowledge graphs. Summary of the Invention
[0005] To overcome the shortcomings of existing technologies, this invention provides a simple and efficient method for fault detection and handling of information technology application innovation terminals based on knowledge graphs.
[0006] This invention is achieved through the following technical solution:
[0007] A method for fault detection and handling of domestically developed terminals based on knowledge graphs is characterized by: constructing a fault prediction knowledge graph and a historical fault knowledge graph using knowledge graph technology to achieve intelligent data processing, fault detection, and fault handling.
[0008] Includes the following steps:
[0009] Step S1: Data Acquisition and Processing
[0010] The system's data is diverse and heterogeneous. By combining performance data and alarm data for preprocessing and modeling the correlation between different types and levels of data in the system, the accuracy and reliability of information system fault prediction can be effectively improved.
[0011] First, the collected data is cleaned, structured, and normalized to obtain a unified data structure. Then, a fault prediction knowledge graph is constructed based on the preprocessed information data.
[0012] Step S1.1: Real-time data acquisition
[0013] The client collects time-series data of monitoring metrics, including metric data, performance data, and log data; threshold parameters are set, and simple rule filters are specified based on the characteristics of key metrics and the key needs of the application to filter out a portion of suspected anomalies.
[0014] Step S1.2: Data Preprocessing
[0015] First, clean the acquired data to remove incomplete and redundant data;
[0016] Then, data structuring is implemented, semi-structured data is packaged and knowledge is extracted, and after being transformed into structured data, entity extraction is performed.
[0017] The semi-structured data includes, but is not limited to, historical fault data, historical fault repair records, experience data of operation and maintenance engineers, technical manuals, and user manuals;
[0018] Finally, the data is normalized to unify the fault prediction standards;
[0019] Step S2, Fault Discovery
[0020] Step S2.1, Fault Prediction
[0021] Construct a fault prediction knowledge graph and obtain a fault prediction model by pre-training the fault prediction knowledge graph to predict faults hidden in the collected data.
[0022] Step S2.2: Construct a historical fault knowledge graph
[0023] For each type of fault, a causal discovery algorithm is used to train and analyze historical fault data to construct the indicator data change characteristics of each type of fault, which serves as a historical fault knowledge graph for fault similarity judgment.
[0024] Step S2.3: Through the above steps, the associated fault data is aggregated into an alarm knowledge graph. The fault rate prediction module further predicts the fault rate by comparing the similarity between the fault knowledge graph to be predicted and the historical fault knowledge graph, thereby improving the accuracy of fault prediction.
[0025] Step S2.4: Use the causal discovery algorithm to calculate the correlation of abnormal events, use high-correlation links to represent the propagation path and characteristics of this type of abnormal event, and locate the root cause of the abnormal event.
[0026] Step S3, Troubleshooting
[0027] By using knowledge graphs to associate the context of abnormal events, false alarms can be identified and suppressed. The similarity between the false alarms and the context of historical false alarms can be used to determine the authenticity of the alarms, thereby suppressing false alarms.
[0028] The alarm convergence module aggregates and organizes data into a single valid message based on the correlation between indicator data through filtering, compression, merging, and deduplication.
[0029] The alarm self-healing module introduces artificial intelligence technology to train historical fault repair data and builds a Bayesian fault self-healing model, realizing artificial intelligence fault self-healing to replace manual fault handling, thereby achieving rapid and automated processing of terminal faults.
[0030] The event scheduling module will automatically repair events that support fault self-healing through the alarm self-healing module, while events that require manual repair will be repaired manually through automatic work order scheduling technology.
[0031] The alarm notification module, through alarm notification policy configuration, notifies users of alarm events, reminding maintenance personnel to repair faults in a timely manner.
[0032] In step S1.1, threshold parameters are set through alarm strategies, or the threshold parameters are automatically configured by training a model based on historical data.
[0033] In step S2.1, the steps for constructing the fault prediction knowledge graph are as follows:
[0034] Step S2.1.1: Based on the preset information system equipment manual and related knowledge base, determine the association between each information entity in the information data and the preset fault type;
[0035] Step S2.1.2: Based on the correlation between information entities and preset fault types, select some information entities from the information entities as nodes of the fault prediction knowledge graph, and determine the relationship between adjacent nodes;
[0036] The information data was trained using multiple causal discovery algorithms. The causal edges output by each algorithm were combined with manual review and screening to determine the final causal edges. Causal edges refer to the node information corresponding to entities in the graph and the edge information corresponding to the relationship between entities.
[0037] Step S2.1.3: Construct a fault prediction knowledge graph based on all nodes and their relationships.
[0038] Based on the logic of all information entities, their relationships, and entities, a fault prediction knowledge graph is constructed.
[0039] In step S2.1.1, the correlation is determined as follows:
[0040] S2.1.1.1. The MD5 algorithm is adopted. The fingerprint information of each alarm is calculated by using the adoption policy, rules, terminal unique ID, metric, metric field and metric tag attribute. Alarms with the same fingerprint are considered to be the same alarm message.
[0041] S2.1.1.2 Extract the association relationship of the module to which the alarm message belongs;
[0042] S2.1.1.3 When a computer room failure occurs, alarm messages generated within the same computer room will be aggregated and organized into a single valid message.
[0043] In step S2.2, the steps for constructing the historical fault knowledge graph are as follows:
[0044] Step S2.2.1, Event Generation
[0045] The fault prediction model is used to detect real-time indicator data, and abnormal events are generated when an anomaly occurs.
[0046] Step S2.2.2: Fault Propagation Diagram Construction
[0047] Similar to the fault prediction knowledge graph construction step in step S2.1, the correlation between abnormal events is mined to construct a fault propagation graph;
[0048] Step S2.2.3: Classification and Merging
[0049] Clustering algorithms are used to classify and merge the generated fault propagation graph and the historical fault knowledge graph;
[0050] Step S2.2.4, Labeling
[0051] The root cause annotation is performed on the merged fault knowledge graph, and each type of historical fault knowledge graph is labeled with a fault type.
[0052] In step S2.3, the failure probability corresponding to the knowledge graph to be predicted is determined, and the steps are as follows:
[0053] Step S2.3.1: Based on the intersection of the subgraph set of the knowledge graph to be predicted and the fault subgraph set of any historical fault knowledge graph, determine the same subgraph;
[0054] Step S2.3.2: Based on the determined identical subgraphs, the weights corresponding to the identical subgraphs, and the union of the subgraph set and the fault subgraph set, determine the similarity between the knowledge graph to be predicted and any historical fault knowledge graph;
[0055] Step S2.3.3: Sort the similarity scores and obtain the historical fault knowledge graph with the highest similarity score to the knowledge graph to be predicted. This similarity score is the fault rate of the knowledge graph to be predicted.
[0056] In step S2.4, the fault prediction knowledge graph contains causal inference relationships derived from historical alarm events. The root cause localization process based on the fault prediction knowledge graph is as follows:
[0057] S2.4.1 Input the time slice samples of abnormal events into the alarm knowledge graph to obtain the cause-effect graph of alarm nodes;
[0058] S2.4.2 Calculate the weight of each causal edge in the cause-effect graph of the alarm node. The weight of the causal edge reflects the probability of the suspected root cause path of the abnormal event under that time slice.
[0059] S2.4.3 Sort the weights of the causal edges and select the causal edge with the highest weight as the final root cause path.
[0060] In step S3, the fault handling process is as follows:
[0061] Step S3.1, Alarm Suppression
[0062] Step S3.1.1: Parsing and storing the call chain log data.
[0063] Set up an analysis window, analyze the call chain within the time window of the alarm based on the alarm log, and store it in the database;
[0064] Step S3.1.2, Map Construction
[0065] Construct a complete entity tree structure based on the reference relationships in the call chain;
[0066] Step S3.1.3: Construction of the indicator table
[0067] Analyze the structure of the call chain, find the relevant metrics on the call chain that occur within the window time, analyze the occurrence frequency of the relevant metrics within the analysis window time, and record the statistical information of the relevant metrics in the metric table;
[0068] Step S3.1.4, Alarm Authenticity Analysis
[0069] Based on the call chain of the current alarm, find the call chain in the past that had the same metric but caused a false alarm, and search for the relevant metrics that occurred on the current call chain and the number of times the metric occurred. Calculate the similarity between the local alarm and the historical alarm using the call chain and the relevant metrics on the call chain; if the similarity is higher than a custom threshold, the current alarm is considered a false alarm, otherwise it is a real alarm.
[0070] Step S3.2, Alarm Convergence
[0071] Step S3.2.1: Set the time slice granularity
[0072] Real-time acquisition of alarm data within the time slice, i.e., the statistical period of the alarm rule;
[0073] Step S3.2.2, Alarm Classification
[0074] The raw alarm data is classified according to the collection indicators of the alarm data; the collection indicators of the alarm data can be any one of CPU utilization, disk utilization, network traffic or terminal unique identifier.
[0075] Step S3.2.3: Converge alarm events.
[0076] Query the alarm knowledge graph and converge alarm events by system; the convergence format is as follows: System 1: {Node 1: [Alarm type 1, Alarm type 2...], Node 2: [Alarm type 1, Alarm type 2...]...};
[0077] Step S3.3, Fault Self-Healing
[0078] Step S3.3.1: Fault parameter data preprocessing
[0079] The root cause path data obtained in the root cause localization step is organized into fault parameter data, the fault parameter data is moved into the historical fault database, and the fault type and corresponding repair program are stored.
[0080] Step S3.3.2: Construct a Bayesian fault self-healing model
[0081] The prior probability is calculated based on the equipment performance indicators, and the conditional probability, adjustment factor, and posterior probability are calculated based on the fault parameter data. Then, the Markov transition matrix method model is used to optimize the prior probability and calculate the adjustment factor and posterior probability based on the fault parameter data, thereby calculating the self-healing probability corresponding to the fault type.
[0082] The root cause path data acquired in real time is input into the fault self-healing model to obtain the preset fault self-healing operable index for this fault type; when the self-healing operable index is greater than the custom threshold, the corresponding repair program for this fault type is used for automatic repair.
[0083] Step S3.4, Event Scheduling
[0084] For events requiring manual repair, work orders are initiated through automated work order scheduling technology, and maintenance personnel repair them manually; for events that can heal themselves, the above-mentioned fault self-healing model is used to call the corresponding repair program to achieve automated repair.
[0085] Step S3.5, Alarm Notification
[0086] The alarm notification module notifies users of alarm events through alarm notification policy configuration. The notification content supports preset templates and custom template configurations. According to the alarm notification silence policy, the alarm notification module ignores alarms that meet the conditions during the silence period, that is, it does not send alarm notifications.
[0087] A device for fault detection and handling of domestically developed information technology terminals based on knowledge graphs, characterized in that it includes a memory and a processor; the memory is used to store computer programs, and the processor is used to execute the computer programs to implement the above-mentioned method steps.
[0088] A readable storage medium, characterized in that: a computer program is stored on the readable storage medium, and the computer program, when executed by a processor, implements the above-described method steps.
[0089] The beneficial effects of this invention are: the method for fault detection and handling of information technology application terminals based on knowledge graphs can detect system faults in a timely manner through a centralized monitoring system, reduce fault handling time, enable users to understand the operating status of the system and applications correctly and in a timely manner, help system personnel to perform necessary system optimization and configuration changes, and provide a reasonable basis for system upgrades and expansions. Attached Figure Description
[0090] To more clearly illustrate the technical solutions in the embodiments of the present 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 the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.
[0091] Appendix Figure 1 This is a schematic diagram of the method for detecting and handling faults in domestically developed information technology terminals based on knowledge graphs, as described in this invention. Detailed Implementation
[0092] To enable those skilled in the art to better understand the technical solutions of this invention, the technical solutions in the embodiments of this invention will be clearly and completely described below in conjunction with the embodiments of this invention. Obviously, the described embodiments are merely some embodiments of this invention, and not all embodiments. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort should fall within the scope of protection of this invention.
[0093] Maintenance personnel can quickly analyze the causes of faults using the alarm center's statistical, notification, and processing modules, freeing them from tedious tasks. The centralized monitoring system allows for timely detection of system faults, reducing troubleshooting time. Simultaneously, it provides a basis for system upgrades and expansions.
[0094] This knowledge graph-based method for fault detection and handling of domestically developed terminals utilizes knowledge graph technology to construct a fault prediction knowledge graph and a historical fault knowledge graph, thereby achieving intelligent data processing, fault detection, and fault handling.
[0095] Includes the following steps:
[0096] Step S1: Data Acquisition and Processing
[0097] The system's data is diverse and heterogeneous. By combining performance data and alarm data for preprocessing and modeling the correlation between different types and levels of data in the system, the accuracy and reliability of information system fault prediction can be effectively improved.
[0098] First, the collected data is cleaned, structured, and normalized to obtain a unified data structure. Then, a fault prediction knowledge graph is constructed based on the preprocessed information data.
[0099] Step S1.1: Real-time data acquisition
[0100] The client collects time-series data of monitoring metrics, including metric data, performance data, and log data; threshold parameters are set, and simple rule filters are specified based on the characteristics of key metrics and the key needs of the application to filter out a portion of suspected anomalies.
[0101] Step S1.2: Data Preprocessing
[0102] First, clean the acquired data to remove incomplete data (too short online time, too long or too short collection interval, truncated data, etc.) and redundant data (filter out data that has no impact on the fault to reduce the workload of subsequent data analysis; data that has no impact includes some dataset information within the normal threshold range, system log data, etc.).
[0103] Then, data structuring is implemented, semi-structured data is packaged and knowledge is extracted, and after being transformed into structured data, entity extraction is performed.
[0104] The semi-structured data includes, but is not limited to, historical fault data, historical fault repair records, experience data of operation and maintenance engineers, technical manuals, and user manuals;
[0105] Finally, the data is normalized to unify the fault prediction standards;
[0106] Step S2, Fault Discovery
[0107] Fault discovery is based on knowledge graphs to realize the processing of collected data into fault root cause information, including fault prediction, construction of historical fault knowledge graphs, fault rate prediction and root cause localization steps;
[0108] Step S2.1, Fault Prediction
[0109] Construct a fault prediction knowledge graph and obtain a fault prediction model by pre-training the fault prediction knowledge graph to predict faults hidden in the collected data.
[0110] Step S2.2: Construct a historical fault knowledge graph
[0111] For each type of fault, a causal discovery algorithm is used to train and analyze historical fault data to construct the indicator data change characteristics of each type of fault, which serves as a historical fault knowledge graph for fault similarity judgment.
[0112] Step S2.3: Through the above steps, the associated fault data is aggregated into an alarm knowledge graph. The fault rate prediction module further predicts the fault rate by comparing the similarity between the fault knowledge graph to be predicted and the historical fault knowledge graph, thereby improving the accuracy of fault prediction.
[0113] Step S2.4: Root cause services and initial anomaly services are usually located on anomaly propagation chains composed of a series of anomaly services. Therefore, the root cause localization module analyzes the anomaly propagation chains implicit in the alarm knowledge graph to determine a set of candidate anomaly root cause services from possible anomaly propagation chains. Based on this, the causal discovery algorithm is used to calculate the correlation of anomaly events, and the propagation path and characteristics of such anomaly events are represented by highly correlated links to perform root cause localization of anomaly events.
[0114] Step S3, Troubleshooting
[0115] Fault handling achieves automated fault diagnosis and decision-making through alarm suppression, alarm convergence, fault self-healing, event scheduling, and alarm notification. Fault self-healing is achieved in some scenarios, and automated work order scheduling is achieved in other scenarios, improving operation and maintenance efficiency and reducing fault handling time.
[0116] Due to the inherent uncertainty of AI predictions and the inherent volatility and lack of periodicity in detection indicators, false alarms are likely to occur. When used extensively in production environments, the number of false alarms can accumulate, potentially creating an alarm storm. To address this issue, a knowledge graph is used to associate the context of anomaly events to identify and suppress false alarms. Furthermore, the similarity between the false alarms and their historical contexts is used to determine their authenticity, thereby suppressing false alarms.
[0117] The alarm convergence module uses filtering, compression, merging, and deduplication based on the correlation between indicator data to finally aggregate and organize them into a valid message. On the one hand, this can prevent alarm storms, and on the other hand, correlation compression can reduce invalid alarms by 90%, thus improving alarm efficiency.
[0118] The alarm self-healing module introduces artificial intelligence technology to train historical fault repair data and builds a Bayesian fault self-healing model, realizing artificial intelligence fault self-healing to replace manual fault handling, thereby achieving rapid and automated processing of terminal faults.
[0119] The event scheduling module will automatically repair events that support fault self-healing through the alarm self-healing module, while events that require manual repair will be repaired manually through automatic work order scheduling technology.
[0120] The alarm notification module, through alarm notification policy configuration, notifies users of alarm events, reminding maintenance personnel to repair faults in a timely manner.
[0121] In step S1.1, threshold parameters are set through alarm strategies, or the threshold parameters are automatically configured by training a model based on historical data.
[0122] The collected historical data contains a large number of correlations and causal relationships. The inherent topology of terminal devices and the calling relationships of system applications can quickly construct entities and relationships in a knowledge graph. In step S2.1, the steps for constructing the fault prediction knowledge graph are as follows:
[0123] Step S2.1.1: Based on the preset information system equipment manual and related knowledge base, determine the association between each information entity in the information data and the preset fault type;
[0124] In step S2.1.1, the correlation is determined as follows:
[0125] S2.1.1.1 Alarm messages share the same dimensional attributes, such as the same policy name, rule name, deployment attributes (terminal, server, host, etc.), and metric type (memory, CPU, network utilization, etc.). Using the MD5 algorithm, a fingerprint is calculated for each alarm based on the policy, rule, unique terminal ID, metric, metric field, and metric tag attributes. Alarms with the same fingerprint are considered to be the same alarm message.
[0126] S2.1.1.2 Extract the association relationship of the module to which the alarm message belongs;
[0127] When module A calls module B, if module B encounters an exception, module A will generally also encounter a related exception. We can explore this correlation by analyzing historical exception events.
[0128] S2.1.1.3 When a computer room failure occurs, alarm messages generated within the same computer room do not need to be generated or retrieved individually; they will eventually be aggregated into a single valid message.
[0129] Step S2.1.2: Based on the correlation between information entities and preset fault types, select some information entities from the information entities as nodes of the fault prediction knowledge graph, and determine the relationship between adjacent nodes;
[0130] The information data was trained using multiple causal discovery algorithms. The causal edges output by each algorithm were combined with manual review and screening to determine the final causal edges. Causal edges refer to the node information corresponding to entities in the graph and the edge information corresponding to the relationship between entities.
[0131] Step S2.1.3: Construct a fault prediction knowledge graph based on all nodes and their relationships.
[0132] Based on a combination of pre-defined system equipment manuals and relevant knowledge bases accumulated from the experience of operation and maintenance experts, the correlation between each information entity in the information data and a pre-defined fault type is determined. Based on this correlation, a subset of entities are selected as nodes in the fault prediction knowledge graph, and the relationships between adjacent nodes are determined. The fault prediction knowledge graph is constructed based on the logic of all information entities, their relationships, and their constituent entities.
[0133] In step S2.2, the steps for constructing the historical fault knowledge graph are as follows:
[0134] Step S2.2.1, Event Generation
[0135] The fault prediction model is used to detect real-time indicator data, and abnormal events are generated when an anomaly occurs.
[0136] Step S2.2.2: Fault Propagation Diagram Construction
[0137] Similar to the fault prediction knowledge graph construction step in step S2.1, the correlation between abnormal events is mined to construct a fault propagation graph;
[0138] Step S2.2.3: Classification and Merging
[0139] Clustering algorithms are used to classify and merge the generated fault propagation graph and the historical fault knowledge graph;
[0140] Step S2.2.4, Labeling
[0141] The root cause annotation is performed on the merged fault knowledge graph, and each type of historical fault knowledge graph is labeled with a fault type.
[0142] In step S2.3, the failure probability corresponding to the knowledge graph to be predicted is determined, and the steps are as follows:
[0143] Step S2.3.1: Based on the intersection of the subgraph set of the knowledge graph to be predicted and the fault subgraph set of any historical fault knowledge graph, determine the same subgraph;
[0144] Step S2.3.2: Based on the determined identical subgraphs, the weights corresponding to the identical subgraphs, and the union of the subgraph set and the fault subgraph set, determine the similarity between the knowledge graph to be predicted and any historical fault knowledge graph;
[0145] Step S2.3.3: Sort the similarity scores and obtain the historical fault knowledge graph with the highest similarity score to the knowledge graph to be predicted. This similarity score is the fault rate of the knowledge graph to be predicted.
[0146] In step S2.4, the fault prediction knowledge graph contains causal inference relationships derived from historical alarm events. The root cause localization process based on the fault prediction knowledge graph is as follows:
[0147] S2.4.1 Input the time slice samples of abnormal events into the alarm knowledge graph to obtain the cause-effect graph of alarm nodes;
[0148] S2.4.2 Calculate the weight of each causal edge in the cause-effect graph of the alarm node. The weight of the causal edge reflects the probability of the suspected root cause path of the abnormal event under that time slice.
[0149] S2.4.3 Sort the weights of the causal edges and select the causal edge with the highest weight as the final root cause path.
[0150] The final set of possible root cause propagation paths essentially contains the true root causes. This method can effectively automate root cause deduction, shorten the intervention time for operations and maintenance personnel, and the visualized deduction path also has good interpretability, making it easy to review and optimize.
[0151] In step S3, the fault handling process is as follows:
[0152] Step S3.1, Alarm Suppression
[0153] This method involves associating the context of anomaly events with interpretable knowledge graphs and identifying and suppressing false alarms. The steps include:
[0154] Step S3.1.1: Parsing and storing the call chain log data.
[0155] Set up an analysis window, analyze the call chain within the time window of the alarm based on the alarm log, and store it in the database;
[0156] Step S3.1.2, Map Construction
[0157] Construct a complete entity tree structure based on the reference relationships in the call chain;
[0158] Step S3.1.3: Construction of the indicator table
[0159] Analyze the structure of the call chain, find the relevant metrics on the call chain that occur within the window time, analyze the occurrence frequency of the relevant metrics within the analysis window time, and record the statistical information of the relevant metrics in the metric table;
[0160] Step S3.1.4, Alarm Authenticity Analysis
[0161] Based on the call chain of the current alarm, find the call chain in the past that had the same metric but caused a false alarm, and search for the relevant metrics that occurred on the current call chain and the number of times the metric occurred. Calculate the similarity between the local alarm and the historical alarm using the call chain and the relevant metrics on the call chain; if the similarity is higher than a custom threshold, the current alarm is considered a false alarm, otherwise it is a real alarm.
[0162] The above steps can preserve historical false alarm records and use the contextual similarity with historical false alarms to determine the authenticity of alarms, thereby suppressing false alarms.
[0163] Step S3.2, Alarm Convergence
[0164] Alarm convergence, based on the correlation between alarm events, converges alarm events into a system-wide knowledge graph, effectively suppressing the number and frequency of alarm messages. Alarm convergence includes the following main steps:
[0165] Step S3.2.1: Set the time slice granularity
[0166] Real-time acquisition of alarm data within the time slice, i.e., the statistical period of the alarm rule;
[0167] Step S3.2.2, Alarm Classification
[0168] The raw alarm data is classified according to the collection metrics of the alarm data; the collection metrics of the alarm data can be any one of CPU utilization, disk utilization, network traffic or terminal unique identifiers such as IP, MAC, etc.
[0169] Step S3.2.3: Converge alarm events.
[0170] Query the alarm knowledge graph and converge alarm events by system; the convergence format is as follows: System 1: {Node 1: [Alarm type 1, Alarm type 2...], Node 2: [Alarm type 1, Alarm type 2...]...};
[0171] Step S3.3, Fault Self-Healing
[0172] This patent employs artificial intelligence (AI) technology to train historical fault repair data, constructing a Bayesian fault self-healing model. This model enables AI-powered fault self-healing to replace manual fault handling, thereby achieving rapid and automated processing of terminal faults. The construction of the fault self-healing model used in this patent includes the following steps:
[0173] Step S3.3.1: Fault parameter data preprocessing
[0174] The root cause path data obtained in the root cause localization step is organized into fault parameter data, the fault parameter data is moved into the historical fault database, and the fault type and corresponding repair program are stored.
[0175] Step S3.3.2: Construct a Bayesian fault self-healing model
[0176] The prior probability is calculated based on the equipment performance indicators, and the conditional probability, adjustment factor, and posterior probability are calculated based on the fault parameter data. Then, the Markov transition matrix method model is used to optimize the prior probability and calculate the adjustment factor and posterior probability based on the fault parameter data, thereby calculating the self-healing probability corresponding to the fault type.
[0177] The root cause path data acquired in real time is input into the fault self-healing model to obtain the preset fault self-healing operable index for this fault type; when the self-healing operable index is greater than the custom threshold, the corresponding repair program for this fault type is used for automatic repair.
[0178] Step S3.4, Event Scheduling
[0179] For events requiring manual repair, work orders are initiated through automated work order scheduling technology, and maintenance personnel repair them manually; for events that can heal themselves, the above-mentioned fault self-healing model is used to call the corresponding repair program to achieve automated repair.
[0180] Step S3.5, Alarm Notification
[0181] The alarm notification module notifies users of alarm events through alarm notification policy configuration. Notification methods include, but are not limited to, email, SMS, in-app notifications, and DingTalk. Notification content supports preset templates and custom template configurations. Based on the alarm notification silence policy, the alarm notification module ignores alarms that meet certain conditions during the silence period, meaning no alarm notification is sent.
[0182] This knowledge graph-based method for fault detection and handling of domestically developed terminals is compatible with operating systems such as NeoKylin, Deepin, and Puhua based on various domestic CPUs, and is also compatible with Firefox and Chromium browsers in a fully domestic software and hardware environment. It has good versatility, flexibility and portability.
[0183] The device for detecting and handling faults in domestically developed IT terminals based on knowledge graphs includes a memory and a processor; the memory is used to store computer programs, and the processor is used to execute the computer programs to implement the above-described method steps.
[0184] The readable storage medium stores a computer program that, when executed by a processor, implements the above-described method steps.
[0185] This knowledge graph-based method for detecting and handling faults in domestically developed IT terminals is compatible with and adaptable to domestic system environments. It can not only clean up system data regularly to ensure stable system operation, but also back up system data regularly to prevent data loss, or restore data in a timely manner using backup data if data is lost.
[0186] When using it, you can dynamically set up data cleaning or backup as needed, configure and start multiple tasks without affecting each other, which is relatively flexible.
[0187] Furthermore, this knowledge graph-based method for detecting and handling faults in domestically developed IT terminals allows for backups via user-uploaded plugins or scripts, with backup and cleanup tasks that can be started or stopped at any time.
[0188] The embodiments described above are merely one specific implementation of the present invention. Ordinary changes and substitutions made by those skilled in the art within the scope of the technical solution of the present invention should be included within the protection scope of the present invention.
Claims
1. A knowledge graph-based fault discovery and disposal method for a Xincheng terminal, characterized in that: By utilizing knowledge graph technology, we can construct a fault prediction knowledge graph and a historical fault knowledge graph to achieve intelligent data processing, fault detection, and fault handling. Includes the following steps: Step S1: Data Acquisition and Processing By combining performance data and alarm data for preprocessing, and modeling the correlation between different types and levels of data in the system; firstly, the collected data is cleaned, structured and normalized to obtain a unified data structure, and then a fault prediction knowledge graph is constructed based on the preprocessed information data; Step S1.1: Real-time data acquisition The client collects time-series data of monitoring metrics, including metric data, performance data, and log data; threshold parameters are set, and simple rule filters are specified based on the characteristics of key metrics and the key needs of the application to filter out a portion of suspected anomalies. Step S1.2: Data Preprocessing First, clean the acquired data to remove incomplete and redundant data; Then, data structuring is implemented, semi-structured data is packaged and knowledge is extracted, and after being transformed into structured data, entity extraction is performed. The semi-structured data includes, but is not limited to, historical fault data, historical fault repair records, experience data of operation and maintenance engineers, technical manuals, and user manuals; Finally, the data is normalized to unify the fault prediction standards; Step S2, Fault Discovery Step S2.1, Fault Prediction Construct a fault prediction knowledge graph and obtain a fault prediction model by pre-training the fault prediction knowledge graph to predict faults hidden in the collected data. In step S2.1, the steps for constructing the fault prediction knowledge graph are as follows: Step S2.1.1: Based on the preset information system equipment manual and related knowledge base, determine the association between each information entity in the information data and the preset fault type; Step S2.1.2: Based on the correlation between information entities and preset fault types, select some information entities from the information entities as nodes of the fault prediction knowledge graph, and determine the relationship between adjacent nodes. The information data was trained using multiple causal discovery algorithms. The causal edges output by each algorithm were combined with manual review and screening to determine the final causal edges. Causal edges refer to the node information corresponding to entities in the graph and the edge information corresponding to the relationship between entities. Step S2.1.3: Construct a fault prediction knowledge graph based on all nodes and their relationships. Based on the logic of all information entities-relationships-entities, a fault prediction knowledge graph is constructed. Step S2.2: Construct a historical fault knowledge graph For each type of fault, a causal discovery algorithm is used to train and analyze historical fault data to construct the indicator data change characteristics of each type of fault, which serves as a historical fault knowledge graph for fault similarity judgment. In step S2.2, the steps for constructing the historical fault knowledge graph are as follows: Step S2.2.1, Event Generation The fault prediction model is used to detect real-time indicator data, and abnormal events are generated when an anomaly occurs. Step S2.2.2: Fault Propagation Diagram Construction Similar to the fault prediction knowledge graph construction step in step S2.1, the correlation between abnormal events is mined to construct a fault propagation graph; Step S2.2.3: Classification and Merging Clustering algorithms are used to classify and merge the generated fault propagation graph and the historical fault knowledge graph; Step S2.2.4, Labeling The root cause annotation is performed on the merged fault knowledge graph, and each type of historical fault knowledge graph is labeled with the fault type. Step S2.3: Through the above steps, the associated fault data is aggregated into an alarm knowledge graph. The fault rate prediction module further predicts the fault rate by comparing the similarity between the fault knowledge graph to be predicted and the historical fault knowledge graph, thereby improving the accuracy of fault prediction. Step S2.4: Use the causal discovery algorithm to calculate the correlation of abnormal events, use high-correlation links to represent the propagation path and characteristics of abnormal events, and locate the root cause of abnormal events. In step S2.4, the fault prediction knowledge graph contains causal inference relationships derived from historical alarm events. The root cause localization process based on the fault prediction knowledge graph is as follows: S2.4.1 Input the time slice samples of abnormal events into the alarm knowledge graph to obtain the cause-effect graph of alarm nodes; S2.4.2 Calculate the weight of each causal edge in the cause-effect graph of the alarm node. The weight of the causal edge reflects the probability of the suspected root cause path of the abnormal event under that time slice. S2.4.3 Sort the weights of the causal edges and select the causal edge with the highest weight as the final root cause path; Step S3, Troubleshooting By using knowledge graphs to associate the context of abnormal events, false alarms can be identified and suppressed. The similarity between the false alarms and the context of historical false alarms can be used to determine the authenticity of the alarms, thereby suppressing false alarms. The alarm convergence module uses filtering, compression, merging, and deduplication to aggregate and organize the alarm data into a single valid message based on the correlation between the indicator data. The alarm self-healing module introduces artificial intelligence technology to train historical fault repair data and builds a Bayesian fault self-healing model, realizing artificial intelligence fault self-healing to replace manual fault handling, thereby achieving rapid and automated processing of terminal faults. The event scheduling module will automatically repair events that support fault self-healing through the alarm self-healing module, while events that require manual repair will be repaired manually through automatic work order scheduling technology. The alarm notification module, through alarm notification policy configuration, notifies users of alarm events, reminding maintenance personnel to repair faults in a timely manner.
2. The knowledge graph-based fault discovery and disposal method for the Xincheng terminal according to claim 1, characterized in that: In step S1.1, threshold parameters are set through alarm strategies, or the threshold parameters are automatically configured by training a model based on historical data.
3. The knowledge graph-based fault discovery and disposal method for the Xincheng terminal according to claim 1, characterized in that: In step S2.1.1, the correlation is determined as follows: S2.1.1.
1. The MD5 algorithm is adopted. The fingerprint information of each alarm is calculated by using the adoption policy, rules, terminal unique ID, metric, metric field and metric tag attribute. Alarms with the same fingerprint are considered to be the same alarm message. S2.1.1.2 Extract the association relationship of the module to which the alarm message belongs; S2.1.1.3 When a computer room failure occurs, alarm messages generated within the same computer room will be aggregated and organized into a single valid message.
4. The knowledge graph-based fault discovery and disposal method for the Xincheng terminal according to claim 1, characterized in that: In step S2.3, the failure probability corresponding to the knowledge graph to be predicted is determined, and the steps are as follows: Step S2.3.1: Based on the intersection of the subgraph set of the knowledge graph to be predicted and the fault subgraph set of any historical fault knowledge graph, determine the same subgraph; Step S2.3.2: Based on the determined identical subgraphs, the weights corresponding to the identical subgraphs, and the union of the subgraph set and the fault subgraph set, determine the similarity between the knowledge graph to be predicted and any historical fault knowledge graph; Step S2.3.3: Sort the similarity scores and obtain the historical fault knowledge graph with the highest similarity score to the knowledge graph to be predicted. This similarity score is the fault rate of the knowledge graph to be predicted.
5. The knowledge graph-based fault discovery and disposal method for the Xincheng terminal according to claim 1, characterized in that: In step S3, the fault handling process is as follows: Step S3.1, Alarm Suppression Step S3.1.1: Parsing and storing the call chain log data. Set up an analysis window, analyze the call chain within the time window of the alarm based on the alarm log, and store it in the database; Step S3.1.2, Map Construction Construct a complete entity tree structure based on the reference relationships in the call chain; Step S3.1.3: Construction of the indicator table Analyze the structure of the call chain, find the relevant metrics on the call chain that occur within the window time, analyze the occurrence frequency of the relevant metrics within the analysis window time, and record the statistical information of the relevant metrics in the metric table; Step S3.1.4, Alarm Authenticity Analysis Based on the call chain of the current alarm, find the call chain of the same metric in the past that caused a false alarm, and search for the relevant metric that occurred on the current call chain and the number of times the metric occurred. Calculate the similarity between the local alarm and the historical alarm by using the call chain and the relevant metric on the call chain; if the similarity is higher than a custom threshold, the current alarm is considered a false alarm, otherwise it is a real alarm. Step S3.2, Alarm Convergence Step S3.2.1: Set the time slice granularity Real-time acquisition of alarm data within the time slice, i.e., the statistical period of the alarm rule; Step S3.2.2, Alarm Classification The raw alarm data is classified according to the collection metrics of the alarm data; the collection metrics of the alarm data can be any one of CPU utilization, disk utilization, network traffic or terminal unique identifier. Step S3.2.3: Converge alarm events. Query the alarm knowledge graph and converge alarm events by system; the convergence format is as follows: System 1: {Node 1: [Alarm type 1, Alarm type 2...], Node 2: [Alarm type 1, Alarm type 2...]...}; Step S3.3, Fault Self-Healing Step S3.3.1: Fault parameter data preprocessing The root cause path data obtained in the root cause localization step is organized into fault parameter data, the fault parameter data is moved into the historical fault database, and the fault type and corresponding repair program are stored. Step S3.3.2: Construct a Bayesian fault self-healing model The prior probability is calculated based on the equipment performance indicators, and the conditional probability, adjustment factor, and posterior probability are calculated based on the fault parameter data. Then, the Markov transition matrix method model is used to optimize the prior probability calculation. The adjustment factor and posterior probability are calculated based on the fault parameter data, thereby calculating the self-healing probability corresponding to the fault type. The root cause path data acquired in real time is input into the fault self-healing model to obtain the preset fault self-healing operable index for this fault type; when the self-healing operable index is greater than the custom threshold, the corresponding repair program for this fault type is used for automatic repair. Step S3.4, Event Scheduling For events requiring manual repair, work orders are initiated through automated work order scheduling technology, and maintenance personnel repair them manually; for events that can heal themselves, the above-mentioned fault self-healing model is used to call the corresponding repair program to achieve automated repair. Step S3.5, Alarm Notification The alarm notification module notifies users of alarm events through alarm notification policy configuration. The notification content supports preset templates and custom template configurations. According to the alarm notification silence policy, the alarm notification module ignores alarms that meet the conditions during the silence period, that is, it does not send alarm notifications.
6. A device for knowledge graph-based fault discovery and disposal of a Xincheng terminal, characterized in that: It includes a memory and a processor; the memory is used to store a computer program, and the processor is used to execute the computer program to implement the steps of the method as described in any one of claims 1 to 5.
7. A readable storage medium characterized by: The readable storage medium stores a computer program that, when executed by a processor, implements the steps of the method as described in any one of claims 1 to 5.