Abnormality detection method, system and device and storage medium

Abstract

The invention discloses an exception detection method, system and device and a storage medium, relates to the technical field of data processing, and is used for determining an exception root by comparing data of different levels in a server system so as to improve the accuracy of exception detection. The method comprises the following steps: collecting hardware register data and BMC interface layer data of each component in a server system; establishing a mapping relation between the hardware register data and the BMC interface layer data; the hardware register data and the BMC interface layer data which have the mapping relation are compared, and the cause of the abnormity is determined according to the comparison result.

Description

Technical Field

[0001] This invention relates to the field of data processing technology, and in particular to an anomaly detection method, system, device, and storage medium. Background Technology

[0002] With the rapid development of cloud computing, edge computing, and artificial intelligence technologies, the global server market continues to expand, and technological innovation has become the core driving force of the industry. Industry analysis predicts that the server market will maintain rapid and sustained growth in the future. As a core component of server management, the Baseboard Management Controller (BMC) undertakes key functions such as equipment status monitoring, health management, remote control, and operation and maintenance support. Its stability directly affects the reliability and maintainability of the server system.

[0003] However, under the existing technical architecture, the compatibility of the BMC with heterogeneous hardware platforms presents significant challenges. The BMC obtains data from the underlying registers via the I2C (Inter-Integrated Circuit) bus, but due to signal integrity defects in the I2C protocol itself and hardware differences, the raw data is susceptible to interference, easily leading to probabilistic monitoring failures. Existing testing methods verify data consistency through upper-layer interfaces, but cannot verify the correctness of the data source, making it difficult to guarantee the reliability of the test. Summary of the Invention

[0004] This invention provides an anomaly detection method, system, device, and storage medium, which are used to determine the root cause of anomalies by comparing data at different levels in a server system, thereby improving the accuracy of anomaly detection.

[0005] In a first aspect, an anomaly detection method is provided by an embodiment of the present invention, the method comprising:

[0006] Collect hardware register data and BMC interface layer data of various components in the server system;

[0007] Establish a mapping relationship between the hardware register data and the BMC interface layer data;

[0008] The hardware register data and BMC interface layer data with mapping relationship are compared, and the cause of the anomaly is determined based on the comparison results.

[0009] The anomaly detection method provided in this embodiment collects low-level data (hardware register data) and high-level data (BMC interface layer data) of each component, and maps the cross-level data together. By comparing data from different levels, it can achieve cross-level fault tracing and improve the accuracy of anomaly detection.

[0010] As an optional implementation, hardware register data and BMC interface layer data of various components in the server system are collected through any one or more of the following methods:

[0011] Hardware register data and BMC interface layer data are acquired in parallel through different processes, with one process acquiring hardware register data and another process acquiring BMC interface layer data; or,

[0012] Hardware register data for each component is acquired in parallel using multiple threads, with one thread dedicated to acquiring the hardware register data for one component; or,

[0013] The BMC interface layer data of each component is collected in parallel using multiple threads, with one thread used to collect the BMC interface layer data of one component.

[0014] This embodiment improves data processing efficiency by collecting data from different levels in parallel. When collecting bottom-level or top-level data from different components, parallel collection can also improve data processing efficiency, thereby improving detection efficiency.

[0015] As an optional implementation, after collecting hardware register data and BMC interface layer data from various components in the server system, the method further includes:

[0016] Determine if there is any abnormal data in the hardware register data or BMC interface layer data of each component;

[0017] In response to the presence of abnormal data in the hardware register data or the BMC interface layer data, the abnormal data is marked according to its type.

[0018] Write the marked hardware register data and BMC interface layer data to the log file.

[0019] This embodiment can also mark abnormal data in hardware register data or BMC interface layer data and write it to a log file, thereby enabling testers to quickly locate anomalies and effectively improve testing efficiency.

[0020] As an optional implementation, the abnormal data is marked according to its type, including:

[0021] In response to an abnormal data condition in the hardware register being empty, the empty data is assigned a first fixed value; or,

[0022] In response to an error in the BMC interface layer data where the data is empty, the empty data is assigned a second fixed value; or,

[0023] In response to a negative value in the BMC interface layer data, the negative value is assigned a third fixed value; or,

[0024] In response to an abnormal data point in the BMC interface layer that is positive and exceeds a preset range, the positive value is assigned a fourth fixed value; or,

[0025] In response to an interface information error in the BMC interface layer, the BMC interface layer data is assigned the fifth fixed value.

[0026] This embodiment provides an end-to-end data traceability mechanism by comparing data from different levels collected under the same component and the same timestamp, and cross-validating the data through comparison of different levels of data. It also solves transient anomaly problems through log backtracking.

[0027] As an optional implementation, establishing the mapping relationship between the hardware register data and the BMC interface layer data includes:

[0028] The hardware register data and BMC interface layer data of each component are time-aligned according to the order of the collected timestamps.

[0029] Based on the time-aligned hardware register data and BMC interface layer data, establish a mapping relationship between the hardware register data and BMC interface layer data of the same component collected at the same timestamp.

[0030] This embodiment constructs a timestamp-aligned dual-channel data warehouse and establishes an association mapping between I2C underlying register data and Redfish upper-layer interface data. This allows for the identification of I2C link anomalies or BMC data processing failures through difference comparison, thereby improving testing efficiency and accuracy.

[0031] As an optional implementation, the hardware register data and BMC interface layer data with a mapping relationship are compared, and the cause of the anomaly is determined based on the comparison result, including:

[0032] Compare the hardware register data and BMC interface layer data of the same component collected at the same timestamp;

[0033] In response to the comparison result indicating abnormal data in the hardware registers, a hardware link failure is determined; or,

[0034] If the comparison result shows that the difference between the hardware register data with mapping relationship and the BMC interface layer data is higher than the threshold, it is determined that the BMC data processing is abnormal.

[0035] This embodiment identifies I2C link anomalies or BMC data processing failures by comparing the differences between I2C underlying register data and Redfish upper-layer interface data, thereby improving testing efficiency and accuracy.

[0036] As an optional implementation, the method further includes:

[0037] At least one thread is used to perform login and logout tests on at least one interface of the BMC interface layer at a preset frequency, with one thread used to test the login and logout of one interface.

[0038] In response to a login or logout exception at at least one interface, obtain exception test data and mark the exception test data according to its type;

[0039] Write the abnormal test data of at least one marked interface to the log file, and determine that at least one interface of the BMC interface layer failed to respond.

[0040] This embodiment provides dynamic stability verification of the BMC service, integrating high-frequency login and logout tests of the BMC interface layer to quantify the robustness of the BMC service layer. It dynamically couples component data acquisition with BMC service layer stress testing (i.e., high-frequency login and logout) to reproduce systemic failures under high concurrency, improving test accuracy and efficiency.

