A server failure prediction system and method

Abstract

The application relates to the technical field of server fault prediction, and discloses a server fault prediction system and method. The method comprises the following steps: collecting running index data streams of server components through a monitoring agent to form an initial running data pool; performing multi-level cleaning and context association analysis on the data to construct a high-quality running data set; generating a server health state portrait and establishing a dynamic health state baseline model based on the set; constructing a knowledge graph capable of representing fault causal relationships by analyzing the deviation mode of real-time indexes and the baseline model; and driving a risk calculation engine by using the knowledge graph to output the fault probability of the components and a maintenance scheme. The method realizes more accurate and more forward prediction of server faults by improving data quality and introducing knowledge reasoning, and effectively supports intelligent operation and maintenance decisions.

Description

Technical Field

[0001] This invention relates to the field of server fault prediction technology, specifically to a server fault prediction system and method. Background Technology

[0002] Currently, data centers and cloud service platforms generally rely on server clusters to support business operations, making their stability crucial. The industry typically uses monitoring agents to collect operational metrics data of server components, such as CPU utilization, memory usage, and disk I / O, and then uses this historical data to build statistical or machine learning models for fault prediction. Common existing technical solutions include setting static thresholds to trigger alarms, or applying time series analysis and regression models to predict trends for specific indicators.

[0003] These existing technical solutions have shortcomings. Static thresholding methods struggle to adapt to dynamically changing server workloads, leading to frequent false positives and false negatives. Meanwhile, pure machine learning models heavily rely on the quality and comprehensiveness of training data, and the models themselves lack interpretability. More importantly, existing methods typically perform isolated and superficial processing of monitoring data, failing to delve into the complex contextual relationships between different metrics. This makes root cause analysis of potential failures difficult, and predictions are often delayed or inaccurate.

[0004] Traditional predictive models, once deployed, have relatively fixed inference logic, making it difficult to incorporate the domain knowledge accumulated by operations and maintenance personnel, and unable to adaptively learn new failure modes. When server hardware configurations are updated or business scenarios change, the model needs to be retrained, resulting in high maintenance costs. The deep knowledge contained in the deviation between real-time monitoring data and baseline status has not been effectively structured, represented, and utilized, making it difficult for predictive systems to achieve forward-looking and accurate maintenance decisions. Summary of the Invention

[0005] The purpose of this invention is to provide a server fault prediction system and method to solve the problems mentioned in the background art.

[0006] To achieve the above objectives, the present invention provides a server fault prediction method, the method comprising:

[0007] By continuously collecting operational metric data streams of server components through monitoring agents deployed on the server cluster, an initial operational data pool is formed.

[0008] Multi-level data cleaning and contextual correlation analysis are performed on the initial running data pool to construct a server running data set;

[0009] A server health status profile is generated based on the server operation data set, and a health status baseline model is established.

[0010] By analyzing the deviation patterns between the health status baseline model and real-time operating indicators, a fault prediction knowledge graph is constructed.

[0011] The fault prediction knowledge graph is used to drive a dynamic risk calculation engine, which outputs the failure probability of server components and maintenance decision schemes.

[0012] Preferably, the multi-level data cleaning and contextual correlation analysis of the initial running data pool includes:

[0013] The original indicator data in the initial running data pool is subjected to noise filtering to remove abnormal data points caused by transient interference.

[0014] The filtered metric data is sliced ​​according to time windows, and server load type, environment configuration parameters and business process status are associated within each time slice;

[0015] By analyzing the correlation across time slices, sequences of index changes with causal relationships are labeled, forming a set of server runtime data with context labels.

[0016] Preferably, generating a server health status profile based on the server operation data set includes:

[0017] Extract key feature dimensions that characterize the server's health status from the server operation data set;

[0018] For each key feature dimension, calculate its dynamic fluctuation range and behavior pattern under normal operating conditions;

[0019] By integrating the dynamic fluctuation range and behavior patterns of each key feature dimension, a multi-dimensional profile of server health status is generated.

[0020] The calculation of the dynamic fluctuation range and behavior pattern of each key feature dimension under normal operating conditions includes:

[0021] Select historical data segments under normal operating conditions from the server's operational data set, and extract time series data for each key feature dimension;

[0022] Statistical analysis was performed on the historical time series data for each key feature dimension to calculate its mean, standard deviation, and percentiles in order to determine the dynamic fluctuation range.

[0023] By applying time series pattern recognition algorithms, we can identify the periodic changes, trend changes, and distribution of outliers of each key feature dimension under normal operating conditions, thereby characterizing the behavior pattern.

[0024] The dynamic fluctuation range and behavioral patterns are integrated into a health status descriptor for each key feature dimension.

[0025] Preferably, the establishment of the health status baseline model includes:

[0026] Based on the server health status profile, a pattern learning method is used to characterize the baseline behavior profile of the server in a fault-free operating state.

[0027] The baseline behavior profile is parametrically modeled, and the health state threshold boundary is defined;

[0028] The health status threshold boundary is calibrated with historical normal data in the server's operating data set to form a health status baseline model.

[0029] Preferably, the deviation patterns for analyzing the real-time operating indicators include:

[0030] Real-time acquisition of server component operating metrics and mapping of them to the health status baseline model;

[0031] Calculate the deviation and deviation trend between real-time operating indicators and the baseline behavioral profile in the health status baseline model;

[0032] Identify abnormal patterns whose deviation exceeds a preset threshold, and trace the frequency of occurrence and evolution path of the abnormal patterns in historical data;

[0033] The deviation and deviation trend between the calculated real-time operating indicators and the baseline behavioral profile in the health status baseline model include:

[0034] Real-time operating metrics are sliced ​​by time window and compared with reference values ​​of the corresponding time window in the baseline behavior profile. The Euclidean distance or cosine similarity between the real-time operating metrics and the reference values ​​within each time window is calculated as the deviation. The deviation changes in continuous time windows are analyzed, and the direction and magnitude of the deviation trend are calculated using linear regression or moving average methods. When the deviation exceeds a preset threshold or the deviation trend indicates continuous deterioration, abnormal pattern recognition is triggered.

[0035] Preferably, the construction of the fault prediction knowledge graph includes:

[0036] The identified anomaly patterns are mapped to historical server failure events;

[0037] Establish a network of relationships between abnormal modes, fault types, component types, and fault severity;

[0038] The network of relationships is stored using a graph structure to form a fault prediction knowledge graph that includes the association between fault precursor patterns and fault consequences.

[0039] Preferably, storing the relationship network through a graph structure includes:

[0040] The abnormal mode, fault type, component type, and fault severity are used as nodes in the graph structure, and the edges between the nodes are defined to represent the relationships.

[0041] Set a weight attribute for each edge, with the weight based on the frequency and strength of the association in historical data;

[0042] Use a graph database or adjacency matrix to store node and edge information, and support real-time query and update operations;

[0043] Graph traversal algorithms are used to mine potential connections between nodes to enhance the completeness of the fault prediction knowledge graph.

[0044] Preferably, the working process of the dynamic risk calculation engine includes:

[0045] Receive real-time server performance metrics and extract current anomaly pattern characteristics;

[0046] The current abnormal pattern features are matched with nodes in the fault prediction knowledge graph to calculate the matching degree. Based on the matching degree and the associated historical fault data in the graph, the probability value of the current server component failing is calculated.

[0047] Preferably, the failure probability and maintenance decision-making scheme of the output server component includes:

[0048] Based on the calculated failure probability value, combined with the criticality level and availability requirements of the server components;

[0049] Develop response strategies for different failure probability levels, including early warning levels, inspection cycles, and intervention measures;

[0050] Generate a maintenance decision plan that includes specific execution time and operation details.

[0051] Preferably, the present invention also includes a server failure prediction system, the system including a memory, a processor, and a computer program stored in the memory and running on the processor, wherein the processor, when executing the computer program, implements the steps of the server failure prediction method described above.

[0052] Compared with the prior art, the beneficial effects of the present invention are:

[0053] By performing multi-level data cleaning and contextual correlation analysis on the initial operational data pool, a high-quality server operational data set was constructed. Multi-level cleaning addressed fundamental quality issues such as data format errors and logical inconsistencies. Contextual correlation analysis placed previously isolated indicators within the specific operational environment of the server to mine their correlations, identifying implicit dependencies and collaborative change patterns among the indicators. This process eliminated data noise at its source and endowed the data with rich semantic information, ensuring that the data used for subsequent modeling is no longer a discrete numerical sequence but an information entity reflecting the overall operational status of the server. The health baseline model generated based on this high-quality data set exhibits improved accuracy and robustness, more realistically representing the server's behavior under normal operating conditions.

[0054] By analyzing the deviation patterns between the baseline health status model and real-time operational metrics, a structured fault prediction knowledge graph is constructed. This knowledge graph stores and manages various deviation patterns, server components, historical fault events, and operational rules as entities and relationships. It allows implicit fault precursor knowledge to be expressed explicitly and structurally. When real-time data anomalies occur, the dynamic risk calculation engine can perform graph traversal and reasoning on the knowledge graph to identify complex fault propagation paths and associated risks, rather than simply making numerical comparisons. This knowledge-based reasoning approach enhances the predictive ability for complex fault scenarios and cascading faults, while providing interpretable predictive evidence. The scalability of the knowledge graph also facilitates the integration of new fault cases and expert experience, enabling the system to continuously evolve. Attached Figure Description

[0055] Figure 1 This is a schematic diagram illustrating the working principle of the server fault prediction method described in this invention.

[0056] Figure 2 A flowchart for multi-level data cleaning and contextual correlation analysis;

[0057] Figure 3 A flowchart for establishing a baseline model of health status;

[0058] Figure 4 A graph showing the deviation analysis between the baseline model of health status and real-time operating indicators;

[0059] Figure 5 This is a network diagram relating to the knowledge graph for fault prediction. Detailed Implementation

[0060] The technical solutions of the embodiments of the present invention will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present invention, and not all embodiments. Based on the embodiments of the present invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of the present invention.

[0061] Please see Figure 1 This invention provides a server fault prediction method. The method includes: a monitoring agent deployed in a server cluster continuously collecting operational indicator data streams of server components, including but not limited to the central processing unit, memory, hard disk, network interface card, and power supply unit. The monitoring agent collects operational indicators such as CPU utilization, memory utilization, hard disk I / O throughput, network latency, and temperature readings at a preset frequency to form an initial operational data pool. Subsequently, multi-level data cleaning and contextual correlation analysis are performed on the initial operational data pool to remove invalid data and establish intrinsic relationships between data, thereby constructing a high-quality server operational data set. Based on this data set, the system generates a health status profile that comprehensively reflects the server's operational status and establishes a baseline model characterizing the server's behavior under normal conditions. By continuously analyzing the deviation patterns between the real-time collected operational indicators and the health status baseline model, the system can identify potential abnormal behavior sequences and construct a fault prediction knowledge graph containing complex correlations between fault precursor patterns and fault consequences. This knowledge graph drives a dynamic risk calculation engine that can quantify the real-time failure risk probability of each component of the server and output corresponding, actionable maintenance decision-making schemes, thereby achieving early warning and precise intervention for server failures.

