Intelligent server fault detection method based on BMC (Baseboard Management Controller)

Abstract

The invention relates to an intelligent server fault detection method based on a BMC, and the method comprises the steps: adjusting a to-be-detected server to a debug mode of the BMC to obtain original data, judging whether the data received by the BMC is sensor fault data or not, and when the BMC receives an alarm that a sensor is abnormal; constructing a fault model and carrying out training and optimization; acquiring specified data of a to-be-detected server in real time, preprocessing the specified data, inputting the preprocessed specified data into the optimized fault model, automatically classifying the preprocessed specified data by the fault model, judging whether the to-be-detected server has a fault or a fault tendency, if so, starting an automatic repair strategy, and if not, starting an automatic repair strategy. According to the automatic decision, which repair measure is taken is determined according to the severity and the influence range of the fault, and the repair operation is executed through the automatic script or tool of the automatic operation. Through deep mining of BMC underlying data value and fusion of an intelligent model and an automatic repair mechanism, full-process optimization of server fault detection and processing is realized.

Description

Technical Field

[0001] This invention belongs to the field of server fault detection technology, and in particular relates to an intelligent server fault detection method based on BMC. Background Technology

[0002] With the rapid development of cloud computing, big data, and artificial intelligence technologies, servers, as the core hardware devices of information systems, directly determine the continuity of business systems through their operational stability and reliability. In large-scale data centers, the number of servers in a single room can reach thousands or even tens of thousands. Traditional fault detection methods that rely on manual inspections or simple threshold alarms are no longer sufficient to meet the needs of efficient operation and maintenance. Current server fault detection technologies have the following limitations: First, relying on single threshold triggering of alarms by hardware sensors is insufficient for predicting gradual faults, often generating alarms only after a fault has occurred, leading to a high risk of business interruption. Second, the BMC (Baseboard Management Controller), as the core module of server hardware monitoring, has its native functions largely limited to basic status collection and log recording, failing to fully utilize its data interfaces for in-depth fault analysis. Third, existing intelligent detection models mostly rely on operating system layer data, failing in scenarios where the server is offline or the operating system crashes, and the matching degree between model training data and actual fault characteristics is low, resulting in high false alarm and false negative rates. Fourth, fault repair largely relies on manual intervention, with response cycles from fault discovery to repair lasting several hours, making it difficult to adapt to fields with stringent real-time requirements such as finance and healthcare. Furthermore, server hardware failures are complex, encompassing multiple components such as power supply, CPU, memory, hard drive, and network. The characteristics of different failures exhibit cross-correlation, making it difficult for traditional rule-based detection methods to establish comprehensive failure correlation models. Additionally, differences in BMC firmware and sensor data formats between manufacturers lead to poor compatibility of fault detection solutions across different server brands, increasing data center operation and maintenance costs. Therefore, it is urgent to improve existing server fault detection methods and solve the aforementioned technical problems. Summary of the Invention

[0003] The purpose of this invention is to provide a server fault intelligent detection method based on BMC, which improves existing server fault detection methods and solves the above-mentioned technical problems.

[0004] To solve the above-mentioned technical problems, the present invention adopts the following technical solution: A server fault intelligent detection method based on BMC includes the following process: S1: Adjust the server to be tested to BMC's debug mode and obtain the raw data in debug mode; S2: Based on the server failure to be tested, modify the sensor status and parameters in the original data, and determine whether the data received by BMC is sensor failure data. If so, proceed to step S3. S3: Determine whether the BMC has received a sensor malfunction alarm. When the BMC receives a sensor malfunction alarm, it preprocesses the valid data and the status information of the associated devices and stores them in the FRAM memory via the SPI bus. S4: Construct a fault model and train and optimize the fault model based on the preprocessed effective data and the status information of related equipment; S5: Collect specified data from the server under test in real time, preprocess it and input it into the optimized fault model. The fault model automatically classifies the preprocessed specified data and determines whether the server under test has a fault or fault tendency. If so, execute step S6. S6: Activate the automated remediation strategy, which includes automated decision-making and automated operation. Automated decision-making determines what remediation measures to take based on the severity and scope of the fault, while automated operation executes the remediation actions through automated scripts or tools.