[0041] As an optional implementation, the method further includes:

[0042] The collected hardware register data and BMC interface layer data of each component are written to a log file, with one log file corresponding to each component;

[0043] The log files of each component are converted into a chart with the acquisition time on the horizontal axis and the acquisition data on the vertical axis, and the chart is visualized. The acquisition data includes at least one of hardware register data, BMC interface layer data, and abnormal test data.

[0044] This embodiment provides visual anomaly analysis with an interactive analysis interface, supporting real-time monitoring, historical data backtracking, and anomaly data location for testers, effectively improving debugging flexibility.

[0045] Secondly, an electronic device provided by an embodiment of the present invention includes a processor and a memory, wherein the memory is used to store a program executable by the processor, and the processor is used to read the program in the memory and perform the following steps:

[0046] Collect hardware register data and BMC interface layer data of various components in the server system;

[0047] Establish a mapping relationship between the hardware register data and the BMC interface layer data;

[0048] The hardware register data and BMC interface layer data with mapping relationship are compared, and the cause of the anomaly is determined based on the comparison results.

[0049] Thirdly, embodiments of the present invention also provide an anomaly detection device, the device comprising:

[0050] The data acquisition unit is used to acquire hardware register data and BMC interface layer data of various components in the server system;

[0051] A data association unit is used to establish a mapping relationship between the hardware register data and the BMC interface layer data;

[0052] The anomaly localization unit is used to compare the hardware register data and BMC interface layer data that have a mapping relationship, and determine the cause of the anomaly based on the comparison result.

[0053] Fourthly, embodiments of the present invention also provide a computer storage medium having a computer program stored thereon, which, when executed by a processor, is used to implement the method described in any one of the first aspects above.

[0054] Fifthly, this application provides a computer program product comprising: computer program code, which, when run on a computer, causes the computer to perform the method described in any one of the first aspects.

[0055] These or other aspects of this application will become more apparent in the following description of embodiments. Attached Figure Description

[0056] To more clearly illustrate the technical solutions in the embodiments of the present invention, the accompanying drawings used in the description of the embodiments will be briefly introduced below. Obviously, the accompanying drawings described below are only some embodiments of the present invention. For those skilled in the art, other drawings can be obtained based on these drawings without creative effort.

[0057] Figure 1 This is a flowchart illustrating the implementation of an anomaly detection method provided in an embodiment of the present invention.

[0058] Figure 2 This is a schematic diagram of hardware register data monitoring provided in an embodiment of the present invention;

[0059] Figure 3 This is a schematic diagram of monitoring Redfish interface data provided in an embodiment of the present invention;

[0060] Figures 4A-4B This is a schematic diagram of an intelligent alignment engine for I2C-Redfish time alignment provided in an embodiment of the present invention;

[0061] Figure 5 This is a schematic diagram of upper-layer interface data monitoring provided in an embodiment of the present invention;

[0062] Figure 6 This is a schematic diagram of an anomaly detection system provided in an embodiment of the present invention;

[0063] Figure 7 This is a flowchart illustrating a specific implementation of an anomaly detection method provided in an embodiment of the present invention.

[0064] Figure 8 A schematic diagram of an electronic device structure provided in an embodiment of the present invention;

[0065] Figure 9 This is a schematic diagram of an anomaly detection device provided in an embodiment of the present invention. Detailed Implementation

[0066] To make the objectives, technical solutions, and advantages of this invention clearer, the invention will be further described in detail below with reference to the accompanying drawings. Obviously, the described embodiments are only a part of the embodiments of this invention, and not all of them. Based on the embodiments of this invention, all other embodiments obtained by those skilled in the art without creative effort are within the scope of protection of this invention.

[0067] In this embodiment of the invention, the term "and / or" describes the relationship between associated objects, indicating that three relationships can exist. For example, A and / or B can represent: A existing alone, A and B existing simultaneously, or B existing alone. The character " / " generally indicates that the preceding and following associated objects have an "or" relationship.

[0068] The application scenarios described in the embodiments of this invention are for the purpose of more clearly illustrating the technical solutions of the embodiments of this invention, and do not constitute a limitation on the technical solutions provided by the embodiments of this invention. Those skilled in the art will understand that with the emergence of new application scenarios, the technical solutions provided by the embodiments of this invention are also applicable to similar technical problems. In the description of this invention, unless otherwise stated, "multiple" means two or more.

[0069] Before introducing the anomaly detection method provided in the embodiments of this application, for ease of understanding, the technical background of the embodiments of this application will be described in detail below.