[0062] Example 1: See Figure 2In practical implementation, multi-level data cleaning and contextual correlation analysis of the initial running data pool are key steps in constructing a high-quality server running data set. The initial running data pool gathers raw indicator data streams continuously reported by various monitoring agents in the server cluster. Noise is inevitably introduced into these raw indicator data during collection and transmission. Noise filtering, as the first level of data cleaning, aims to identify and remove abnormal data points caused by transient interference. Transient interference may originate from brief network congestion, transient resource contention in the collection agent process, or occasional errors in the underlying hardware reads. In practice, the Z-score method based on statistical distribution can be used for noise filtering. This calculates the standard deviation multiple of each data point from the mean of the data within its short-term time window, and data points with an absolute Z-score exceeding a preset threshold (e.g., 3 or 4) are identified as outliers and removed. Alternatively, a local outlier factor algorithm can be used, which identifies outliers by calculating the local density deviation of data points. This method is more adaptable to datasets with uneven density. The filtered indicator data forms the basis for subsequent analysis.

[0063] In practice, the second-level processing involves slicing the filtered metric data into fixed or adaptive time windows. The length of the time window can be configured according to the characteristics of the metric and the required granularity of analysis. For example, a 5-minute window can be used for rapidly changing metrics such as CPU utilization, while a 1-hour window can be used for metrics that change slowly, such as disk capacity. Within each time slice, the system needs to perform contextual correlation analysis, which correlates the metric data within that time slice with the server's load type, environment configuration parameters, and business process status during the same period. Load type can be extracted from system logs or resource manager, such as marking the server as compute-intensive, I / O-intensive, or idle; environment configuration parameters include static or semi-static information such as the operating system version number, kernel parameter settings, and virtual memory configuration; business process status focuses on dynamic information such as the survival status of critical application processes, thread count, and changes in memory usage. The purpose of the correlation operation is to inject runtime context into the cold metric data, so that an isolated high CPU utilization value can be correctly interpreted as being caused by normal batch processing tasks or by a process entering an infinite loop.

[0064] In practical implementation, cross-time-slice correlation analysis constitutes the third level of processing. This analysis aims to transcend the limitations of a single time slice and uncover causal or temporal relationships between indicator changes over a longer time scale. The analysis process examines the sequence patterns of different indicators across different time slices. For example, it analyzes whether an increase in memory usage consistently leads to an increase in swap partition usage after several time windows, or whether abnormal peaks in network packet reception are always accompanied by an increase in CPU interrupt processing time in a subsequent time window. By calculating the lag cross-correlation between time series or applying Granger causality tests, the relationship between statistically significant preceding indicators and subsequent indicators can be identified. Once causally related indicator change sequences are identified, the system assigns context labels to these sequences; for example, a sequence of "continuously increasing memory usage accompanied by swap partition growth" is labeled as a "memory pressure accumulation" pattern. It can be understood that this cross-time-slice correlation analysis can reveal deep dependencies between indicators, providing important evidence for accurately assessing server status. Ultimately, all the cleaned, sliced, context-linked, and cross-slice-analyzed data is integrated to form a server operation data set with context labels. This set not only contains clean numerical metrics, but more importantly, it embeds rich operational semantic information.

[0065] In some embodiments, the time window slicing strategy can employ a dynamic adjustment mechanism. The window length is not fixed but adaptively adjusted based on the fluctuations in server load. During periods of relatively stable load, a longer time window can be used to reduce data granularity and computational overhead; during periods of drastic load fluctuations, a shorter time window is automatically switched to capture more granular patterns of change. The dynamic adjustment can be based on the rate of change of data variance within the window or a complexity measure based on information entropy. It can be understood that this adaptive windowing mechanism can optimize system resource consumption while ensuring analytical accuracy.

[0066] In some embodiments, the scope of contextual correlation analysis can be further expanded to include micro-environmental information of the server rack, in addition to load type, environment configuration, and business process status. For example, information such as temperature indicators of adjacent servers within the same rack, load status of shared power supplies, and air supply temperature of the data center air conditioning can be correlated with the operating indicators of the target server. This broader contextual correlation helps identify common problems caused by external environmental factors, such as an abnormal pattern of temperature increases across all servers in the rack.

[0067] Example 2: See Figure 3In practice, generating a server health profile and establishing a baseline model based on server runtime datasets is a systematic process. The server runtime dataset is a semantically rich collection of data obtained after multi-level data cleaning and contextual analysis. The first step in generating a server health profile is to extract key feature dimensions representing the server's health status from this dataset. The selection of key feature dimensions is based on their importance in reflecting the health of server components. For example, CPU user-mode utilization, system-mode utilization, interrupt rate, and run queue length; memory available bytes, page swapping rate, and page fault rate; hard disk read / write operations per second, average input / output latency, and read / write error rate; and network interface bandwidth utilization, packet loss rate, and error packet rate can all be considered as candidate key feature dimensions. In practice, feature selection algorithms, such as mutual information-based methods or recursive feature elimination methods, can be used to automatically filter out the subset of feature dimensions most relevant to the server's health status, reducing redundancy and improving the efficiency of subsequent models.