[0005] Preferably, the specific process of step S1 is as follows: S11: Disconnect the server power, connect the BMC debugging serial port, and configure the serial port tool according to the BMC serial port protocol; S12: Power on the server, check the BMC print information, and enter debug mode according to the prompts; S13: Log in with the BMC administrator's username and password to query the sensor status and raw data that need to be modified.

[0006] Preferably, the specific process of step S2 is as follows: S21: Use IPMI in-band commands to query the real-time parameters of each sensor received by the BMC within the server operating system, and at the same time verify the parameter consistency from the remote terminal through IPMI out-of-band commands to establish the original parameter benchmark library; S22: For the type of fault to be tested, modify the sensor's raw data using preset configuration commands in debug mode; S23: Use the IPMI in-band and out-of-band commands to query the sensor's raw data storage area again. The address is obtained through sensorlist-v. Compare the hexadecimal values ​​before and after the modification to obtain the difference. S24: After the original data is modified, the sensor parameters of the BMC receiver are queried again after a specified sampling period and it is determined whether the parameters received by the BMC have changed. If yes, proceed to step S25; otherwise, repeat step S22. S25: Based on the preset fault determination rules, perform compliance verification on the modified BMC receiving parameters.

[0007] Preferably, the specific process for determining whether the BMC has received a sensor malfunction alarm in step S3 is as follows; S31: Use the ipmi command to query the BMC system event log, filter out sensor-related event records, and extract key information such as event type, occurrence time, sensor ID, and alarm level; S32: Analyze the alarm flag in the event log. If the flag is displayed as Asserted and the alarm level is a preset abnormal level, it is initially determined that there is a sensor abnormal alarm. S33: Monitor alarm information output in real time via BMC debug serial port. If an alarm message corresponding to the sensor is captured within a specified time after the sensor fault data is generated, and the message content is consistent with the BMC system event log record, then it is confirmed that BMC has received the alarm of sensor abnormality.

[0008] Preferably, the specific process of preprocessing the valid data and the status information of the associated devices in step S3 and storing them in the FRAM memory via the SPI bus is as follows: S34: Define the scope of valid data, including sensor fault data, BMC alarm logs, and status information of associated devices; S35: Preprocess the data, integrate multi-source data by millisecond-level time axis through timestamp alignment, remove duplicate records, standardize numerical parameters, perform structured parsing of text logs, and extract keywords to generate tag fields; S36: Initialize the FRAM memory via the SPI bus, check the memory read / write status and verify the response; S37: According to the preset data storage format, the main body is arranged in the order of sensor ID-fault data-related status-time stamp, the pre-processed data is encapsulated and written to the specified storage block of FRAM; S38: Send the SPI_READ command to read the stored content, perform CRC verification with the original packaged data, and if the verification passes, the storage is confirmed to be successful. At the same time, update the FRAM storage index table to record the data storage address and length.

[0009] Preferably, the specific process of step S4 is as follows: S41: Select a hybrid model architecture that integrates time series processing and feature classification. Use an LSTM network as the bottom-level feature extractor to capture temporal dependencies. The output layer is connected to a fully connected network to classify fault types. The model input dimension is set to the dimension of the preprocessed feature vector. S42: Read the preprocessed valid data and associated device status information from the FRAM memory and eMMC memory card, and divide them into a training set and a test set including fault labels according to a specified ratio; S43: Set the initial learning rate, batch size, and training epochs; generate the initial weights using the Xavier initialization method; divide the training set into multiple batches in chronological order, and sample data in each batch evenly according to the fault type; S44: Input the batch feature vector into the model. The LSTM layer processes the temporal features through a gating mechanism. The fully connected layer outputs the predicted probability distribution of each fault type. The weighted cross-entropy loss function is used to assign a specified weight to the fault type with a small sample size. The model parameters are updated by gradient descent. The average loss and accuracy of the training set are calculated after each training round.