[0070] Under the existing technical architecture, the BMC faces significant challenges in its compatibility with heterogeneous hardware platforms, specifically in terms of I2C link reliability. The BMC obtains underlying register data via the I2C bus, including the on-premises status, temperature, voltage, and power consumption of components such as the CPU (Central Processing Unit), memory, hard drive, PSU (Power Supply Unit), FAN (fan), and PCIe (Peripheral Component Interconnect Express). However, due to signal integrity defects inherent in the I2C protocol and hardware differences, the raw data is susceptible to interference, requiring the BMC to rely on secondary data processing strategies (such as filtering and verification) to generate effective monitoring information. When the data processing algorithm cannot adapt to abnormal scenarios, probabilistic monitoring failures (such as intermittent data loss or numerical jumps) will occur. Insufficient reliability of upper-layer interface data: Existing testing methods verify data consistency through upper-layer interfaces such as Redfish (a server hardware management interface standard based on modern web technologies developed by the Distributed Management Task Force (DMTF), IPMI (Intelligent Platform Management Interface), and SNMP (Simple Network Management Protocol), but cannot verify the correctness of the data source. For example, component temperature readings returned by different interfaces may be consistent, but if the underlying registers have generated incorrect original values ​​due to I2C link anomalies, the BMC will still generate invalid output based on the erroneous data, creating a "consistency illusion." Low efficiency in fault diagnosis: The randomness and short duration of probabilistic problems make traditional manual testing difficult to reproduce, and it lacks the ability to compare data over time, making it impossible to accurately locate the root cause of the anomaly. For example, it is impossible to distinguish between I2C hardware link failures and defects in the BMC data processing logic.

[0071] Current BMC component information monitoring technology suffers from the following key problems, which severely restrict system reliability and testing efficiency, as detailed below:

[0072] (1) Limitations of Single-Dimensional Monitoring: Pure upper-layer interface testing (such as Redfish multi-interface comparison) can only verify data consistency and cannot trace the authenticity of underlying data; pure lower-layer register capture (such as direct reading of I2C instructions) can obtain raw data, but lacks the ability to verify the BMC processing logic. The lack of correlation analysis between lower-layer register data and upper-layer interface data makes it impossible to quickly determine the domain of responsibility when an anomaly occurs, for example, it is impossible to determine whether it is the hardware link layer, the BMC data processing layer, or the interface transmission layer. Current monitoring methods only focus on isolated verification of the data output end (BMC upper-layer interface) or the input end (I2C register), lacking an end-to-end data traceability mechanism.

[0073] (2) Lack of probabilistic anomaly detection capability: Traditional testing methods only perform static verification on BMC output data at discrete time points, lacking the ability to perform continuous time-series analysis on component monitoring data. Due to random interference at the hardware layer such as I2C link noise and register read / write conflicts, as well as boundary condition vulnerabilities in the BMC data processing algorithm, anomalies often exhibit short-term suddenness (such as second-level abnormal data changes). Existing technologies, due to insufficient sampling frequency and the lack of a continuous monitoring mechanism, cannot effectively capture such transient faults, creating a testing blind spot.

[0074] (3) Insufficient verification of data processing reliability: For continuous sensor data such as temperature and voltage, the existing solution only verifies the existence of the result after BMC processing (such as non-empty value), while ignoring the dynamic deviation between the original value and the processed value. It cannot identify data distortion caused by the failure of the filtering algorithm or the error of the calibration parameters. There is a problem of time sequence consistency break. When BMC data processing is blocked or retried, the traditional method cannot detect the time lag or out-of-order problem of the output result.

[0075] (4) Low utilization of test resources: Currently, testing relies on manual methods. Due to the explosive growth of component types (CPU / memory / hard disk / PSU, etc.) and monitoring parameters (on-site status, temperature, voltage, power consumption, etc.), manual testing leads to a linear increase in execution time. Manual operation is prone to false negative / false positive results due to omissions in test steps and environmental interference, introducing human error and reducing the credibility of test conclusions. Traditional methods rely on sequential triggering of IPMI / Redfish queries and I2C commands, which cannot achieve concurrent monitoring of multiple components, resulting in a mismatch between the test window and the real load scenario. Furthermore, existing technologies do not dynamically couple component data acquisition with BMC service layer stress testing (such as high-frequency login and logout), making it difficult to reproduce systemic failures under high concurrency.

[0076] To address the aforementioned technical issues, this application provides a method for cross-level collaborative monitoring to detect server system anomalies. By comparing hardware register data and BMC interface layer data of various components in the server system, the correctness of the BMC data processing logic is verified, accurately distinguishing between I2C physical layer faults, BMC application layer data processing anomalies, and other problems. Through cross-level data correlation analysis, the root cause of the anomaly is located, improving the accuracy and efficiency of anomaly detection. Furthermore, the testing process requires no manual intervention, avoiding errors introduced by manual operation and saving computational resources.

[0077] like Figure 1 As shown, the implementation flow of an anomaly detection method provided in this embodiment is as follows:

[0078] Step 100: Collect hardware register data and BMC interface layer data of each component in the server system;

[0079] Optionally, the hardware register data in this embodiment includes, but is not limited to: register data transmitted via the I2C bus. This register data includes, but is not limited to: operating parameters of components such as the CPU, memory, hard disk, PSU, fan, and PCIe devices, continuously captured at a set frequency. These operating parameters include, but are not limited to, presence detection, thermal reading, power telemetry, and voltage output (VR output). The hardware register data in this embodiment can be understood as the underlying register data of the server system, collected through I2C bus polling technology. Optionally, when collecting this hardware register data, hardware register data from different components can be collected in parallel, thereby improving data processing efficiency.

[0080] Optionally, the BMC interface layer data in this embodiment includes, but is not limited to, at least one of the following: Redfish interface data, Web interface data, IPMI interface data, and SNMP interface data.

[0081] In some embodiments, hardware register data and BMC interface layer data of various components in the server system are collected in the following manner:

[0082] Hardware register data and BMC interface layer data are acquired in parallel through different processes. One process is used to acquire hardware register data, and another process is used to acquire BMC interface layer data.

[0083] In practice, two processes can be created to collect data in parallel and synchronously. One process collects register data from each component, while the other process collects BMC interface layer data from each component. This enables parallel and synchronous data collection at different levels in the server system, effectively improving data processing efficiency.

[0084] In some embodiments, when acquiring hardware register data from various components, data can be acquired in parallel in the following manner to improve data processing efficiency:

[0085] The hardware register data of each component is acquired in parallel using multiple threads, with one thread used to acquire the hardware register data of one component.

[0086] During implementation, I2C bus polling technology is used to continuously capture key operating parameters of the CPU, memory, hard disk, PSU, fan and PCIe devices at a set frequency, including hardware register data such as presence detection, thermal reading, power telemetry and voltage regulation output.

[0087] Optionally, after acquiring the hardware register data of each component, this application can also perform a number system conversion on the hardware register data, that is, convert the hexadecimal hardware register data (source data) into decimal hardware register data, so as to facilitate the comparison of the hardware register data with the BMC interface layer data.

[0088] In some embodiments, when collecting BMC interface layer data from various components, the data can be collected in parallel in the following manner to improve data processing efficiency:

[0089] The BMC interface layer data of each component is collected in parallel using multiple threads, with one thread used to collect the BMC interface layer data of one component.

[0090] In practice, this embodiment can build a multi-threaded data acquisition engine to achieve concurrent acquisition and verification of management interface data. The data acquisition scope covers the status information of core components such as CPU, memory, and hard disk.

[0091] Optionally, BMC interface layer data can be collected in the following way:

[0092] Send a request message to the interface of the BMC interface layer to request the BMC to return interface data; receive a response message sent by the BMC, the response message carrying interface data, and identify the interface data as BMC interface layer data.

[0093] In implementation, taking the acquisition of the Redfish interface of the BMC interface layer as an example, after sending a GETURL request message to the Redfish interface of the BMC, the BMC will return a corresponding response message. The interface data carried in the response message is identified as the BMC interface layer data. One component corresponds to one URL interface.

[0094] In some embodiments, after collecting hardware register data and BMC interface layer data of various components in the server system, this embodiment further performs the following steps:

[0095] Step a: Determine if there is any abnormal data in the hardware register data or BMC interface layer data of each component;

[0096] During implementation, when hardware register data is empty, it is considered abnormal. This abnormal data is marked and written to the log, allowing maintenance personnel to locate the root cause of the anomaly based on the marked abnormal data in the log. Similarly, when BMC interface layer data is empty or negative, it is considered abnormal. Conversely, when BMC interface layer data is positive and exceeds a preset range, it is also considered abnormal. The preset range can be determined based on the specific component; different components have different preset ranges for their BMC interface layer data. Even for the same component, different parameters (such as on-state, temperature sensor data, power consumption measurement values, voltage output, etc.) have different preset ranges for their BMC interface layer data. For example, if the BMC interface layer data corresponding to temperature sensor data is 6000, it is considered abnormal.

[0097] Step b: In response to the presence of abnormal data in the hardware register data or the BMC interface layer data, mark the abnormal data according to the type of abnormal data;

[0098] Optionally, the types of abnormal data in this embodiment include, but are not limited to: empty hardware register data, empty BMC interface layer data, negative BMC interface layer data, and positive BMC interface layer data that exceeds a preset range.

[0099] Step c: Write the hardware register data and BMC interface layer data of each marked component into the log file.

[0100] Optionally, the hardware register data of each tagged component is written to a log file according to a fixed format. Similarly, the BMC interface layer data of each tagged component is written to a log file according to a fixed format. Optionally, one log file corresponds to the hardware register data of one component, or one log file corresponds to the BMC interface layer data of one component. One example is writing the data to the log file (log) in the format of acquisition timestamp, component name, component parameter name, and acquired parameter value.

[0101] Optionally, when abnormal data is detected in the hardware register data or the BMC interface layer data, the abnormal data can be automatically marked and written to a log file. Maintenance personnel can quickly identify the abnormal data based on the marks in the log file. The log file can also be converted into a chart for visualization. Users can quickly locate the abnormal data in the displayed chart based on the marked abnormal data, which facilitates the user's abnormality root cause location and analysis and improves the efficiency of abnormality detection.

[0102] In implementation, in response to abnormal data in the hardware register data or the BMC interface layer data, the abnormal data is assigned a fixed value corresponding to its type and written to the log file. This allows maintenance personnel to quickly find the abnormal data from the log file, improving anomaly detection efficiency. The log file can also be converted into a chart for visualization. Since assigning fixed values ​​to the abnormal data and displaying it graphically allows for quick identification of the abnormal data, further improving anomaly detection efficiency.

[0103] In some embodiments, when it is determined that there is abnormal data in the hardware register data or the BMC interface layer data, the abnormal data is marked in one or more of the following ways according to the type of abnormal data:

[0104] Method a: In response to an abnormal data error in the hardware register, where the data is empty, the empty data is assigned a first fixed value;

[0105] In implementation, hardware register data (i.e., hexadecimal source data) transmitted via the I2C bus can be input into the corresponding data processing module. Then, the hexadecimal source data is adaptively converted into readable decimal data, and anomaly detection is performed on the converted hardware register data. The detection rule is as follows: if the hardware register data is empty, a first fixed value is assigned, such as assigning "-1000" to empty hardware register data. Finally, the collected hardware register data is written to the log in a fixed format (collection timestamp, component name, component parameter name, collected parameter value). In this embodiment, empty data refers to missing or null values. The collected parameter value in this embodiment is the register value.

[0106] Method b: In response to an error in the BMC interface layer data, if the data is empty, assign the empty data a second fixed value.

[0107] Method c: In response to an abnormal data error in the BMC interface layer, if the data is negative, assign the negative value to a third fixed value;

[0108] In method d, if the abnormal data in response to the BMC interface layer is positive and exceeds the preset range, the positive value is assigned a fourth fixed value.

[0109] Method e: In response to an error in the BMC interface layer's interface information response, assign the BMC interface layer data to the fifth fixed value.

[0110] In implementation, taking the Redfish interface as an example, the data monitoring scope covers the status information of core components such as CPU, memory, and hard drive. After sending a GET URL request message to the Redfish interface of BMC (each component corresponds to a URL interface), BMC will return a corresponding response message. At this time, the timestamp, return code, and response data carried in the response message are automatically recorded. That is, the returned timestamp, return code, and response data are used as the collected BMC interface layer data. The timestamp, return code, and parameter values ​​are written to a temporary storage unit, and then the data stored in the temporary storage unit is processed for abnormal data. When processing abnormal data, the returned information is first classified by the return code. For example, a return code of '200' indicates that the interface information response is correct, otherwise it indicates that the interface information response is incorrect. When the interface information response is correct, the specific parameter value returned is judged. If the parameter value is empty, a second fixed value such as "-1000" is assigned to it. If the parameter value is negative, a third fixed value such as "-2000" is assigned to it. If the parameter value is positive but exceeds the preset range (such as a temperature value of 6000), a fourth fixed value "-6000" is assigned to it. When the interface information response is incorrect, the parameter value in the BMC interface layer data corresponding to this interface is assigned the value "-7000".

[0111] It should be noted that the assignment in this embodiment is for the convenience of classifying and processing abnormal data. The corresponding assignment only represents the flag bit and does not represent the actual reading value. Finally, the BMC interface layer data after anomaly processing is stored in a log file according to a fixed format (collection timestamp, component name, component parameter name, collected parameter value). This log contains both normal BMC interface layer data and abnormal data.

[0112] Optionally, in this embodiment, the processing of hardware register data and BMC interface layer data is automatically and adaptively multi-threaded, with each thread processing the hardware register data or BMC interface layer data of one component, thereby effectively improving data acquisition efficiency.

[0113] Step 101: Establish the mapping relationship between the hardware register data and the BMC interface layer data;

[0114] This embodiment establishes a mapping relationship between the hardware register data of the same component and the BMC interface layer data, thus associating the underlying data and upper-layer data of each component, making it easier to more accurately locate the root cause of the anomaly.

[0115] In some embodiments, the mapping relationship between the hardware register data and the BMC interface layer data is established in the following manner:

[0116] Based on the chronological order of the collected timestamps, the hardware register data and BMC interface layer data of each component are time-aligned; based on the time-aligned hardware register data and BMC interface layer data, a mapping relationship is established between the hardware register data and BMC interface layer data of the same component collected at the same timestamp.

[0117] During implementation, a timing synchronization strategy is adopted to ensure that hardware register data and BMC interface layer data are aligned in timing. It should be noted that hardware register data is processed by the BMC and then transmitted to the BMC interface layer to obtain BMC interface layer data. By establishing a mapping relationship between hardware register data and BMC interface layer data, a cross-level association mapping is established between the lower-level data (hardware register data) and upper-level data (BMC interface layer data) of the same component collected at the same timestamp. This facilitates the analysis of the lower-level and upper-level data of the same component at the same time, thereby quickly identifying anomalies, locating the root cause of anomalies, and improving the accuracy of anomaly detection.

[0118] In some embodiments, this embodiment can also perform stress testing on the interface stability of the BMC interface layer. The specific testing steps are as follows:

[0119] At least one thread is used to perform login and logout tests on at least one interface of the BMC interface layer at a preset frequency. One thread is used to test the login and logout of one interface. Optionally, the interfaces of the BMC interface layer include, but are not limited to, at least one of the Redfish interface and Web interface.

[0120] In response to a login or logout exception at at least one interface, obtain exception test data and mark the exception test data according to its type;

[0121] Write the abnormal test data of at least one marked interface to the log file, and determine that at least one interface of the BMC interface layer failed to respond.

[0122] Optionally, this embodiment can also process the log files related to interface stability stress testing. When the abnormal test data (i.e., the recorded flag value) in the read log file is '-1', it is determined to be an interface response failure. This embodiment can also record the abnormal test data in the log after judging the values ​​of various parameters, thereby realizing full-path tracing from hardware events to software responses. In particular, this embodiment can record only the abnormal test data with faults, effectively improving the efficiency of abnormal testing.

[0123] In implementation, high-frequency login and logout operations of the Redfish / Web interface can be automatically simulated. One thread continuously creates and deletes Redfish sessions, while another thread continuously sends request messages to the Web API login and logout interface. The two threads operate independently and concurrently. During monitoring, both threads need to handle outlier values ​​in the BMC response messages: if the return code in the response message is '202', it indicates a successful request, and the flag value is recorded as '1', indicating normal login or logout; otherwise, it indicates a failed request, and the flag value is recorded as '-1', indicating an abnormal login or logout. When the flag value is '-1', it is determined that the BMC interface layer's interface response has failed. This embodiment quantitatively evaluates key indicators such as the session retention rate of the BMC service layer (i.e., if there are no failures under the above high-frequency login and logout operations, it indicates that the service layer session response is stable) and authentication response latency, and judges and records abnormal events in real time during the testing process.

[0124] Step 102: Compare the hardware register data with the mapping relationship with the BMC interface layer data, and determine the cause of the anomaly based on the comparison results.

[0125] During implementation, by comparing hardware register data and BMC interface layer data of the same component collected at the same timestamp, cross-layer data discrepancies can be identified. The correctness of the BMC data processing logic is verified by comparing the hardware register data with the BMC-processed data (i.e., BMC interface layer data). This accurately distinguishes between I2C physical layer faults and BMC application layer data processing anomalies. By combining timing correlation analysis, the root cause of anomalies can be located, improving diagnostic efficiency.

[0126] In some embodiments, the cause of the anomaly is determined based on the comparison results in the following manner:

[0127] Compare the hardware register data and BMC interface layer data of the same component collected at the same timestamp;

[0128] (1) In response to the comparison result showing abnormal data in the hardware register data, it is determined that the hardware link has failed;

[0129] In practice, when the parameter value in the hardware register data is "-1000", it is determined as a hardware link failure, which can be identified as an I2C link failure. The parameter value in the hardware register data can be a parameter value that has already been marked as abnormal data, meaning the parameter value has already been assigned a value. Thus, when automatically identifying parameter values ​​in the log file, if it is abnormal data that has already been assigned a value, the type of abnormal data can be immediately identified based on the parameter value. This type allows for the determination of the current root cause of the exception. For example, when the parameter value in the hardware register data is identified as "-1000", the cause of the current exception can be quickly located as an I2C link failure.

[0130] (2) In response to the comparison result that the difference between the hardware register data with mapping relationship and the BMC interface layer data is higher than the threshold, it is determined that the BMC data processing is abnormal.

[0131] In practice, when the parameter value in the hardware register is normal, but the absolute difference between the hardware register and the BMC interface layer data is greater than a threshold (e.g., 20), it is judged as a BMC data processing abnormality problem.

[0132] Optionally, this embodiment can also process the log files related to interface stability stress testing. When the abnormal test data (i.e., the recorded flag value) in the read log file is '-1', it is determined to be an interface response failure. This embodiment can also record the abnormal test data in the log after judging the values ​​of various parameters, thereby realizing full-path tracing from hardware events to software responses. In particular, this embodiment can record only the abnormal test data with faults, effectively improving the efficiency of abnormal testing.

[0133] This embodiment establishes a spatiotemporal correlation between hardware register data and BMC interface layer data, and can simultaneously monitor the service stability of the Redfish / Web interface, thereby achieving accurate diagnosis of BMC system stability. Specifically, the cross-level collaborative monitoring engine unit maps hardware register data to BMC interface layer data (the output logs of both hardware register data and BMC interface layer data have a unified and fixed format, representing the collection timestamp, component name, component parameter name, and collected parameter value). It maps the parameter values ​​(register values) of each component collected at each timestamp to the upper-layer interface read values ​​(i.e., the parameter values ​​of each component in the BMC interface layer data). Finally, it performs fault diagnosis and judgment on the parameter values ​​of the same component at the same timestamp.

[0134] In some embodiments, this embodiment may also provide visual diagnostics and dynamic testing support. The specific visualization implementation process is as follows:

[0135] The collected hardware register data and BMC interface layer data of each component are written to a log file, with one log file corresponding to each component;

[0136] The log files of each component are converted into a chart with the acquisition time on the horizontal axis and the acquisition data on the vertical axis, and the chart is visualized. The acquisition data includes at least one of hardware register data, BMC interface layer data, and abnormal test data.

[0137] In implementation, this embodiment supports visualized anomaly analysis and dynamic testing. It employs a two-dimensional time-domain-parameter value mapping technique to convert time-series data in log files into visual charts. Specifically, it reads log files containing hardware register data, BMC interface layer data, and anomaly test data, and inputs them into a data table generation module. This module utilizes ECharts' powerful JavaScript charting library, supporting interactive functions such as data zooming and tooltips. It converts each log file into a visual chart with the acquisition time on the horizontal axis and the acquired data (parameter values) on the vertical axis. The results are ultimately saved in the "result.html" file. Testers can analyze the parameter values ​​in "result.html" to determine if anomalies exist (e.g., high fluctuations in the monitored curve indicate anomalies). It also allows for real-time extraction of intermediate test results (test data) during the testing process, improving debugging flexibility.

[0138] like Figure 2 As shown in the diagram, this embodiment provides a monitoring schematic of hardware register data. This embodiment utilizes high-precision timestamp synchronization technology to synchronously acquire hardware register data from various components in the server system. An intelligent data parsing engine automatically converts the hardware register data into readable data, ultimately generating a visualized monitoring graph based on a timeline. This visualization interface supports dynamic interactive operations, including timeline zooming and hovering over data points to view details. For example, users can drag a slider to zoom in on parameter values ​​(such as abnormal data) for a specific time period, or view the overall data for that period, significantly improving data monitoring efficiency.

[0139] like Figure 3As shown, this embodiment also provides a monitoring diagram of Redfish interface data. This embodiment collects the component status information of the upper-layer Redfish interface in real time and uses a timing alignment strategy to achieve accurate matching between the register data of the hardware components acquired by I2C and the upper-layer interface data. The visualization interface supports dynamic interactive operations, including timeline zooming and data point hovering for details. For example, users can drag the slider to zoom in on parameter values ​​(such as abnormal data) for a certain period, or view the overall data for a certain period, significantly improving data monitoring efficiency. Each component corresponds to a graph, and a graph can display the parameter values ​​of various parameters for a component, such as input voltage, input current, input power consumption, output voltage, output current, output power consumption, core temperature, inlet temperature, and output voltage.

[0140] like Figures 4A-4B As shown in the diagram, this embodiment also provides a schematic of an intelligent comparison engine for I2C-Redfish timing alignment. By comparing the specific parameters of hardware register data transmitted via the I2C bus and Redfish interface data, it can identify data differences and effectively verify the accuracy and rationality of the BMC data processing logic. For example, in the hardware register data of the same component and at the same time stamp, the input power consumption PSU1 is -60000 and the input voltage PSU2 is 64, while in the Redfish interface data of the same component and at the same time stamp, the input power consumption is 238 and the input voltage is 232. In this case, the root cause of the anomaly can be determined based on the difference information, effectively verifying the accuracy and rationality of the BMC data processing logic. This embodiment achieves spatiotemporal alignment of hardware and software data, synchronously capturing monitoring data within a single timing framework, and further realizing cross-layer fault tracing by constructing a parameter mapping matrix.

[0141] like Figure 5 As shown in the diagram, this embodiment provides a schematic of upper-layer interface data monitoring. Through dynamic load simulation technology, it automatically executes high-frequency login / logout tests (Redfish + Web dual-interface concurrency), accurately capturing interface anomalies and session conflicts, and displaying the monitoring results in a visual format. This automated approach achieves cross-layer stability of the BMC with I2C-Redfish timing alignment. Each unit module runs in parallel without interference, requiring no manual intervention during testing, thus reducing the probability of human error and saving resources.

[0142] This embodiment also provides a BMC cross-layer anomaly detection system based on I2C-Redfish timing alignment. By constructing a collaborative monitoring system between hardware registers and the BMC interface layer, it achieves full-stack stability assessment of the server management controller. The anomaly detection system employs multi-source heterogeneous data fusion technology, synchronously collecting hardware register data transmitted via the I2C bus and Redfish interface data provided by the BMC interface layer. Through timing alignment, it establishes a cross-layer data association mapping, further improving the reliability of the BMC component monitoring module.

[0143] like Figure 6 As shown, this embodiment provides an anomaly detection system, which includes: a hardware register real-time monitoring unit 600, an upper-layer interface intelligent monitoring unit 601, an interface stability stress testing unit 602, and a cross-level collaborative monitoring engine unit 603.

[0144] The hardware register real-time monitoring unit 600 employs an improved parallel I2C bus polling technology to continuously capture key operating parameters of the CPU, memory, hard disk, PSU, fan, and PCIe devices at high frequency, including in-situ status, temperature sensor data, power consumption measurement values, and voltage output. It can also input the register information data captured by I2C (i.e., hexadecimal source data) into the corresponding data processing module, then adaptively convert the hexadecimal source data into readable decimal data, and finally perform outlier detection on the converted data.

[0145] The upper-layer interface intelligent monitoring unit 601, built on the Redfish architecture, utilizes a multi-threaded data acquisition engine to achieve concurrent acquisition and verification of management interface data. The monitoring scope covers the status information of core components such as CPU, memory, and hard disk. This unit sends a GET URL request to the BMC's Redfish interface (each component corresponds to a URL interface), and the BMC returns the corresponding response information. This monitoring unit automatically records the timestamp, return code, and response data carried in the response message, and writes the timestamp, return code, and parameter values ​​to a temporary storage unit. Then, it performs anomaly processing on the data stored in the temporary storage unit. Request-response timestamp marking technology ensures the accuracy of data timing. Compared to traditional single-threaded query methods, this unit improves data acquisition efficiency.

[0146] The Interface Stability Stress Test Unit 602 is used to simulate high-frequency login and logout operations of the Redfish / Web interface, quantitatively evaluate key indicators such as session retention rate and authentication response latency of the BMC service layer, and record abnormal events in real time during the test process.

[0147] The cross-level collaborative monitoring engine unit 603 establishes a spatiotemporal correlation between the hardware register layer and the BMC interface layer, enabling precise diagnosis of BMC system stability, including issues such as I2C link failures, BMC data processing anomalies, and interface response delays. This allows for full-path tracing from hardware events to software responses. Furthermore, it provides visual output of the hardware registers and BMC interface layer.

[0148] like Figure 7 As shown in the figure, this embodiment also provides a specific implementation process of an anomaly detection method, as follows:

[0149] Step 700: Parallel acquisition of hardware register data and BMC interface layer data, and execution of login and logout of the Redfish / Web interface of the BMC interface layer;

[0150] During implementation, users obtain the test toolkit, configure the test environment and select test items, run the test program to start the test, and collect hardware register data, BMC interface layer data, and execute login and logout of the Redfish / Web interface of the BMC interface layer in parallel.

[0151] Step 701a: Determine if the hardware register data is empty. If yes, proceed to step 702a; otherwise, proceed to step 703a.

[0152] Step 702a: Process the empty data and proceed to step 703a;

[0153] Among them, a first fixed value can be assigned to empty data.

[0154] Step 703a: Write the hardware register data to the log file according to a fixed format, and then proceed to step 704;

[0155] This involves converting the read hardware register data into a number system to obtain the register data corresponding to each component and writing it to the log file.

[0156] Step 701b: Determine if the BMC interface layer data is abnormal. If so, proceed to step 702b; otherwise, proceed to step 703b.

[0157] Step 702b: Process the abnormal data and proceed to step 703b;

[0158] Among these options, empty data can be assigned a second fixed value; or, negative values ​​can be assigned a third fixed value; or, positive values ​​that exceed a preset range can be assigned a fourth fixed value.

[0159] Step 703b: Write the BMC interface layer data to the log file according to a fixed format, and then proceed to step 704;

[0160] Step 701c: Determine if the login / logout is abnormal. If so, proceed to step 702c; otherwise, proceed to step 703c.

[0161] Step 702c: Process the abnormal test data and proceed to step 703c;

[0162] Among these options, abnormal test data can be assigned a fifth fixed value.

[0163] Step 703c: Write the abnormal test data to the log file, and then proceed to step 704;

[0164] Step 704: Analyze and process the log files of each component;

[0165] Specifically, it can compare the hardware register data and BMC interface layer data that have a mapping relationship, determine the cause of the anomaly based on the comparison results, and determine the failure of the Redfish / Web interface response of the BMC interface layer based on the abnormal test data in the log file.

[0166] Step 705: Convert the log files of each component into a chart with the collection time on the horizontal axis and the collection data on the vertical axis, and then visualize the chart.

[0167] Among them, it can be visualized using HTML (HyperText Markup Language).

[0168] This embodiment can capture I2C underlying register data and Redfish upper-layer interface data in parallel to achieve synchronous capture of data sources; it can perform correlation mapping of dual-channel data based on timestamps, identify I2C link anomalies or BMC data processing failures through difference comparison, and solve transient anomaly problems; it can also achieve dynamic stability verification, integrate high-frequency Redfish / Web interface login and logout tests, and quantify the robustness of the BMC service layer.

[0169] Based on the same inventive concept, this embodiment of the invention also provides an electronic device. Since this electronic device is the same as the electronic device in the method of this embodiment of the invention, and the principle of solving the problem by this electronic device is similar to that of this method, the implementation of this electronic device can refer to the implementation of the method, and the repeated parts will not be described again.

[0170] like Figure 8 As shown, the electronic device includes a processor 800 and a memory 801. The memory 801 stores programs executable by the processor 800. The processor 800 reads the programs from the memory 801 and performs the following steps:

[0171] Collect hardware register data and BMC interface layer data of various components in the server system;

[0172] Establish a mapping relationship between the hardware register data and the BMC interface layer data;

[0173] The hardware register data and BMC interface layer data with mapping relationship are compared, and the cause of the anomaly is determined based on the comparison results.

[0174] As an optional implementation, the processor 800 is specifically configured to acquire hardware register data and BMC interface layer data of various components in the server system through any one or more of the following methods:

[0175] Hardware register data and BMC interface layer data are acquired in parallel through different processes, with one process acquiring hardware register data and another process acquiring BMC interface layer data; or,

[0176] Hardware register data for each component is acquired in parallel using multiple threads, with one thread dedicated to acquiring the hardware register data for one component; or,

[0177] The BMC interface layer data of each component is collected in parallel using multiple threads, with one thread used to collect the BMC interface layer data of one component.

[0178] As an optional implementation, after collecting hardware register data and BMC interface layer data from various components in the server system, the processor 800 is further configured to execute:

[0179] Determine if there is any abnormal data in the hardware register data or BMC interface layer data of each component;

[0180] In response to the presence of abnormal data in the hardware register data or the BMC interface layer data, the abnormal data is marked according to its type.

[0181] Write the marked hardware register data and BMC interface layer data to the log file.

[0182] As an optional implementation, the processor 800 is specifically configured to perform:

[0183] In response to an abnormal data condition in the hardware register being empty, the empty data is assigned a first fixed value; or,

[0184] In response to an error in the BMC interface layer data where the data is empty, the empty data is assigned a second fixed value; or,

[0185] In response to a negative value in the BMC interface layer data, the negative value is assigned a third fixed value; or,

[0186] In response to an abnormal data point in the BMC interface layer that is positive and exceeds a preset range, the positive value is assigned a fourth fixed value; or,

[0187] In response to an interface information error in the BMC interface layer, the BMC interface layer data is assigned the fifth fixed value.

[0188] As an optional implementation, the processor 800 is specifically configured to perform:

[0189] The hardware register data and BMC interface layer data of each component are time-aligned according to the order of the collected timestamps.

[0190] Based on the time-aligned hardware register data and BMC interface layer data, establish a mapping relationship between the hardware register data and BMC interface layer data of the same component collected at the same timestamp.

[0191] As an optional implementation, the processor 800 is specifically configured to perform:

[0192] Compare the hardware register data and BMC interface layer data of the same component collected at the same timestamp;

[0193] In response to the comparison result indicating abnormal data in the hardware registers, a hardware link failure is determined; or,

[0194] If the comparison result shows that the difference between the hardware register data with mapping relationship and the BMC interface layer data is higher than the threshold, it is determined that the BMC data processing is abnormal.

[0195] As an optional implementation, the processor 800 is further configured to perform:

[0196] At least one thread is used to perform login and logout tests on at least one interface of the BMC interface layer at a preset frequency, with one thread used to test the login and logout of one interface.

[0197] In response to a login or logout exception at at least one interface, obtain exception test data and mark the exception test data according to its type;

[0198] Write the abnormal test data of at least one marked interface to the log file, and determine that at least one interface of the BMC interface layer failed to respond.

[0199] As an optional implementation, the processor 800 is further configured to perform:

[0200] The collected hardware register data and BMC interface layer data of each component are written to a log file, with one log file corresponding to each component;

[0201] The log files of each component are converted into a chart with the acquisition time on the horizontal axis and the acquisition data on the vertical axis, and the chart is visualized. The acquisition data includes at least one of hardware register data, BMC interface layer data, and abnormal test data.

[0202] Based on the same inventive concept, this embodiment of the invention also provides an anomaly detection device. Since this device is the same as the device in the method of this embodiment of the invention, and the principle of the device in solving the problem is similar to that of the method, the implementation of the device can refer to the implementation of the method, and the repeated parts will not be described again.

[0203] like Figure 9 As shown, the device includes:

[0204] The data acquisition unit 900 is used to acquire hardware register data and BMC interface layer data of various components in the server system.

[0205] Data association unit 901 is used to establish the mapping relationship between the hardware register data and the BMC interface layer data;

[0206] The anomaly location unit 902 is used to compare the hardware register data and BMC interface layer data that have a mapping relationship, and determine the cause of the anomaly based on the comparison result.

[0207] As an optional implementation, the data acquisition unit 900 is used to acquire hardware register data and BMC interface layer data of various components in the server system through any one or more of the following methods:

[0208] Hardware register data and BMC interface layer data are acquired in parallel through different processes, with one process acquiring hardware register data and another process acquiring BMC interface layer data; or,

[0209] Hardware register data for each component is acquired in parallel using multiple threads, with one thread dedicated to acquiring the hardware register data for one component; or,

[0210] The BMC interface layer data of each component is collected in parallel using multiple threads, with one thread used to collect the BMC interface layer data of one component.

[0211] As an optional implementation, after collecting hardware register data and BMC interface layer data from various components in the server system, an exception handling unit is also included, specifically for:

[0212] Determine if there is any abnormal data in the hardware register data or BMC interface layer data of each component;

[0213] In response to the presence of abnormal data in the hardware register data or the BMC interface layer data, the abnormal data is marked according to its type.

[0214] Write the marked hardware register data and BMC interface layer data to the log file.

[0215] As an optional implementation, the exception handling unit is specifically used for:

[0216] In response to an abnormal data condition in the hardware register being empty, the empty data is assigned a first fixed value; or,

[0217] In response to an error in the BMC interface layer data where the data is empty, the empty data is assigned a second fixed value; or,

[0218] In response to a negative value in the BMC interface layer data, the negative value is assigned a third fixed value; or,

[0219] In response to an abnormal data point in the BMC interface layer that is positive and exceeds a preset range, the positive value is assigned a fourth fixed value; or,

[0220] In response to an interface information error in the BMC interface layer, the BMC interface layer data is assigned the fifth fixed value.

[0221] As an optional implementation, the data association unit 901 is specifically used for:

[0222] The hardware register data and BMC interface layer data of each component are time-aligned according to the order of the collected timestamps.

[0223] Based on the time-aligned hardware register data and BMC interface layer data, establish a mapping relationship between the hardware register data and BMC interface layer data of the same component collected at the same timestamp.

[0224] As an optional implementation, the anomaly location unit 902 is specifically used for:

[0225] Compare the hardware register data and BMC interface layer data of the same component collected at the same timestamp;

[0226] In response to the comparison result indicating abnormal data in the hardware registers, a hardware link failure is determined; or,

[0227] If the comparison result shows that the difference between the hardware register data with mapping relationship and the BMC interface layer data is higher than the threshold, it is determined that the BMC data processing is abnormal.

[0228] As an optional implementation, a test unit is also included, specifically for:

[0229] At least one thread is used to perform login and logout tests on at least one interface of the BMC interface layer at a preset frequency, with one thread used to test the login and logout of one interface.

[0230] In response to a login or logout exception at at least one interface, obtain exception test data and mark the exception test data according to its type;

[0231] Write the abnormal test data of at least one marked interface to the log file, and determine that at least one interface of the BMC interface layer failed to respond.

[0232] As an optional implementation, a visualization unit is also included, specifically for:

[0233] The collected hardware register data and BMC interface layer data of each component are written to a log file, with one log file corresponding to each component;

[0234] The log files of each component are converted into a chart with the acquisition time on the horizontal axis and the acquisition data on the vertical axis, and the chart is visualized. The acquisition data includes at least one of hardware register data, BMC interface layer data, and abnormal test data.

[0235] Based on the same inventive concept, this disclosure provides a computer storage medium comprising: computer program code, which, when executed on a computer, causes the computer to perform any of the anomaly detection methods described above. Since the principle by which the computer storage medium solves the problem is similar to that of the anomaly detection method, the implementation of the computer storage medium can be referred to the implementation of the method, and repeated details will not be elaborated further.

[0236] In specific implementation, computer storage media can include: Universal Serial Bus Flash Drive (USB), portable hard drive, Read-Only Memory (ROM), Random Access Memory (RAM), magnetic disk or optical disk, and other storage media that can store program code.

[0237] Based on the same inventive concept, this disclosure also provides a computer program product, which includes computer program code that, when executed on a computer, causes the computer to perform any of the anomaly detection methods discussed above. Since the principle by which the above-described computer program product solves the problem is similar to that of the anomaly detection method, the implementation of the above-described computer program product can be referred to the implementation of the method, and repeated details will not be elaborated further.

[0238] Computer program products may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples (a non-exhaustive list) of readable storage media include: electrical connections having one or more wires, portable disks, hard disks, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0239] Those skilled in the art will understand that embodiments of the present invention can be provided as methods, systems, or computer program products. Therefore, the present invention can take the form of a completely hardware embodiment, a completely software embodiment, or an embodiment combining software and hardware aspects. Furthermore, the present invention can take the form of a computer program product embodied on one or more computer-usable storage media (including, but not limited to, disk storage and optical storage) containing computer-usable program code.

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

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

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

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