[0068] In practical implementation, for each ultimately selected key feature dimension, it is necessary to calculate its dynamic fluctuation range and behavioral pattern under normal operating conditions. The calculation process requires selecting a historical data segment explicitly marked as operating under normal conditions from the server's operational dataset. This data segment should represent a period of stable server operation without faults or performance bottlenecks. For the key feature dimension "CPU user-mode utilization," its time-series data within the normal historical data segment is extracted. Statistical analysis is performed on this time-series data, calculating its arithmetic mean, standard deviation, 5th percentile, 25th percentile, 50th percentile, 75th percentile, and 95th percentile. The dynamic fluctuation range can be described using percentile intervals [P5, P95] or intervals equal to or less than a certain multiple of the standard deviation from the mean. Characterizing the behavioral pattern requires the application of time-series pattern recognition algorithms, such as using a seasonal autoregressive integral moving average model to identify and decompose the trend component, seasonal component, and residual component in the time series, thereby capturing the daily, weekly, and long-term trend changes of CPU user-mode utilization. Outlier distributions can be identified using the Isolation Forest algorithm or methods based on prediction error to understand acceptable minor anomalies within a normal pattern. Dynamic fluctuation ranges and behavioral patterns are integrated to form a health status descriptor for the key feature dimension of "CPU user-mode utilization." The above process is repeated for all key feature dimensions to generate their respective health status descriptors.

[0069] In practical implementation, the dynamic fluctuation ranges and behavioral patterns of each key feature dimension are fused to generate a multi-dimensional server health profile. Fusion is not a simple juxtaposition but requires consideration of the correlations between different dimensions. One fusion method is to construct a multi-dimensional health status vector, where each component corresponds to the core summary statistics of a key feature dimension's health status descriptor. A more refined fusion method can introduce principal component analysis (PCA) to reduce the dimensionality and decorrelate the original key feature dimensions, generating a set of uncorrelated principal components. Each principal component also has its own dynamic fluctuation range and behavioral pattern; these principal components collectively constitute the server health profile. Essentially, the server health profile is a quantitative summary of the server's multi-dimensional operational characteristics in a healthy state.

[0070] In practical implementation, the establishment of the health status baseline model is based on the server health status profile. Pattern learning methods are used to characterize the baseline behavior profile of the server under fault-free operating conditions. Pattern learning can apply clustering algorithms to cluster normal historical data samples, using the trajectory of the center point of the largest or most central cluster as the baseline behavior profile; or it can apply Gaussian mixture models to model the normal data distribution, using its expected value as the baseline behavior profile. The baseline behavior profile is then parametrically modeled, meaning that a health status threshold boundary is defined for each key feature dimension or principal component. The threshold boundary can be dynamic; for example, for indicators with obvious diurnal periodicity, its threshold boundary should also be a function that changes over time, rather than a fixed value. An exemplary formula for defining the health status threshold boundary can be expressed as:

[0071]

[0072] in: This represents the upper threshold boundary at time t. This represents the baseline behavior profile value at time t. The standard deviation of the historical normal data at time t is represented by k, which is a configurable scaling factor.

[0073] In some embodiments, behavioral pattern identification can employ transform domain-based methods, such as performing wavelet transform on time-series data of key feature dimensions, and extracting fluctuation features at different time scales by analyzing wavelet coefficients. Wavelet transform can simultaneously characterize the local features of signals in both the time and frequency domains, and is particularly effective for capturing non-stationary periodic changes in server metrics. The extracted main wavelet coefficients and their corresponding scales can be incorporated into the health status descriptor as important components of the behavioral pattern. The calibration process of the health status baseline model can employ more complex optimization algorithms, such as using grid search or Bayesian optimization to find the optimal combination of threshold boundary parameters within a preset parameter space. The optimization objective function can be defined as a weighted sum of false positive and false negative rates, with the weights adjusted according to the criticality of the server business. For core business servers, a higher weight can be assigned to the false negative rate to ensure higher sensitivity to potential faults.

[0074] Optionally, a time decay factor can be introduced into the server health profile, giving higher weight to recent normal operation data when calculating dynamic fluctuation ranges and behavioral patterns. This helps the health profile adapt slowly to the normal evolution of the server's hardware and software environment. For example, as business volume naturally increases, the normal baseline of CPU utilization will gradually shift upwards, and the time decay factor allows the health profile to track this gradual change.

[0075] Optionally, for multiple servers with similar configurations and workloads, a group health baseline model can be built. This group model is constructed by aggregating normal historical data from multiple servers. This model provides a preliminary baseline reference for newly deployed servers or servers lacking sufficiently long historical data, and helps identify individual anomalies that deviate from the overall group's normal pattern. This is particularly useful for discovering common-cause failures or configuration discrepancies. The process of building the group model is similar to that of the single-machine model, but the data source is a selected set of homogeneous server instances.

[0076] Example 3: In practical implementation, analyzing the deviation patterns between the health status baseline model and real-time operating indicators is a key step in triggering fault prediction. The system continuously acquires real-time operating indicators of server components through monitoring agents deployed on the server cluster. These real-time operating indicators are transmitted to the analysis module in the form of data streams. The analysis module first performs necessary preprocessing on the real-time operating indicators, consistent with the preprocessing of the server operating data set, such as data format standardization and unit unification. The preprocessed real-time operating indicators are then mapped onto the pre-established and stored health status baseline model. The mapping operation aligns and compares the time point or time period of the real-time operating indicator with the reference baseline behavioral profile of the corresponding time point or time period defined in the health status baseline model. For example, for indicators with a significant diurnal cycle, the real-time value at 3 PM should be compared with the reference value in the health status baseline model that characterizes normal behavior at 3 PM.