[0010] Preferably, the specific process of step S5 is as follows: S51: Collect specified data at specified time intervals through the BMC interface, and ensure the time consistency of multi-source data through a timestamp synchronization mechanism during the collection process; S52: Perform the same preprocessing operations on the collected real-time data as on the training dataset, including deleting null values, correcting outliers, format conversion, and real-time feature extraction to obtain feature vectors; S53: Input the feature vector into the optimized fault model, calculate and output the probability distribution of each fault type, and output the fault type or fault tendency; S54: The model outputs classification results, including fault type, confidence level, and correlation features, which are pushed to the monitoring terminal through the BMC management interface.

[0011] Preferably, the specific process of real-time feature extraction in step S52, which calculates statistical features for a specified number of periods based on a sliding window and generates a feature vector consistent with that in the training phase, is as follows: S521: Based on the window parameters determined during the training phase, initialize a circular buffer to store real-time data, maintain a separate buffer for each data dimension, and sort them in ascending order by timestamp; S522: Whenever new sampled data is input, the window sliding mechanism is triggered to extract the data of the previous N periods from the buffer, where N is the window size; S523: Statistical characteristic calculation: Calculate statistics for numerical data within the window, including mean, variance, maximum / minimum value, and coefficient of variation; calculate the number of occurrences and duration of Boolean events within the window; S524: Feature Dimension Alignment: Sort the calculated statistical features by dimension according to the feature order defined in the training phase; automatically fill in default values ​​and mark new data dimensions, and remove redundant dimensions; S525: Feature Vector Generation: Combines aligned statistical features into a fixed-length vector, and normalizes it using a preset standardization method; the generated vector includes a timestamp and window integrity marker for subsequent model validation.

[0012] The beneficial effects of this invention include: This invention provides a server fault intelligent detection method based on BMC (Browser Controller Model). The method acquires raw data by adjusting the server under test to BMC's debug mode and determining whether the data received by BMC is sensor fault data. When BMC receives an alarm indicating sensor anomaly, a fault model is constructed, trained, and optimized. Specific data from the server under test is collected in real time, preprocessed, and input into the optimized fault model. The fault model automatically classifies the preprocessed data to determine whether the server under test has a fault or a fault tendency. If so, an automated repair strategy is initiated. Automated decision-making determines the appropriate repair measures based on the severity and scope of the fault, and the repair operation is executed through automated scripts or tools. By deeply mining the value of BMC's underlying data and integrating intelligent models with automated repair mechanisms, the entire process of server fault detection and handling is optimized.

[0013] First, raw sensor data is acquired through BMC's debug mode, and combined with the extraction of multi-dimensional features during fault model training, overcoming the limitations of traditional single-threshold alarms. The model can learn the correlation between different fault types, enabling early prediction of gradual faults, thus advancing fault warning time and reducing false alarm and false negative rates compared to existing technologies.

[0014] Secondly, it achieves low-level hardware data acquisition based on the BMC interface, unaffected by the server operating system status, and can still function normally even in system crashes or offline scenarios, solving the problem of traditional detection schemes that rely on operating system-level data failing in extreme cases. Through standardized data preprocessing and feature alignment mechanisms, it is compatible with BMC firmware and sensor data formats from different manufacturers.

[0015] Finally, the automated repair strategy, through a hierarchical decision-making mechanism, automatically executes operations such as restarting services and switching backup nodes based on the severity of the fault, reducing the fault response cycle from hours of traditional manual handling to seconds. This reduces business interruption time. Furthermore, the real-time feature extraction mechanism based on sliding windows and dynamic optimization strategies enable the model to continuously adapt to dynamic scenarios such as server hardware aging and load changes. Through incremental training and parameter updates, the model's accuracy in identifying new fault types is improved, significantly reducing model maintenance costs. Attached Figure Description

[0016] Figure 1This is a flowchart illustrating the intelligent server fault detection method based on BMC of the present invention.

[0017] Figure 2 This is a schematic diagram illustrating the working principle of the hybrid model architecture of the present invention. Detailed Implementation