Claims

1. An anomaly detection method characterized by, The method comprises: Collecting hardware register data and BMC interface layer data of each component in the server system; Establishing a mapping relationship between the hardware register data and the BMC interface layer data; Comparing the hardware register data and the BMC interface layer data with the mapping relationship, and determining the cause of the exception according to the comparison result.

2. The method of claim 1, wherein, The hardware register data and the BMC interface layer data of each component in the server system are collected in any one or more of the following ways: Collecting the hardware register data and the BMC interface layer data in parallel through different processes, one process being used to collect the hardware register data and the other process being used to collect the BMC interface layer data; or Collecting the hardware register data of each component in parallel through multiple threads, one thread being used to collect the hardware register data of one component; or Collecting the BMC interface layer data of each component in parallel through multiple threads, one thread being used to collect the BMC interface layer data of one component.

3. The method of claim 1, wherein, After collecting the hardware register data and the BMC interface layer data of each component in the server system, the method further comprises: Determining whether the hardware register data or the BMC interface layer data of each component has abnormal data; In response to the hardware register data or the BMC interface layer data having abnormal data, marking the abnormal data according to the type of the abnormal data; and Writing the marked hardware register data and the BMC interface layer data of each component into a log file.

4. The method of claim 3, wherein, The marking of the abnormal data according to the type of the abnormal data comprises: In response to the abnormal data of the hardware register data being empty data, assigning the empty data to a first fixed value; or In response to the abnormal data of the BMC interface layer data being empty data, assigning the empty data to a second fixed value; or In response to the abnormal data of the BMC interface layer data being negative, assigning the negative value to a third fixed value; or In response to the abnormal data of the BMC interface layer data being positive and exceeding a preset range, assigning the positive value to a fourth fixed value; or In response to the interface information of the BMC interface layer responding incorrectly, assigning the BMC interface layer data to a fifth fixed value.