[0077] In practical implementation, calculating the deviation and trend between real-time operational indicators and the baseline behavioral profile in the health status baseline model is the core step in quantifying the deviation. The calculation process slices the continuously input real-time operational indicators according to the same time window length used when constructing the health status baseline model. For example, if the health status baseline model is constructed based on a one-hour time window, the real-time data stream is also divided into continuous one-hour time window slices. For each time window slice, the real-time operational indicator sequence of all sampling points within the window is compared with the reference baseline behavioral profile sequence in the same time period in the health status baseline model. One method for calculating the deviation is Euclidean distance, which calculates the square root of the sum of the squares of the differences between corresponding points in the two sequences. The formula is expressed as:

[0078]

[0079] in: This indicates the Euclidean distance deviation within the current time window. This indicates the number of sampling points within the time window. Indicates the first Real-time operational index values ​​for each sampling point The first in the baseline model of health status The reference value of the baseline behavior profile for each sampling point. The larger the Euclidean distance deviation value, the greater the difference in overall shape and value between the real-time operating index sequence and the baseline behavior profile sequence.

[0080] In practical implementation, identifying abnormal patterns where deviation exceeds a preset threshold and tracing their historical frequency and evolution path represents a deeper level of deviation pattern analysis. The health status baseline model typically defines dynamic threshold boundaries for different key feature dimensions or overall deviation. When the calculated real-time deviation exceeds the preset threshold boundary for the corresponding dimension, the system triggers the abnormal pattern identification mechanism. Abnormal patterns not only include threshold exceedances at single points but also focus on continuous, evolving patterns. For example, even if the deviation in a single time window does not exceed the threshold, a stable linear growth trend in deviation over three consecutive time windows with a slope exceeding a certain critical value may be identified as an abnormal pattern requiring attention. Once an abnormal pattern is identified, the system immediately traces the frequency of occurrence of that abnormal pattern or similar patterns in the historical data stored in the server's runtime dataset. For example, it queries how many times similar abnormal deviations occurred in the past thirty days and what percentage of these historical abnormal events ultimately led to actual failures. At the same time, the system will analyze the typical evolution path of the abnormal pattern in historical data, that is, how the relevant indicators change from the first appearance of the pattern to its eventual disappearance or failure. For example, does it rapidly escalate and trigger an alarm and recover, or does it slowly accumulate and eventually lead to service interruption? This historical tracing provides crucial contextual information for assessing the potential risks and urgency of the current abnormal pattern.

[0081] In some embodiments, the deviation calculation can consider the differences in importance of different indicator dimensions, assigning different weights to the deviation components of each key feature dimension, and then calculating a weighted Euclidean distance or using Mahalanobis distance. Mahalanobis distance considers the correlation between data dimensions and can more accurately measure the degree of deviation of real-time data points from the baseline in multi-dimensional space. The weights can be determined based on the degree of influence of the indicator on the overall health of the server or based on correlation analysis of historical failure data. For indicators with no obvious periodicity, the baseline behavior profile in the health baseline model may not be a function that changes over time, but rather a relatively stable range of values. In this case, the deviation calculation of real-time operating indicators can be simplified to calculating the percentage deviation of the real-time value from the stable reference value or the Z-score value, and the deviation trend is assessed by observing the changes in these relative deviation values ​​within a continuous time window.

[0082] Optionally, anomaly pattern recognition can incorporate machine learning classifiers. The difference features between the real-time running indicator sequence and the baseline health status model are input into a pre-trained classification model. The model then determines whether the current pattern is abnormal and requires alerting, rather than relying solely on simple threshold comparisons. The classification model can use algorithms such as support vector machines, random forests, or neural networks, and is trained on historical labeled data. When tracing the historical frequency and evolution of anomaly patterns, a pattern library can be constructed. This library extracts features from and indexes various historical anomaly patterns. When a new anomaly pattern appears, the system performs a similarity search in the library to quickly find the most similar historical pattern instances and summarizes their subsequent development. This provides richer reference data for predicting the current pattern. The similarity search in the pattern library can employ shape-based distance metrics or embedding vector similarity calculations from deep learning.

[0083] See Figure 4 This chart presents a comparative analysis of the server health baseline model and real-time operational metrics. The charts, presented in time-series format, show the health baseline data and actual operational data for CPU utilization, clearly illustrating the differences between the system's normal operating mode and real-time monitoring data. The blue curve represents the health baseline model built upon historical normal data, reflecting the expected behavior of the server under fault-free operation; the red curve shows the real-time operational metrics data continuously collected by the monitoring agent, reflecting the system's current actual operating status. Anomalies marked in the charts represent detected deviations exceeding preset thresholds; these anomalies are key signals triggering fault prediction. By observing the degree of agreement between the two curves and the distribution of anomalies, the stability of the server's health status can be intuitively understood, providing important basis for subsequent fault prediction. This visualization analysis helps operations and maintenance personnel quickly identify abnormal system behavior, take timely preventative measures, and avoid potential service interruption risks.

[0084] Example 4: In specific implementation, constructing a fault prediction knowledge graph involves systematically associating analyzed anomaly patterns with historical fault events to form a structured relationship network. The construction process begins with mapping the identified anomaly patterns with historical server fault event records. Historical fault event records originate from maintenance work order systems, monitoring system alarm logs, or manual annotations. Each record contains information such as the time of the fault occurrence, affected server components, fault type description, fault severity, and fault repair measures. The association mapping is achieved by analyzing the temporal relationship between anomaly patterns and fault events in historical data. For example, it retrieves whether a certain anomaly pattern has appeared continuously or intermittently within a time window before a specific fault occurred. If this co-occurrence relationship is statistically significant in historical data, a directed edge is established between the anomaly pattern node and the fault type node, with the edge pointing from the anomaly pattern to the fault type, indicating that the former is a potential precursor to the latter.