[0018] The following is in conjunction with the appendix Figures 1-2 The present invention will be further described in detail below: Example 1 See appendix Figure 1 As shown, a server fault intelligent detection method based on BMC includes the following process: S1: Adjust the server to be tested to BMC's debug mode and obtain the raw data in debug mode; S2: Based on the server failure to be tested, modify the sensor status and parameters in the original data, and determine whether the data received by BMC is sensor failure data. If so, proceed to step S3. S3: Determine whether the BMC has received a sensor malfunction alarm. When the BMC receives a sensor malfunction alarm, it preprocesses the valid data and the status information of the associated devices and stores them in the FRAM memory via the SPI bus. S4: Construct a fault model and train and optimize the fault model based on the preprocessed effective data and the status information of related equipment; S5: Collect specified data from the server under test in real time, preprocess it and input it into the optimized fault model. The fault model automatically classifies the preprocessed specified data and determines whether the server under test has a fault or fault tendency. If so, execute step S6. S6: Activate the automated remediation strategy, which includes automated decision-making and automated operation. Automated decision-making determines what remediation measures to take based on the severity and scope of the fault, while automated operation executes the remediation actions through automated scripts or tools.

[0019] The specific process of step S1 is as follows: S11: Disconnect the server power, connect the BMC debugging serial port, and configure the serial port tool according to the BMC serial port protocol; S12: Power on the server, check the BMC print information, and enter debug mode according to the prompts; S13: Log in with the BMC administrator's username and password to query the sensor status and raw data that need to be modified.

[0020] The specific process of step S2 is as follows: S21: Use IPMI in-band commands to query the real-time parameters of each sensor received by the BMC within the server operating system, and at the same time verify the parameter consistency from the remote terminal through IPMI out-of-band commands to establish the original parameter benchmark library; S22: For the type of fault to be tested, modify the sensor’s raw data through preset configuration commands in debug mode, where parameter types include upper and lower thresholds, sampling frequency, and calibration coefficients. S23: Query the sensor's original data storage area again using the IPMI in-band and out-of-band commands. The address is obtained by sensor list -v. Compare the differences in hexadecimal values ​​before and after the modification to confirm that the original data has been changed as expected. S24: After the original data is modified, the sensor parameters of the BMC receiver are queried again after 1-3 sampling periods. The parameter change record is checked by the ipmitool event command. If the parameter jump record corresponding to the modification operation appears in the BMC log, and the current displayed value matches the modified original data with a degree greater than or equal to the preset threshold, it is determined whether the parameters received by the BMC have changed. If yes, proceed to step S25; otherwise, re-execute step S22. S25: Based on the preset fault determination rules, which include the temperature parameter exceeding the safety threshold for a specified time or the voltage parameter fluctuation exceeding the preset amplitude threshold, the modified BMC receiving parameters are checked for compliance. If any fault rule is met, the data is determined to be sensor fault data.

[0021] The specific process for determining whether the BMC has received a sensor malfunction alarm in step S3 is as follows; S31: Use the ipmi command to query the BMC system event log, filter out sensor-related event records, and extract key information such as event type, occurrence time, sensor ID, and alarm level; S32: Analyze the alarm flag in the event log. If the flag is "Asserted", that is, an alarm has been triggered and the alarm level is a preset abnormal level, then it is preliminarily determined that there is a sensor abnormal alarm. S33: Monitor alarm information output in real time via BMC debug serial port. If an alarm message corresponding to the sensor is captured within a specified time after the sensor fault data is generated, and the message content is consistent with the BMC system event log record, then it is confirmed that BMC has received the alarm of sensor abnormality.

[0022] The specific process of preprocessing the valid data and the status information of the associated devices in step S3 and storing them in the FRAM memory via the SPI bus is as follows: S34: Define the scope of valid data, including sensor fault data, BMC alarm logs and associated device status information. Sensor fault data includes fault type, parameter value and occurrence time. BMC alarm logs include corresponding records in SEL. Associated device status information includes CPU load, memory usage and hard disk I / O performance data. Data is collected jointly through ipmitool fru print and system commands. S35: Preprocess the data, integrate multi-source data by millisecond-level time axis through timestamp alignment, remove duplicate records, standardize numerical parameters, perform structured parsing of text logs, and extract keywords to generate tag fields; S36: Initialize the FRAM memory via the SPI bus, send the SPI_INIT instruction to configure the communication rate to 10MHz and the data format to 8 bits, check the memory read / write status, and verify the response via the FRAM_CHECK instruction; S37: According to the preset data storage format, that is, the preset header contains a check code and a data length field, the main body is arranged in the order of sensor ID-fault data-association status-time stamp, the pre-processed data is encapsulated, and the data is written to the specified storage block of FRAM through the SPI_WRITE instruction. The address is defined by the FRAM_MAP configuration file. S38: Send the SPI_READ command to read the stored content, perform CRC verification with the original packaged data, and if the verification passes, the storage is confirmed to be successful. At the same time, update the FRAM storage index table to record the data storage address and length.