5. The method of claim 1, wherein, The establishment of the mapping relationship between the hardware register data and the BMC interface layer data comprises: Aligning the hardware register data and the BMC interface layer data of each component in time sequence according to the order of the collected time stamps; and According to the hardware register data and the BMC interface layer data after the time sequence alignment, establishing a mapping relationship between the hardware register data and the BMC interface layer data of the same component collected at the same time stamp.

6. The method of claim 1, wherein, The comparison of the hardware register data and the BMC interface layer data with the mapping relationship, and the determination of the cause of the exception according to the comparison result, comprises: Comparing the hardware register data and the BMC interface layer data of the same component collected at the same time stamp; and In response to the comparison result being that the hardware register data has abnormal data, determining that the hardware link is invalid; or In response to the comparison result being that the difference between the hardware register data and the BMC interface layer data with the mapping relationship is higher than a threshold value, determining that the BMC data processing is abnormal.

7. The method of claim 1, wherein, The method further comprises: The login and logout of at least one interface of the BMC interface layer are tested at a preset frequency by at least one thread, and one thread is used to test the login and logout of one interface; In response to login or logout exception of at least one interface, abnormal test data is acquired, and the abnormal test data is marked according to a type of the abnormal test data; The marked abnormal test data of at least one interface is written into a log file, and it is determined that at least one interface of the BMC interface layer fails to respond.

8. The method according to any one of claims 1 to 7, characterized in that, The method further comprises: The collected hardware register data and BMC interface layer data of each component are written into a log file, and one component corresponds to one log file; The log files of each component are converted into a chart with collection time as the horizontal coordinate and collection data as the vertical coordinate, and the chart is visually displayed, wherein the collection data comprises at least one of the hardware register data, the BMC interface layer data and the abnormal test data.

9. An electronic device, comprising: The electronic device comprises a processor and a memory, the memory is used to store a program executable by the processor, and the processor is used to read the program in the memory and execute the steps of any one of claims 1-8.

10. A computer storage medium having stored thereon a computer program, characterized in that The program is executed by the processor to implement the steps of any one of claims 1-8.

Images