[0085] In practical implementation, establishing a network of relationships between anomaly patterns, fault types, component types, and fault severity is the core content of a knowledge graph. This network is a multi-dimensional graph structure where nodes represent different entity types. Anomaly pattern nodes describe a sequence of metric deviations, such as "CPU user-mode utilization consistently exceeds 90% accompanied by a temperature spike"; fault type nodes describe specific fault categories, such as "CPU overheating and frequency throttling" or "Memory controller error correction rate exceeding limits"; component type nodes identify the server's hardware or logical components, such as "CPU," "memory modules," or "hard drive backplane"; and fault severity nodes classify the impact of faults, such as "Minor: Performance degradation" or "Severe: Service unavailable." Edges between nodes represent relationships between entities, and edge types can include "manifests as" (connecting anomaly patterns and fault types), "impacts" (connecting fault types and component types), and "has severity" (connecting fault types and fault severity). The construction of this network relies on in-depth mining of historical operational data, establishing stable and repeatable relationships between these entities through the analysis of numerous historical cases.

[0086] In practical implementation, storing the relationship network through a graph structure is the foundation for efficient querying and reasoning. The graph structure formally represents the relationship network using nodes and edges. Each node has a unique identifier and a set of attributes. For example, an anomaly pattern node might contain attributes such as the pattern's feature vector description and first occurrence time; a fault type node might contain attributes such as the standard fault code and fault description. Edges, besides connecting two nodes, can also carry attributes themselves. The weight attribute is a crucial one, calculated based on the frequency and strength of the relationship in historical data. For instance, the weight of the edge connecting anomaly pattern A and fault type B can be set based on the conditional probability of fault B occurring after pattern A appears in history, or the number of times they co-occur within a time window. Graph databases are ideal for storing this type of graph structure because they are optimized for node and edge traversal and relationship queries. The Cypher query language can be used to easily find all potential fault type nodes reachable from an anomaly pattern node via several hop edges. Adjacency matrices are another storage method, particularly suitable for situations where the number of nodes is not extremely large. They represent the connections between nodes using a matrix, where the matrix elements can represent edge weights or the existence of edges. Graph-structured storage supports real-time query and update operations. When a new fault event occurs or a new anomaly pattern is identified, new nodes and edges can be dynamically added to the graph, or the weight attributes of existing edges can be updated. By executing graph traversal algorithms, such as breadth-first search or depth-first search, we can explore the associated nodes and paths starting from a certain node, thereby discovering potential, indirect relationships. For example, traversal may reveal that anomaly pattern A usually triggers fault B first, and fault B often leads to fault C. This uncovers a potential path from A to C, enhancing the predictive ability for complex fault chains (see Table 1).

[0087] Table 1: Calculation Table of Correlation Weights between Abnormal Modes and Fault Types

[0088]

[0089] In some embodiments, edge weight calculation can employ more complex formulas, considering not only the conditional probability of co-occurrence but also confidence factors and lift metrics. The confidence factor can be based on the absolute number of co-occurrences; for example, if the number of co-occurrences is too low, even with a high conditional probability, the confidence level will be low. The final weight can be the product of the conditional probability and the confidence factor. The lift metric measures the strength of the association rule relative to random co-occurrence, helping to filter out truly meaningful strong associations and avoid associating common faults with occasional abnormal patterns. It can be understood that the construction of a fault prediction knowledge graph is a continuous learning and evolutionary process. As the system continues to run and accumulate new data, the nodes, edges, and edge weights in the graph are constantly updated and optimized, enabling the fault prediction capability to gradually improve over time. The discovery of new abnormal patterns and the recording of new fault types enrich the content of the knowledge graph in real time.

[0090] Optionally, in addition to storing known, explicitly defined relationships, graph structures can also utilize graph embedding techniques to map nodes to a low-dimensional vector space. In this vector space, nodes with similar semantics or close relationships will have closer vector distances. By calculating the similarity of node vectors, relationships can be discovered between nodes that are not directly connected in the original graph structure but have potentially similar semantics. For example, discovering a new anomaly pattern whose vector is very close to the vector of a known fault type can lead to the inference that there may be unrecorded associations between them. This capability greatly expands the coverage and reasoning ability of knowledge graphs.

[0091] Optionally, to manage the complexity of the knowledge graph and improve query efficiency, the graph structure can be stored in layers or blocks. For example, the graph can be divided into different subgraphs according to the server component type, with CPU-related entities and their relationships stored in one subgraph and memory-related entities stored in another. During fault prediction, the relevant component subgraph can be located first for local querying and reasoning, thereby reducing the number of nodes and edges that need to be traversed and improving system response speed. Subgraphs are connected through key shared nodes to ensure the traceability of global associations.

[0092] See Figure 5This paper showcases the network structure of the constructed fault prediction knowledge graph, presenting the complex relationships between anomaly patterns, fault types, component types, and fault severity through graph theory visualization. Nodes in the knowledge graph are categorized by different colors, representing entity types such as anomaly patterns, fault types, server components, and fault severity. Directed edges between nodes represent the relationships between entities, and edge labels indicate the specific relationship type. This structured representation method systematically organizes historical fault data and anomaly pattern information, forming a queryable and reasonable relational network. The diagram clearly illustrates the potential causal path from anomaly patterns to fault types, as well as the impact of fault types on specific server components, and also displays the severity levels corresponding to different fault types. This visualization allows for an intuitive understanding of the strength of the association between various anomaly patterns and the final fault, providing rich contextual information for fault prediction. The construction of the knowledge graph enables the system to perform intelligent reasoning based on historical experience. When a new anomaly pattern emerges, it can quickly match similar historical patterns and predict possible fault consequences.