[0023] The specific process of step S4 is as follows: S41: A hybrid model architecture integrating time series processing and feature classification is selected, using an LSTM network as the underlying feature extractor to capture temporal dependencies; the output layer is connected to a fully connected network for fault type classification. The model input dimension is set to the dimension of the preprocessed feature vector, and the output dimension is the number of fault types. See the schematic diagram illustrating the working principle of this hybrid model architecture. Figure 2 .

[0024] S42: Read the preprocessed valid data and associated device status information from the FRAM memory and eMMC memory card, and divide them into a training set and a test set including fault labels according to a specified ratio; perform data augmentation on the training set, add Gaussian noise to the numerical features, stretch the time series data, and slightly perturb the fault labels; S43: Set the initial learning rate to 0.01-0.05, the batch size to 32-128, and the number of training rounds to 50-200; use the Adam optimizer, and generate the initial weights using the Xavier initialization method; divide the training set into multiple batches in chronological order, and sample the data in each batch evenly according to the fault type; S44: Input the batch feature vector into the model. The LSTM layer processes the temporal features through a gating mechanism. The fully connected layer outputs the predicted probability distribution of each fault type. The weighted cross-entropy loss function is used to assign a specified weight to the fault type with a small sample size. The model parameters are updated by gradient descent. The average loss and accuracy of the training set are calculated after each training round.

[0025] The specific process of step S5 is as follows: S51: Collects specified data at specified time intervals through the BMC interface, including real-time sensor parameters, system operating indicators, network communication data and system logs. During the collection process, a timestamp synchronization mechanism is used to ensure the time consistency of multi-source data. S52: Perform the same preprocessing operations on the collected real-time data as on the training dataset, including deleting null values; if a parameter is null for a specified number of consecutive sampling periods, trigger the data completion mechanism and use forward padding to fill in the null values; correcting outliers by interpolating values ​​that exceed the normal range by 3 times the standard deviation, and converting them to structured labels and standardizing numerical parameters to a specified range; and extracting features in real time by calculating statistical features for a specified number of periods based on a sliding window to generate feature vectors consistent with those in the training phase. S53: Input the feature vector into the optimized fault model. The model calculates and outputs the probability distribution of each fault type through forward propagation. The threshold determination method is adopted. If the probability of a certain fault type is ≥ the threshold, it is determined that the fault of that type exists. If the probability of all fault types is < the threshold but there are at least 3 types with probabilities in the interval [0.3, 0.7), it is determined that there is a fault tendency. S54: The model outputs classification results, including fault type, confidence level, and associated features, which are pushed to the monitoring terminal through the BMC management interface. At the same time, the results are associated with the corresponding original data and stored in the eMMC storage card, archived in the format of "timestamp-fault type-feature vector", and the real-time status marker in FRAM is updated.