[0093] Example 5: In specific implementation, the dynamic risk calculation engine is the core execution component of the fault prediction method. It is responsible for combining real-time data with the fault prediction knowledge graph to quantify risks and generate decisions. The dynamic risk calculation engine continuously receives real-time server operation indicators from the monitoring data stream. The engine first extracts features from the real-time server operation indicators to identify the current abnormal pattern features. The extraction process involves comparing the real-time indicator sequence with the health status baseline model to calculate feature values ​​such as deviation degree, deviation trend, abnormal pattern duration, and pattern intensity. These feature values ​​together constitute a feature vector describing the current server state. For example, for the central processing unit component, the extracted abnormal pattern features may include Boolean features such as "the proportion of time in the past hour when user state utilization exceeded 95%", "average deviation degree value", "deviation trend slope", and "whether a temperature alarm was detected". These features are organized into a structured current abnormal pattern feature descriptor.

[0094] In practical implementation, matching the current anomaly pattern features with nodes in the fault prediction knowledge graph is a crucial step in calculating the fault probability. The matching operation primarily targets anomaly pattern nodes in the fault prediction knowledge graph. The matching process calculates the similarity or matching degree between the current anomaly pattern feature descriptor and the feature vectors of each anomaly pattern node stored in the fault prediction knowledge graph. Similarity calculation can employ cosine similarity, the reciprocal of Euclidean distance, or more complex domain-knowledge-based matching algorithms. The matching degree quantifies the degree of agreement between the currently observed anomaly and known fault precursor patterns in the knowledge graph. For example, if the current feature has a high matching degree with an anomaly pattern node identified as a "memory leak precursor," it indicates that the current server may be experiencing a similar memory pressure accumulation process. Based on the matching degree and associated historical fault data in the fault prediction knowledge graph, the system calculates the probability value of the current server component failing. Historical fault data is stored in the edge attributes of the fault prediction knowledge graph; for example, the edges connecting anomaly pattern nodes and fault type nodes typically contain a weight attribute, which may represent conditional probability. A basic probability calculation method involves identifying the top K anomalous pattern nodes with the highest feature matching degree to the current anomalous pattern. Then, the fault type nodes connected to these nodes via edges are read, and the weighted average or product of the edge weights and matching degrees is used as the initial probability estimate for the occurrence of that fault type. The calculation process also needs to consider the synergistic effect of multiple anomalous patterns potentially pointing to the same fault type simultaneously, or the mutual inhibition relationship between different anomalous patterns.

[0095] In practical implementation, the failure probability and maintenance decision plan for the output server components are the final outputs of the dynamic risk calculation engine. The failure probability value is a numerical value between 0 and 1, representing the likelihood of a specific component failing in the foreseeable future. Based on the calculated failure probability value, the system makes a comprehensive decision considering the criticality level of the server component in the overall business system and system availability requirements. Components with high criticality levels may require more proactive countermeasures even if the failure probability is relatively low, while alarm thresholds for backup or non-critical components can be set higher. The system has a pre-built strategy library that defines differentiated response strategies for different failure probability levels. The response strategies specify the warning level, recommended inspection cycle, and specific intervention measures. The system generates a structured, executable maintenance decision plan, which includes specific execution time points, detailed descriptions of operation content, recommended responsible personnel or automated execution modules, etc. The goal of the maintenance decision plan is to take the most cost-effective intervention action before a failure occurs, balancing operational costs and business continuity risks.

[0096] In some embodiments, the calculation of failure probability can incorporate a Bayesian inference framework, combining the prior probabilities of edges in the failure prediction knowledge graph with currently observed anomalous pattern features as evidence to calculate the posterior probability of failure. Bayesian methods naturally handle uncertainty and dynamically update probability estimates as new evidence emerges. For example, when only a weak anomalous signal is initially observed, the failure probability may be low, but as time progresses, if other anomalous signals related to the failure appear, the failure probability will gradually increase through Bayesian updates. The generation of maintenance decision options can incorporate a cost-benefit analysis model, which estimates the manpower, resource, and business interruption costs required to perform each recommended maintenance operation and compares this with the potential business losses caused by inaction. The dynamic risk calculation engine selects the maintenance decision option with the lowest expected overall cost as output. For example, for a medium-probability failure risk, if the business interruption cost of immediate maintenance is high, while the loss caused by the failure itself is relatively controllable, the solution might suggest handling it in the next planned maintenance window rather than immediately.

[0097] Optionally, the dynamic risk calculation engine can support "what-if analysis" scenarios, allowing operations personnel to manually adjust input parameters such as failure probability values ​​or component criticality levels, and then observe the corresponding changes in maintenance decision-making schemes. This functionality helps operations teams assess the consequences of different decision paths in complex situations, such as evaluating how maintenance strategies will be upgraded after temporarily increasing the criticality level of a component, thus providing a more comprehensive reference for the final decision. Maintenance decision-making schemes can include rollback plans or contingency measures; that is, if recommended maintenance operations fail to resolve the problem or cause new problems, what steps should be taken immediately to restore service or mitigate the impact. For recurring failure modes with fixed processing procedures, maintenance decision-making schemes can directly trigger the execution of automated operations scripts, rather than simply providing suggestions. The engine can transmit information such as failure type and target component identifier to the automated operations platform, which automatically calls preset scripts to complete operations such as service restarts and load switching, thereby achieving closed-loop automation from prediction to repair and significantly shortening failure mitigation time.

[0098] It should be noted that, in this document, relational terms such as "first" and "second" are used only to distinguish one entity or operation from another, and do not necessarily require or imply any such actual relationship or order between these entities or operations. Furthermore, the terms "comprising," "including," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or apparatus that comprises a list of elements includes not only those elements but also other elements not expressly listed, or elements inherent to such process, method, article, or apparatus.

[0099] Although embodiments of the invention have been shown and described, it will be understood by those skilled in the art that various changes, modifications, substitutions and alterations can be made to these embodiments without departing from the principles and spirit of the invention, the scope of which is defined by the appended claims and their equivalents.

Claims

1. A server fault prediction method, characterized in that, The method is implemented through the following process: The monitoring agent deployed on the server cluster continuously collects the operational metrics data stream of the server components to form an initial operational data pool; The initial running data pool is subjected to multi-level data cleaning and contextual correlation analysis to construct a server running data set, including: The raw indicator data in the initial running data pool is subjected to noise filtering to remove abnormal data points caused by instantaneous interference; the filtered indicator data is sliced ​​according to time windows, and server load type, environment configuration parameters and business process status are associated in each time slice; through cross-time slice correlation analysis, the indicator change sequence with causal relationship is marked to form a server running data set with context labels. Based on the server operation data set, a server health status profile is generated, and a health status baseline model is established. By analyzing the deviation patterns between the health status baseline model and real-time operational indicators, a fault prediction knowledge graph is constructed, including: The identified abnormal patterns are mapped to historical server failure events; a network of relationships between abnormal patterns, failure types, component types, and failure severity is established; the network of relationships is stored in a graph structure to form a fault prediction knowledge graph that includes the association between fault precursor patterns and fault consequences. The fault prediction knowledge graph is used to drive a dynamic risk calculation engine, which outputs the failure probability of server components and maintenance decision schemes.

2. The server fault prediction method according to claim 1, characterized in that, The process of generating a server health status profile based on the server operation data set includes: Extract key feature dimensions that characterize the server's health status from the server operation data set; For each key feature dimension, calculate its dynamic fluctuation range and behavior pattern under normal operating conditions; By integrating the dynamic fluctuation range and behavior patterns of each key feature dimension, a multi-dimensional profile of server health status is generated. The calculation of the dynamic fluctuation range and behavior pattern of each key feature dimension under normal operating conditions includes: Select historical data segments under normal operating conditions from the server's operational data set, and extract time series data for each key feature dimension; Statistical analysis was performed on the historical time series data for each key feature dimension to calculate its mean, standard deviation, and percentiles in order to determine the dynamic fluctuation range. By applying time series pattern recognition algorithms, we can identify the periodic changes, trend changes, and distribution of outliers of each key feature dimension under normal operating conditions, thereby characterizing the behavior pattern. The dynamic fluctuation range and behavioral patterns are integrated into a health status descriptor for each key feature dimension.

3. The server fault prediction method according to claim 2, characterized in that, The establishment of the health status baseline model includes: Based on the server health status profile, a pattern learning method is used to characterize the baseline behavior profile of the server in a fault-free operating state. The baseline behavior profile is parametrically modeled, and the health state threshold boundary is defined; The health status threshold boundary is calibrated with historical normal data in the server's operating data set to form a health status baseline model.

4. The server fault prediction method according to claim 3, characterized in that, The analysis of deviation patterns of the real-time operating indicators includes: Real-time acquisition of server component operating metrics and mapping of them to the health status baseline model; Calculate the deviation and deviation trend between real-time operating indicators and the baseline behavioral profile in the health status baseline model; Identify abnormal patterns whose deviation exceeds a preset threshold, and trace the frequency of occurrence and evolution path of the abnormal patterns in historical data; The deviation and deviation trend between the calculated real-time operating indicators and the baseline behavioral profile in the health status baseline model include: Real-time operating metrics are sliced ​​by time window and compared with reference values ​​of the corresponding time window in the baseline behavior profile. The Euclidean distance or cosine similarity between the real-time operating metrics and the reference values ​​within each time window is calculated as the deviation. The deviation changes in continuous time windows are analyzed, and the direction and magnitude of the deviation trend are calculated using linear regression or moving average methods. When the deviation exceeds a preset threshold or the deviation trend indicates continuous deterioration, abnormal pattern recognition is triggered.

5. The server fault prediction method according to claim 4, characterized in that, The method of storing the relationship network through a graph structure includes: The abnormal mode, fault type, component type, and fault severity are used as nodes in the graph structure, and the edges between the nodes are defined to represent the relationships. Set a weight attribute for each edge, with the weight based on the frequency and strength of the association in historical data; Use a graph database or adjacency matrix to store node and edge information, and support real-time query and update operations; By using graph traversal algorithms to uncover potential connections between nodes, the completeness of the fault prediction knowledge graph can be enhanced.

6. The server fault prediction method according to claim 5, characterized in that, The working process of the dynamic risk calculation engine includes: Receive real-time server performance metrics and extract current anomaly pattern characteristics; The current abnormal pattern features are matched with nodes in the fault prediction knowledge graph to calculate the matching degree. Based on the matching degree and the associated historical fault data in the graph, the probability value of the current server component failing is calculated.

7. The server fault prediction method according to claim 6, characterized in that, The failure probability and maintenance decision-making scheme of the output server component includes: Based on the calculated failure probability value, combined with the criticality level and availability requirements of the server components; Develop response strategies for different failure probability levels, including early warning levels, inspection cycles, and intervention measures; Generate a maintenance decision plan that includes specific execution time and operation details.

8. A server fault prediction system, 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 steps of the server fault prediction method according to any one of claims 1 to 7.

Images