[0026] The specific process of real-time feature extraction in step S52, which calculates statistical features for a specified number of periods based on a sliding window and generates feature vectors consistent with those in the training phase, is as follows: S521: Based on the window parameters determined during the training phase, the size is set to 5-20 sampling periods, the step size is set to 1 sampling period, and a circular buffer is initialized to store real-time data. The buffer capacity is 1.2 times the window size, with reserved space for expansion. A separate buffer is maintained for each data dimension and sorted in ascending order by timestamp. S522: Whenever new sampled data is input, the window sliding mechanism is triggered to extract the data of the previous N periods from the buffer, where N is the window size. If the amount of data is insufficient, historical data is used to fill the gaps, and the filling area is marked. For missing segments in the time series, linear interpolation is used to complete them. S523: Statistical feature calculation: Calculate statistics for numerical data within the window, including mean (updated in real time using a moving average algorithm, with a computational complexity of O(1)), variance, maximum / minimum value (extreme values ​​are maintained using a double-ended queue, with each update taking O(1)), and coefficient of variation (the ratio of standard deviation to mean); calculate the number of occurrences and duration percentage (event duration / total window duration) for Boolean events within the window. S524: Feature Dimension Alignment: According to the feature order defined in the training phase, the calculated statistical features are sorted by dimension to ensure complete matching with the dimensions of the model input layer; for newly added data dimensions, default values ​​are automatically filled and marked, and redundant dimensions are removed, including offline sensors; S525: Feature Vector Generation: Combine the aligned statistical features into a fixed-length vector, normalize it using a preset standardization method to ensure that the value range of each element in the vector is consistent with the training data; generate the vector with a timestamp and window integrity marker for subsequent model validation.

[0027] The specific process of step S6 is as follows: S61: Based on the fault type, confidence level, and correlation characteristics output by the fault model, faults are classified into three levels. Level 1 is an emergency fault, including CPU temperature exceeding 95°C and power module failure, which requires immediate handling; Level 2 is a critical fault, including memory usage consistently above 90% and network packet loss rate exceeding 15%, which requires handling within 30 seconds; Level 3 is a minor fault, including fan speed slightly below the threshold and individual process response delays, which can be handled within 5 minutes. S62: By collecting real-time server cluster topology information and business deployment relationship data, analyze the types of services carried by the faulty server, the number of associated devices and users. For example, if the faulty server is a core database node and is associated with more than 5 business systems, the impact is determined to be "wide"; if it is only an edge computing node carrying a single non-critical business, the impact is determined to be "narrow". S63: Based on the preset decision matrix, determine the repair measures according to the fault level and the scope of impact. When the fault level is level 1 and the scope of impact is wide, trigger "dual-machine hot standby switch" and send an emergency alarm to the operation and maintenance personnel at the same time; when the fault level is level 2 and the scope of impact is medium, execute "service restart + resource scheduling" to migrate part of the load to other nodes; when the fault level is level 3 and the scope of impact is narrow, take "parameter adjustment" measures, including increasing fan speed and releasing cache.

[0028] S64: Read the automated script index corresponding to the selected repair measure from the FRAM memory, load the script file from the eMMC storage card according to the index, verify the integrity of the script, and ensure that it has not been tampered with by MD5 checksum; S65: Sends a permission verification request via the BMC's dedicated interface, carrying an encrypted device identifier and operation instructions. After successful BMC authentication, it obtains temporary root privileges, ensuring the script can perform low-level hardware operations. It then executes repair operations according to the steps defined in the script, with each step receiving real-time feedback on its execution status from the BMC. Taking "CPU overheating fault repair" as an example, it calls the `ipmitool raw` command to start the backup fan, remotely connects to the server via SSH, executes the `taskset` command to adjust the process's CPU affinity, monitors CPU temperature changes, and if the temperature does not drop to a safe threshold within 5 seconds, it triggers the next step of load migration. S66: After the repair operation is completed, collect real-time server status data and input it into the fault model for secondary judgment. If the model outputs "fault resolved" and the status is stable for 3 consecutive sampling periods, the repair is considered successful; if not, the script is re-executed according to the preset retry mechanism (maximum 3 retries), or the fault level is upgraded and manual intervention is notified. S67: Encapsulate key information during the repair process, including decision-making basis, execution steps, timestamps, and status feedback, into log entries, write them to a dedicated log block in the FRAM memory via the SPI bus, and back them up synchronously to the eMMC storage card. The log retention period is set to 90 days for subsequent auditing and model optimization.

[0029] In summary, the server fault intelligent detection method based on BMC provided by this invention obtains raw data by adjusting the server under test to the BMC's debug mode and determining whether the data received by the BMC is sensor fault data. When the BMC receives an alarm indicating sensor anomaly, a fault model is constructed, trained, and optimized. Specific data from the server under test is collected in real time, preprocessed, and input into the optimized fault model. The fault model automatically classifies the preprocessed data to determine whether the server under test has a fault or a fault tendency. If so, an automated repair strategy is initiated. Automated decision-making determines the appropriate repair measures based on the severity and scope of the fault, and the repair operation is executed through automated scripts or tools. By deeply mining the value of the underlying BMC data and integrating intelligent models with automated repair mechanisms, the entire process of server fault detection and handling is optimized.

[0030] By acquiring raw sensor data in BMC's debug mode and combining it with multi-dimensional feature extraction during fault model training, the limitations of traditional single-threshold alarms are overcome. The model learns the correlations between different fault types, enabling early prediction of gradual faults, thus advancing fault warning times and reducing false alarm and false negative rates. Low-level hardware data acquisition is achieved through the BMC interface, unaffected by server operating system status, solving the problem of traditional detection schemes relying on operating system-level data failing in extreme conditions. Through a hierarchical decision-making mechanism, operations such as service restart and backup node switching are automatically executed based on fault severity, shortening the fault response cycle from hours of traditional manual processing to seconds, reducing business interruption time. Furthermore, the real-time feature extraction mechanism based on sliding windows and dynamic optimization strategies allow the model to continuously adapt to dynamic scenarios such as server hardware aging and load changes.

Claims

1. A server fault intelligent detection method based on BMC, characterized in that, Includes the following processes: S1: Adjust the server to be tested to BMC's debug mode and obtain the raw data in debug mode; S2: Based on the server failure to be tested, modify the sensor status and parameters in the original data, and determine whether the data received by BMC is sensor failure data. If so, proceed to step S3. S3: Determine whether the BMC has received a sensor malfunction alarm. When the BMC receives a sensor malfunction alarm, it preprocesses the valid data and the status information of the associated devices and stores them in the FRAM memory via the SPI bus. S4: Construct a fault model and train and optimize the fault model based on the preprocessed effective data and the status information of related equipment; S5: Collect specified data from the server under test in real time, preprocess it and input it into the optimized fault model. The fault model automatically classifies the preprocessed specified data and determines whether the server under test has a fault or fault tendency. If so, execute step S6. S6: Activate the automated remediation strategy, which includes automated decision-making and automated operation. Automated decision-making determines what remediation measures to take based on the severity and scope of the fault, while automated operation executes the remediation actions through automated scripts or tools.

2. The intelligent server fault detection method based on BMC according to claim 1, characterized in that, The specific process of step S1 is as follows: S11: Disconnect the server power, connect the BMC debugging serial port, and configure the serial port tool according to the BMC serial port protocol; S12: Power on the server, check the BMC print information, and enter debug mode according to the prompts; S13: Log in with the BMC administrator's username and password to query the sensor status and raw data that need to be modified.

3. The intelligent server fault detection method based on BMC according to claim 1, characterized in that, The specific process of step S2 is as follows: S21: Use IPMI in-band commands to query the real-time parameters of each sensor received by the BMC within the server operating system, and at the same time verify the parameter consistency from the remote terminal through IPMI out-of-band commands to establish the original parameter benchmark library; S22: For the type of fault to be tested, modify the sensor's raw data using preset configuration commands in debug mode; S23: Use the IPMI in-band and out-of-band commands to query the sensor's raw data storage area again. The address is obtained by using sensor list -v. The difference in hexadecimal values ​​before and after the modification is obtained by comparison. S24: After the original data is modified, the sensor parameters of the BMC receiver are queried again after a specified sampling period and it is determined whether the parameters received by the BMC have changed. If yes, proceed to step S25; otherwise, repeat step S22. S25: Based on the preset fault determination rules, perform compliance verification on the modified BMC receiving parameters.

4. The intelligent server fault detection method based on BMC according to claim 1, characterized in that, The specific process for determining whether the BMC has received a sensor malfunction alarm in step S3 is as follows; S31: Use the ipmi command to query the BMC system event log, filter out sensor-related event records, and extract key information such as event type, occurrence time, sensor ID, and alarm level; S32: Analyze the alarm flag in the event log. If the flag is displayed as Asserted and the alarm level is a preset abnormal level, it is initially determined that there is a sensor abnormal alarm. S33: Monitor alarm information output in real time via BMC debug serial port. If an alarm message corresponding to the sensor is captured within a specified time after the sensor fault data is generated, and the message content is consistent with the BMC system event log record, then it is confirmed that BMC has received the alarm of sensor abnormality.

5. The intelligent server fault detection method based on BMC according to claim 4, characterized in that, The specific process of preprocessing the valid data and the status information of the associated devices in step S3 and storing them in the FRAM memory via the SPI bus is as follows: S34: Define the scope of valid data, including sensor fault data, BMC alarm logs, and status information of associated devices; S35: Preprocess the data, integrate multi-source data by millisecond-level time axis through timestamp alignment, remove duplicate records, standardize numerical parameters, perform structured parsing of text logs, and extract keywords to generate tag fields; S36: Initialize the FRAM memory via the SPI bus, check the memory read / write status and verify the response; S37: According to the preset data storage format, the main body is arranged in the order of sensor ID-fault data-related status-time stamp, the pre-processed data is encapsulated and written to the specified storage block of FRAM; S38: Send the SPI_READ command to read the stored content, perform CRC verification with the original packaged data, and if the verification passes, the storage is confirmed to be successful. At the same time, update the FRAM storage index table to record the data storage address and length.

6. The intelligent server fault detection method based on BMC according to claim 1, characterized in that, The specific process of step S4 is as follows: S41: Select a hybrid model architecture that integrates time series processing and feature classification. Use an LSTM network as the bottom-level feature extractor to capture temporal dependencies. The output layer is connected to a fully connected network to classify fault types. The model input dimension is set to the dimension of the preprocessed feature vector. S42: Read the preprocessed valid data and associated device status information from the FRAM memory and eMMC memory card, and divide them into a training set and a test set including fault labels according to a specified ratio; S43: Set the initial learning rate, batch size, and training epochs; generate the initial weights using the Xavier initialization method; divide the training set into multiple batches in chronological order, and sample data in each batch evenly according to the fault type; S44: Input the batch feature vector into the model. The LSTM layer processes the temporal features through a gating mechanism. The fully connected layer outputs the predicted probability distribution of each fault type. The weighted cross-entropy loss function is used to assign a specified weight to the fault type with a small sample size. The model parameters are updated by gradient descent. The average loss and accuracy of the training set are calculated after each training round.

7. The intelligent server fault detection method based on BMC according to claim 1, characterized in that, The specific process of step S5 is as follows: S51: Collect specified data at specified time intervals through the BMC interface, and ensure the time consistency of multi-source data through a timestamp synchronization mechanism during the collection process; S52: Perform the same preprocessing operations on the collected real-time data as on the training dataset, including deleting null values, correcting outliers, format conversion, and real-time feature extraction to obtain feature vectors; S53: Input the feature vector into the optimized fault model, calculate and output the probability distribution of each fault type, and output the fault type or fault tendency; S54: The model outputs classification results, including fault type, confidence level, and correlation features, which are pushed to the monitoring terminal through the BMC management interface.

8. The intelligent server fault detection method based on BMC according to claim 7, characterized in that, The specific process of obtaining the feature vector in step S52 is as follows: S521: Based on the window parameters determined during the training phase, initialize a circular buffer to store real-time data, maintain a separate buffer for each data dimension, and sort them in ascending order by timestamp; S522: Whenever new sampled data is input, the window sliding mechanism is triggered to extract the data of the previous N periods from the buffer, where N is the window size; S523: Statistical characteristic calculation: Calculate statistics for numerical data within the window, including mean, variance, maximum / minimum value, and coefficient of variation; calculate the number of occurrences and duration of Boolean events within the window; S524: Feature Dimension Alignment: Sort the calculated statistical features by dimension according to the feature order defined in the training phase; automatically fill in default values ​​and mark new data dimensions, and remove redundant dimensions; S525: Feature Vector Generation: Combines aligned statistical features into a fixed-length vector, and normalizes it using a preset standardization method; the generated vector includes a timestamp and window integrity marker for subsequent model validation.

Images