Server hardware testing methods and electronic equipment

Abstract

This application provides a server hardware detection method and electronic device, which can be applied in the field of server technology. The method includes: acquiring status data of each hardware component in a server; performing fault diagnosis on the status data of each hardware component to obtain a fault diagnosis result; responding to the fault diagnosis result indicating the presence of abnormal status data in the multiple status data of the multiple hardware components, determining the timestamp of the abnormal status data as a target time, wherein the timestamp indicates the generation time of the status data; determining the query value for each status data component based on the target time and the timestamps of the multiple status data components; and querying a preset rule based on the query value of each status data component to obtain the server's hardware fault type. This application solves the problem of low accuracy in server hardware detection methods in related technologies.

Description

Technical Field

[0001] This application relates to the field of server technology, specifically to a server hardware testing method and electronic device. Background Technology

[0002] In some examples, when server hardware malfunctions, the fault is determined solely by comparing the server's status data with preset thresholds. However, due to factors such as temperature and electromagnetic interference, this can easily lead to false positives or false negatives, resulting in low accuracy in server hardware fault detection. Summary of the Invention

[0003] This application provides a server hardware testing method and electronic device, which can at least solve the problem of low accuracy of test results in related server hardware testing methods.

[0004] According to one aspect of the embodiments of this application, a server hardware detection method is provided, comprising: acquiring status data of each hardware component among multiple hardware components of a server; performing fault diagnosis on the status data of each hardware component to obtain a fault diagnosis result; in response to the fault diagnosis result indicating the presence of abnormal status data among the multiple status data of the multiple hardware components, determining the timestamp of the abnormal status data as a target time, wherein the timestamp indicates the generation time of the status data; determining the query value of each status data component among the multiple status data based on the target time and the timestamps of the multiple status data; and querying a preset rule based on the query value of each status data component to obtain the hardware fault type of the server, wherein the preset rule represents the mapping relationship between the multiple status data components and the hardware fault type.

[0005] According to another aspect of the embodiments of this application, an electronic device is provided, comprising: one or more processors; and a memory for storing one or more computer programs, wherein the one or more processors execute the one or more computer programs to implement the steps of the method described above.

[0006] In this embodiment, the status data of each hardware component in a server is acquired, and fault diagnosis is performed on the status data of each hardware component to obtain fault diagnosis results. By performing fault diagnosis on the status data of each hardware component separately, the detection results of each hardware component can be obtained, and the possible faults of each hardware component can be determined. If the fault diagnosis results indicate that there is no abnormal status data, subsequent comprehensive judgment and analysis of the status data of all hardware components is not performed, which can save the computing power consumption of the server. To eliminate the possibility of fault diagnosis errors, in response to the fault diagnosis results indicating that there is abnormal status data in the multiple status data of multiple hardware components, the timestamp of the abnormal status data is determined as the target time. Based on the target time and the timestamps of multiple status data, the query value of each status data component is determined. Based on the query value of each status data component, a preset rule is queried to obtain the hardware fault type of the server. By combining and analyzing the status data of each hardware component, and judging the hardware fault type of the server based on the status data of multiple hardware components according to the preset rule, the occurrence of false alarms can be effectively avoided, and the accuracy of the server's hardware fault detection results can be improved. Attached Figure Description

[0007] The above-mentioned contents, other objects, features and advantages of this application will become clearer from the following description of embodiments with reference to the accompanying drawings, in which:

[0008] Figure 1 The illustration shows a schematic diagram of the hardware environment of a server hardware detection method according to an embodiment of this application.

[0009] Figure 2 A flowchart illustrating a server hardware detection method according to an embodiment of this application is shown.

[0010] Figure 3 A schematic diagram illustrating various state data according to embodiments of this application is shown.

[0011] Figure 4 A schematic diagram illustrating various state data according to another embodiment of this application is shown.

[0012] Figure 5 A schematic diagram illustrating various state data according to yet another embodiment of this application is shown.

[0013] Figure 6 A schematic diagram illustrating various state data according to yet another embodiment of this application is shown.

[0014] Figure 7 A schematic block diagram of a computer system for an electronic device according to an embodiment of this application is shown. Detailed Implementation

[0015] To enable those skilled in the art to better understand the present application, the technical solutions in the embodiments of the present application will be clearly and completely described below with reference to the accompanying drawings. Obviously, the described embodiments are only some embodiments of the present application, and not all embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative effort should fall within the scope of protection of the present application.

[0016] It should be noted that the terms "first," "second," etc., in the specification, claims, and accompanying drawings of this application are used to distinguish similar objects and are not necessarily used to describe a specific order or sequence. It should be understood that such data can be interchanged where appropriate so that the embodiments of this application described herein can be implemented in orders other than those illustrated or described herein. Furthermore, the terms "comprising" and "having," and any variations thereof, are intended to cover non-exclusive inclusion; for example, a process, method, system, product, or apparatus that comprises a series of steps or units is not necessarily limited to those steps or units explicitly listed, but may include other steps or units not explicitly listed or inherent to such processes, methods, products, or apparatus.

[0017] The methods and embodiments provided in this application can be executed on a server, mobile terminal, computer terminal, or similar computing device. Taking running on a server as an example, Figure 1 This diagram schematically illustrates the hardware environment of a server hardware detection method according to an embodiment of this application. Figure 1 As shown, a server may include one or more ( Figure 1 Only one is shown in the image. A processor 102 (which may include, but is not limited to, a microprocessor or programmable logic device) and a memory 104 for storing data are also shown. The server may further include a transmission device 106 for communication functions and an input / output device 108. Those skilled in the art will understand that... Figure 1 The structure shown is for illustrative purposes only and does not limit the structure of the server described above. For example, the server may also include components that are more complex than... Figure 1 The more or fewer components shown, or having the same Figure 1 The different configurations shown.

[0018] The memory 104 can be used to store computer programs, such as application software programs and modules, like the computer program corresponding to the server hardware detection method in this embodiment. The processor 102 executes various functional applications and data processing by running the computer program stored in the memory 104, thus implementing the above-described method. The memory 104 may include high-speed random access memory and non-volatile memory, such as one or more magnetic storage devices, flash memory, or other non-volatile solid-state memory. In some instances, the memory 104 may further include memory remotely located relative to the processor 102, and these remote memories can be connected to the mobile terminal via a network. Examples of such networks include, but are not limited to, the Internet, corporate intranets, local area networks, mobile communication networks, and combinations thereof.

[0019] The transmission device 106 is used to receive or send data via a network. Specific examples of the network described above may include a wireless network provided by a communication provider for the computer terminal. In one example, the transmission device 106 includes a Network Interface Controller (NIC), which can connect to other network devices via a base station to communicate with the Internet. In another example, the transmission device 106 may be a Radio Frequency (RF) module used for wireless communication with the Internet.

[0020] Optionally, the server hardware detection method in this embodiment can be executed by the server. Here, "server" refers to the entire server, including the relevant components within the server that need to execute the server hardware detection method, as well as the processor, etc. The server hardware detection method in this embodiment can also be executed by the processor 102. In some examples of this embodiment, the server hardware detection method is described using the example of execution by the server.

[0021] In some examples, when server hardware malfunctions, the fault is determined solely by comparing the server's status data with preset thresholds. For instance, when a server experiences faults such as abnormal power supply voltage, hard drive overheating, or memory errors, the technology may conclude that the power supply, hard drive, and memory are all faulty based solely on the status data of each component. However, due to factors such as temperature and electromagnetic interference, the actual situation might be that a power supply failure is causing the abnormal power supply voltage, hard drive overheating, and memory errors.

[0022] It is evident that server hardware detection methods in related technologies are prone to misjudgment or omission, resulting in low accuracy of server hardware fault detection results.

[0023] To address the aforementioned issues, this application provides a server hardware detection method.

[0024] Figure 2 A flowchart illustrating a server hardware detection method according to an embodiment of this application is shown.

[0025] like Figure 2 As shown, the server hardware detection method of this embodiment includes operations S210 to S250.

[0026] The S210 is used to obtain the status data of each hardware component in the server's multiple hardware components.

[0027] In this embodiment of the application, the server includes multiple hardware components.

[0028] For example, multiple hardware components may include power supply, memory, hard drive, and network card.

[0029] In the embodiments of this application, each piece of hardware includes at least one type of status data. The status data can reflect the operating status of the hardware.

[0030] For example, power supply status data may include output voltage, which can be obtained by connecting a voltage sensor to the power supply output terminal. Power supply status data may also include output current, which can be obtained by connecting a current sensor to the power supply output terminal. Finally, power supply status data may include temperature, which can be obtained by deploying a thermistor or temperature sensor near the heatsink inside the power supply.

[0031] For example, network interface card (NIC) status data can include packet loss rate, which can be calculated using network testing tools. NIC status data can also include power consumption, which can be monitored using the motherboard's power management chip.

[0032] In this embodiment, various types of sensors can be deployed to acquire status data for different hardware characteristics. For example, in a power supply, voltage / current sensors are used to collect electrical parameters, and thermistors are used to detect temperature. In a hard drive, accelerometers are used to detect hard drive vibration, and temperature sensors are used to detect hard drive temperature. In memory, temperature sensors are deployed at the memory heatsink to detect memory temperature. By deploying multiple types of sensors, real-time sensing of key physical quantities of the hardware can be achieved, providing a data foundation for subsequent detection.

[0033] By operating S220, fault diagnosis is performed on the status data of each hardware component to obtain the fault diagnosis results.

[0034] In this embodiment, fault diagnosis is performed on the status data of each hardware component to obtain fault diagnosis results for each component. The fault diagnosis results indicate whether there are any abnormalities in the status data.

[0035] In this embodiment, various status data can be assigned corresponding normal threshold ranges. The fault diagnosis result is determined by judging whether the status data falls within the normal threshold range. When the status data is within the normal threshold range, it indicates that the status data is normal. When the status data is outside the normal threshold range, it indicates that the status data is abnormal.

[0036] For example, let's take a power supply as an example. The normal threshold range for power supply voltage is 10V-20V. When the power supply voltage is 15V, it indicates that the power supply voltage is normal. When the power supply voltage is 7V, it indicates that the power supply voltage is abnormal.

[0037] In this embodiment of the application, various status data can be provided with corresponding judgment conditions. By judging whether the status data meets the corresponding judgment conditions, the fault diagnosis result can be determined.

[0038] For example, let's take a network card as an example. The signal quality of the network card is tested by reading the error frame count using a network card management tool. If the error frame count exceeds a preset value, it indicates low signal quality.

[0039] In operation S230, in response to the presence of abnormal state data among multiple state data representing multiple hardware components in the fault diagnosis result, the timestamp of the abnormal state data is determined as the target time, where the timestamp indicates the time when the state data was generated.

[0040] In this embodiment, operation S220 can determine whether any status data is abnormal. If abnormal status data exists among the multiple status data representing multiple hardware components in the fault diagnosis result, the timestamp of the abnormal status data is determined as the target time.

[0041] In this embodiment, the status data of each hardware component may include data detected within a target time period. Abnormal status data may be detected at a specific moment within the target time period, and that moment can be designated as the target moment. Abnormal status data may be distributed across multiple moments within the target time period; in this case, the moment of the first detected abnormal status data can be designated as the target moment.

[0042] For example, the power supply voltage is checked once per second over one hour. If an abnormality in the power supply voltage is detected at 20 minutes and 10 seconds, then 20 minutes and 10 seconds can be designated as the target time. If a continuous abnormality in the power supply voltage is detected between 30 minutes and 15 seconds and 30 minutes and 32 seconds, then 30 minutes and 15 seconds can be designated as the target time.

[0043] In operation S240, the query value of each state data in the multiple state data is determined based on the target time and the timestamps of multiple state data.

[0044] In this embodiment, the query value for each state data represents the value of each state data at the corresponding timestamp. For example, when the state data is the voltage data of the power supply, the query value is the voltage value. When the state data is the power consumption data of the network card, the query value is the power consumption value.

[0045] In this embodiment, each state data includes the state data of its corresponding hardware during a target time period. During the target time period, each hardware component is tested multiple times; therefore, each state data includes multiple values ​​obtained from these tests within the target time period.

[0046] In this embodiment, the query value for each state data point is determined based on the target time and the timestamps of multiple state data points. Since the target time is the timestamp of the abnormal state data, the query value for each state data point can be determined by selecting the state data generated at a time close to the target time based on the timestamps of each state data point, and then using the value of the selected state data as the query value. For example, the value of the state data corresponding to the timestamp adjacent to the target time can be selected as the query value for that state data.

[0047] For example, each status data point represents the status data generated by the corresponding hardware between 9:00 and 10:00. When the target time is 9:23:10, the value of the status data corresponding to the timestamp adjacent to 9:23:10 can be selected as the query value for that status data. The power supply voltage data has a timestamp adjacent to the target time of 9:23:09, so the voltage value at 9:23:09 is determined as the query value for that voltage data. Similarly, the network card power consumption data has a timestamp adjacent to the target time of 9:23:12, so the power consumption value at 9:23:12 is determined as the query value for that power consumption data.

[0048] In the embodiments of this application, each state data can select at least one query value, and each query value represents the value of the state data at a certain moment.

[0049] For example, each status data point represents the status data generated by the corresponding hardware between 9:00 and 10:00. When the target time is 9:23:10, two timestamps adjacent to the target time in the power supply voltage data can be selected, such as 9:23:09 and 9:23:11, and the voltage values ​​at these two timestamps can be determined as the query values ​​for the voltage data.

[0050] In operation S250, based on the query value of each status data, a preset rule is queried to obtain the hardware fault type of the server. The preset rule represents the mapping relationship between multiple status data and hardware fault types.

[0051] In this embodiment, preset rules characterize the mapping relationship between multiple state data and hardware fault types. Preset rules characterize the mapping relationship between each state data point under different conditions and the hardware fault type. Each rule in the preset rules includes a mapping relationship between a hardware fault type and each state data point. When the query value of each state data point meets the preset condition of a certain rule in the preset rules, the hardware fault type corresponding to that rule is determined as the hardware fault type of the server. The preset conditions for each state data point in the preset rules can be a limitation on the range of the query value of the state data point.

[0052] For example, a server includes a power supply, a hard drive, and memory. When the query value of the power supply voltage data is lower than a first threshold (e.g., 11.4V), the query value of the hard drive temperature data is higher than a second threshold (e.g., 50℃), and the memory error count data exceeds a third threshold, if the above conditions meet the conditions of the first rule in the preset rules, and the hardware fault type corresponding to the first rule is a power supply fault, then the hardware fault type of the server is determined to be a power supply fault.

[0053] In this embodiment, operations S210 and S220 can be executed by a local edge node of the server. The local edge node can be a controller for various hardware accessories within the server; for example, it can be a baseboard management controller. Operations S230 to S250 can also be executed by the server's processor. The local edge node processes status data in real time to obtain fault diagnosis results. When abnormal status data is detected, it sends the status data to the processor for further detection. The local edge node can process high-frequency status data (such as power supply voltage sampled 10 times per second), avoiding the processor processing large amounts of high-frequency status data and thus improving processor efficiency.

[0054] Through the embodiments of this application, fault diagnosis is performed on the status data of each hardware component individually to obtain the detection results of each hardware component, thereby determining the possible faults currently existing in each hardware component. When the fault diagnosis results indicate abnormal status data, the status data of each hardware component is combined and analyzed. By combining the status data of multiple hardware components and determining the type of hardware fault in the server according to preset rules, false alarms can be effectively avoided, improving the accuracy of the server's hardware fault detection results.

[0055] The following section details the specific process of determining the query value for each state data based on the target time and the timestamps of multiple state data.

[0056] In some embodiments, determining the query value of each state data among multiple state data based on the target time and the timestamp of the state data includes: determining the value corresponding to each state data at the target time as the query value of each state data based on the target time and the timestamp of the state data, wherein the timestamp of the query value of each state data is the target time or is located before the target time.

[0057] Figure 3 A schematic diagram illustrating various state data according to embodiments of this application is shown.

[0058] like Figure 3 As shown, Figure 3 The illustration schematically shows the process of determining the query value for state data 1, state data 2, state data 3, and state data 4. Each state data includes multiple timestamps, and a new value is generated for each state data at each timestamp.

[0059] State data 1 generated four values ​​at times 1, 2, 3, and 4. For example, when state data 1 is the voltage data of the power supply, the voltage of the power supply was detected four times at times 1, 2, 3, and 4, resulting in four voltage values. Similar to state data 1, state data 2, state data 3, and state data 4 generated new values ​​at their respective timestamps.

[0060] In this embodiment of the application, based on the target time and the timestamp of the state data, the value corresponding to each state data at the target time is determined as the query value for each state data. For example... Figure 3 As shown, time 2 is used as the target time for illustration.

[0061] The value corresponding to each state data at time 2 is determined as the query value for each state data. For state data whose generation time is not at time 2, the timestamp of the state data before time 2 and adjacent to time 2 can be determined as the timestamp corresponding to the query value.

[0062] For example, such as Figure 3 As shown, the query value for state data 1 is the query value 1 generated at time 2; the query value for state data 2 is the query value 1 generated at a timestamp before and adjacent to time 2; the query value for state data 3 is the query value 3 generated at a timestamp before and adjacent to time 2; and the query value for state data 4 is the query value 4 generated at a timestamp before and adjacent to time 2.

[0063] In this embodiment, the value corresponding to each state data at the target time is determined as the query value of each state data. The obtained query value can reflect the state of the hardware corresponding to each state data at the target time. By performing subsequent query operations using the obtained query value, the accuracy of subsequent detection steps can be effectively improved, thereby improving the accuracy and reliability of the hardware detection method of this embodiment.

[0064] The foregoing embodiments describe a specific process for determining the query value of each state data. The following will detail another specific process for determining the query value of each state data based on a target time and the timestamps of multiple state data.

[0065] In some embodiments, determining the query value for each state data in a plurality of state data based on the target time and the timestamp of the state data includes: determining a target state dataset whose timestamp is located within a target time window from the plurality of state data, wherein the target time is located within the target time window; and determining the value corresponding to at least one time within the target time window for each state data in the target state dataset as the query value for each state data.

[0066] Figure 4 A schematic diagram illustrating various state data according to another embodiment of this application is shown.

[0067] like Figure 4 As shown, Figure 4 The illustration schematically depicts the process of determining the query value for state data 1, state data 2, state data 3, and state data 4. Each state data includes multiple timestamps, and a new value is generated for each state data at each timestamp.

[0068] State data 1 generated four values ​​at times 1, 2, 3, and 4. For example, when state data 1 is the voltage data of the power supply, the voltage of the power supply was detected four times at times 1, 2, 3, and 4, resulting in four voltage values. Similar to state data 1, state data 2, state data 3, and state data 4 generated new values ​​at their respective timestamps.

[0069] In this embodiment, the target time is located within a target time window. The target time window can be obtained by adding a certain amount of time forward and backward, respectively. For example... Figure 4 As shown, time 2 (target time) is within the target time window.

[0070] In this embodiment of the application, a target state dataset whose timestamp is located within the target time window is determined from multiple state data based on the target time and the timestamp of the state data.

[0071] For example, such as Figure 4 As shown, all values ​​of state data 1, state data 2, state data 3, and state data 4 within the target time window are defined as the target state dataset. For state data 1, the value of state data 1 at time 1 and time 2 is part of the target state dataset. Although the target time window does not include time 1, it includes a portion of the time interval between time 1 and time 2; the value of state data 1 in the intermediate period between time 1 and time 2 is the value of state data 1 at time 1.

[0072] In this embodiment, the value corresponding to each state data in the target state dataset at at least one moment within the target time window is determined as the query value for each state data. At least one moment within the target time window can be selected, and the value corresponding to each state data at that moment can be determined as the query value for each state data at that moment. Therefore, each moment corresponds to a set of query values, and each set of query values ​​includes one query value from each state data. If three moments within the target time window are selected, three sets of query values ​​can be obtained.

[0073] In some examples of this application's embodiments, fluctuations in hardware data or sensor detection processes may cause fluctuations in hardware state data. The query data for each state data point determined solely by a target time may not accurately reflect the true state of each hardware component. In this embodiment, the selection range of the query value is defined as a target time window, increasing the selection range for each state data point. By determining the query value for each state data point at least once within the target time window, the obtained query values ​​for each state data point can more accurately reflect the true state of each hardware component. This effectively improves the accuracy of subsequent detection steps, thereby enhancing the accuracy and reliability of the hardware detection method in this embodiment.

[0074] The foregoing embodiments described two specific methods for determining the query values ​​of each status data. The following will detail a specific method for obtaining the server's hardware fault type by querying preset rules based on the query values ​​of each status data. See the embodiments below for details.

[0075] In some embodiments, the hardware fault type of the server is obtained by querying a preset rule based on the query value of each state data, including: if the query value of each state data satisfies the threshold range indicated by the target rule in the preset rule, the hardware fault type corresponding to the target rule is determined as the hardware fault type of the server. The target rule includes the threshold range corresponding to each state data and the hardware fault type corresponding to multiple state data.

[0076] In this embodiment of the application, when the query value of each state data meets the threshold range indicated by the target rule in the preset rules, the hardware fault type corresponding to the target rule is determined as the hardware fault type of the server.

[0077] Figure 5 A schematic diagram illustrating various state data according to yet another embodiment of this application is shown.

[0078] like Figure 5 As shown, Figure 5 The illustration shows the range limitations of the target rule for state data 1, state data 2, state data 3, and state data 4. When the query value of state data 1 falls within the target range b1, the query value of state data 2 falls within the target range b2, the query value of state data 3 falls within the target range b3, and the query value of state data 4 falls within the target range b4, it is determined that the query value of each state data satisfies the threshold range indicated by the target rule in the preset rule, and the hardware fault type corresponding to the target rule is determined as the hardware fault type of the server.

[0079] It should be noted that the target range can be either the normal range of values ​​for the state data or the abnormal range of values ​​for the state data. For example, ... Figure 5 As shown, the target ranges for state data 1, state data 2, and state data 3 are the abnormal value ranges for the corresponding state data, while the target range for state data 4 is the normal value range.

[0080] For example, if state data 1 is the voltage data of the power supply, and its normal range is 10V-20V, then the normal range a1 is 10V-20V, and the target range b1 of the target rule is less than 10V. Similarly, normal range a2 represents the normal value range of state data 2, normal range a3 represents the normal value range of state data 3, and normal range a4 represents the normal value range of state data 4.

[0081] In this embodiment, each rule in the preset rules includes a threshold range corresponding to each state data point, and a hardware fault type corresponding to multiple state data points. That is, each rule corresponds to a hardware fault type. When the query value of each state data point meets the threshold requirement of each rule, the hardware fault type of the server can be determined to be the hardware fault type corresponding to that rule.

[0082] Through the embodiments of this application, the type of hardware failure of the server can be accurately determined based on the query value of each status data and preset rules, thereby improving the accuracy and reliability of the server hardware detection method of this embodiment.

[0083] The foregoing embodiments described the specific steps for determining the hardware fault type of the server based on the query values ​​of each status data and preset rules. The following will explain the specific steps for determining the hardware fault type of the server when the query values ​​of each status data do not meet the target rules.

[0084] In some embodiments, the method further includes: determining the hardware fault type of the server based on the fault diagnosis results when the query value of each state data does not meet the threshold range indicated by the target rule.

[0085] In this embodiment, if the query value of each state data does not meet the threshold range indicated by the target rule, it indicates that the hardware fault type of the server cannot be determined by combining the various state data. Since the fault diagnosis result represents the presence of abnormal state data among multiple state data, the hardware fault type of the server can be determined based on the fault diagnosis result.

[0086] For example, when the fault diagnosis results indicate that the power supply voltage data is abnormal, it can be determined that the server's power supply is faulty.

[0087] Through the embodiments of this application, when the hardware fault type of the server cannot be determined by querying the preset rules based on the query values ​​of each status data, the hardware fault type of the server can be determined based on the fault diagnosis results, which can improve the reliability of the server hardware detection method of this embodiment.

[0088] The above embodiments illustrate the specific steps for determining the hardware fault type of the server based on the query values ​​of various status data. The method for determining the preset rules will be described below. See the following embodiments for specific steps.

[0089] In some embodiments, the method further includes: acquiring a historical fault dataset of the server, wherein the historical fault dataset includes multiple historical state data of multiple hardware components when the server experienced a hardware failure during a historical period; determining at least one historical abnormal state data corresponding to any hardware failure based on the historical fault dataset, wherein the historical abnormal state data is the state data that is abnormal among the multiple state data when the server experienced any hardware failure; and constructing a preset rule based on any hardware failure and at least one historical abnormal state data.

[0090] In this embodiment of the application, the historical fault dataset includes historical state data of multiple hardware components when the server experienced a hardware failure during a historical period. That is, when the server experienced a hardware failure during a historical period, the historical state data of each hardware component of the server is recorded, and the recorded historical state data of each hardware component is bound to the hardware failure of the server to obtain the historical fault dataset.

[0091] In this embodiment of the application, at least one historical abnormal state data corresponding to any hardware failure is determined based on the historical failure dataset. When a hardware failure occurs in the server, abnormal state data will appear in the status data of each hardware component. Therefore, for each hardware failure in the historical failure dataset, at least one historical abnormal state data corresponding to each hardware failure is determined.

[0092] In this embodiment, a preset rule is constructed based on any hardware fault and at least one historical abnormal state data. The mapping relationship between any hardware fault and at least one historical abnormal state data is constructed as a rule in the preset rule.

[0093] For example, regarding a server power failure, historical fault data can be used to determine the corresponding historical fault status data. This historical fault dataset includes two power failures. In one power failure, the status data showed abnormal voltage data and hard drive overheating. The mapping relationship between these abnormal voltage data, hard drive overheating, and the power failure can be constructed as a rule in a preset set of rules. In the other power failure, the status data showed abnormal voltage data, hard drive overheating, and memory data. The mapping relationship between these abnormal voltage data, hard drive overheating, and memory data can also be constructed as a rule in a preset set of rules.

[0094] Through the embodiments of this application, preset rules can be accurately constructed based on historical fault datasets, thereby improving the reliability of the server hardware detection method of this embodiment.

[0095] The above embodiments illustrate a method for constructing preset rules based on historical fault datasets. The following will describe in further detail how to construct preset rules based on any hardware fault and at least one historical abnormal state data. Specific steps are detailed in the following embodiments.

[0096] In some embodiments, constructing a preset rule based on any hardware failure and at least one historical abnormal state data includes: determining, based on a historical failure dataset, the number of times each historical abnormal state data occurs when the server experiences any hardware failure during a historical period; determining the probability value of each historical abnormal state data based on the total number of times the server experiences any hardware failure during the historical period and the number of times each historical abnormal state data occurs; determining the probability value of each combination of historical abnormal state data based on the probability values ​​of each historical abnormal state data, wherein each combination of historical abnormal state data includes at least one historical abnormal state data, and different combinations of historical abnormal state data include different types of historical abnormal state data; and adding the mapping relationship between any historical abnormal state data combination and any hardware failure to the preset rule in response to the probability value of any historical abnormal state data combination exceeding a preset threshold.

[0097] In this embodiment, based on the historical fault dataset, the number of times each historical abnormal state data occurred when the server experienced any hardware failure during a historical period is determined. Based on the total number of times the server experienced any hardware failure during the historical period and the number of times each historical abnormal state data occurred, the probability value of each historical abnormal state data is determined.

[0098] For example, a server experienced 10 power failures during a historical period. The historical abnormal status data includes voltage data, memory temperature data, and hard drive temperature data. Of these 10 power failures, there were 10 instances of abnormal voltage data, 8 instances of abnormal memory temperature data, and 9 instances of abnormal hard drive temperature data. Therefore, the probability value for the voltage data is 100%, the probability value for the memory temperature data is 80%, and the probability value for the hard drive temperature data is 90%.

[0099] In this embodiment, the probability value of each combination of historical abnormal state data is determined based on the probability values ​​of each individual historical abnormal state data. The probability value of each combination of historical abnormal state data can be obtained by multiplying the probability values ​​of the historical abnormal state data included in each combination.

[0100] For example, voltage data has a probability of 100%, memory temperature data has a probability of 80%, and hard drive temperature data has a probability of 90%. When the historical abnormal state data combination includes voltage data and memory temperature data, the probability of this historical abnormal state data combination is 100% × 80% = 80%. When the historical abnormal state data combination includes voltage data, memory temperature data, and hard drive temperature data, the probability of this historical abnormal state data combination is 100% × 80% × 90% = 72%.

[0101] In this embodiment of the application, in response to the probability value of any combination of historical abnormal state data exceeding a preset threshold, the mapping relationship between any combination of historical abnormal state data and any hardware fault is added to a preset rule.

[0102] For example, if the preset threshold is 75%, when the probability value of a combination of historical abnormal state data exceeds 75%, the mapping relationship between the combination of historical abnormal state data and the corresponding hardware fault can be added to the preset rules.

[0103] For example, a combination of historical abnormal state data includes voltage data and memory temperature data, and the probability value of this combination is 100% × 80% = 80%. Therefore, one of the preset rules can be determined as follows: the hardware fault type is power supply abnormality, and the corresponding abnormal state data are abnormal voltage data and abnormal memory temperature data, while other state data are normal.

[0104] By constructing preset rules based on the probability values ​​of various combinations of historical abnormal state data through the embodiments of this application, the accuracy of the constructed preset rules can be further improved, thereby improving the reliability of the server hardware detection method of this embodiment.

[0105] In some embodiments, a fault propagation chain can be established by dissecting the hardware failure mechanism. For example, when the hardware failure type is abnormal power supply voltage, it will directly affect memory voltage fluctuations. At the same time, abnormal power supply voltage will lead to unstable hard drive power supply, which will in turn cause an increase in hard drive bad sectors and cause memory data read / write errors. Therefore, abnormal power supply will be accompanied by concurrent problems with hard drive and memory. At least one historical abnormal state data corresponding to abnormal power supply voltage may include low power supply voltage, hard drive overheating, and memory errors.

[0106] In this embodiment, after initially determining at least one historical abnormal state data corresponding to the hardware fault type, the data can be verified using a historical fault dataset. Specific verification steps can be found in the embodiments described above.

[0107] In this embodiment of the application, threshold boundaries for each historical abnormal state data can be determined through threshold quantization experiments and destructive testing.

[0108] For example, to test the power supply voltage threshold, hardware behavior can be observed by stepping down the voltage in the range of 11.0V to 12.6V. When the power supply voltage is 11.4V, the hard drive experiences read / write errors (i.e., the critical point is 11.4V). When the power supply voltage is 11.0V, the server crashes. A threshold of 11.4V can be set for the power supply voltage to be too low; when the power supply voltage drops below 11.4V, it is determined that the power supply voltage is too low, and there may be an anomaly in the power supply voltage.

[0109] The above embodiments illustrate the process of constructing preset rules. After performing fault diagnosis on the status data of each hardware component and obtaining the fault diagnosis results, the hardware faults corresponding to the fault diagnosis results can be processed immediately to avoid affecting the stability of the server. Specific steps are described in the following embodiments.

[0110] In some embodiments, the method further includes: in response to the presence of abnormal state data in multiple state data representing multiple hardware components according to a fault diagnosis result, determining faulty hardware and fault handling operations based on the fault diagnosis result; and invoking the faulty hardware to perform the fault handling operation.

[0111] In this embodiment of the application, in response to the presence of abnormal state data among the multiple state data of multiple hardware components represented by the fault diagnosis result, the faulty hardware corresponding to the abnormal state data can be determined based on the fault diagnosis result, and the corresponding fault handling operation can be determined.

[0112] For example, if abnormal power supply voltage data is detected, the power supply can be identified as faulty hardware. When the power supply voltage drops by more than 10%, the fault handling procedure can be determined to be to activate the backup power supply. If a hard drive abnormality is detected, data backup can be initiated when the number of bad sectors on the hard drive exceeds 0.

[0113] Through the embodiments of this application, after obtaining the fault diagnosis result, the corresponding fault handling operation can be performed immediately on the hardware fault corresponding to the fault diagnosis result to avoid affecting the stability of the server, thereby improving the reliability of the server hardware detection method of this embodiment.

[0114] The following section details the specific process of diagnosing faults based on the status data of each hardware component to obtain the fault diagnosis results.

[0115] In some embodiments, fault diagnosis is performed on the status data of each piece of hardware to obtain fault diagnosis results, including: when multiple hardware components include a power supply, fault diagnosis is performed on at least one of the power supply's voltage data, temperature data, capacitance data, power data, and voltage ripple to obtain a power supply fault diagnosis result. When multiple hardware components include a hard disk drive (HDD), fault diagnosis is performed on at least one of the HDD's vibration data, temperature data, hard disk capacity data, and hard disk data integrity to obtain an HDD fault diagnosis result. When multiple hardware components include a solid-state drive (SSD), fault diagnosis is performed on at least one of the SSD's chip temperature data, read / write speed data, hard disk capacity data, and hard disk data integrity to obtain an SSD fault diagnosis result. When multiple hardware components include memory, fault diagnosis is performed on at least one of the memory's voltage data, clock signal data, and temperature data to obtain a memory fault diagnosis result. When multiple hardware components include a network interface card (NIC), fault diagnosis is performed on at least one of the NIC's physical link status data, packet loss rate data, temperature data, and power consumption data to obtain a NIC fault diagnosis result.

[0116] Figure 6 A schematic diagram illustrating various state data according to yet another embodiment of this application is shown.

[0117] like Figure 6 As shown, each hardware component can include multiple status data. For example, hardware 1 can be a power supply; status data 1 of hardware 1 can be the power supply's voltage data, status data 2 can be the power supply's temperature data, and status data 3 can be the power supply's capacitor data. Hardware 2 can be memory; status data 4 of hardware 2 can be the memory's voltage data, and status data 5 can be the memory's temperature data. Hardware 3 can be a network interface card (NIC); status data 6 of hardware 3 can be the NIC's packet loss rate data, status data 7 can be the NIC's temperature data, and status data 8 can be the NIC's power consumption data.

[0118] exist Figure 6 In this context, the timestamp indicates the time when the status data was generated. Taking status data 1 as an example, status data 1 can be the voltage data of the power supply. The voltage values ​​detected by the power supply at time 1, time 2, time 3, and time 4 constitute status data 1.

[0119] In the embodiments of this application, when multiple hardware components include a power supply, fault diagnosis is performed on at least one of the power supply's voltage data, temperature data, capacitance data, power data, and voltage ripple to obtain the power supply's fault diagnosis result.

[0120] In this embodiment, the power supply converts AC to DC to power the device. The core parameters include output voltage, current, power, temperature and capacitor status. Faults often manifest as voltage fluctuations, overheating or power outages.

[0121] For example, the status data of the power supply can be monitored using the following methods.

[0122] Electrical parameter monitoring involves connecting a voltage / current sensor to the power output terminal to collect output voltage values ​​such as +12V, +5V, and +3.3V in real time. The values ​​are compared with the preset error range of the standard threshold (such as ±5% fluctuation range). An alarm is triggered when an abnormality occurs (such as a sudden voltage drop of more than 10%, which may cause a hardware restart).

[0123] Temperature and capacitance monitoring involves deploying thermistors or temperature sensors near the heatsinks and capacitors inside the power supply to monitor the temperature in real time (e.g., normal temperature ≤70℃) and issue warnings when the threshold is exceeded. Capacitor impedance detection circuits (such as the bridge method) monitor the equivalent series resistance of electrolytic capacitors; the equivalent series resistance of aging capacitors will increase significantly, which can predict the risk of capacitor failure.

[0124] Power and ripple detection: Use a power meter to calculate the output power in real time. If the power increases abnormally even when the load remains unchanged, it may be due to a short circuit in an internal component. Monitor the output voltage ripple using an oscilloscope or ripple detection module. Excessive ripple (e.g., 12V output ripple ≥120mV) may cause hardware instability.

[0125] In the embodiments of this application, mechanical hard drives rely on read and write operations by magnetic heads and platters, while solid-state drives rely on flash memory and a main control chip. Common faults include slow read and write speeds, bad sectors, disk failures, or data loss.

[0126] In this embodiment of the application, when multiple hardware components include a mechanical hard disk, at least one of the vibration data, temperature data, hard disk capacity data, and hard disk data integrity of the mechanical hard disk is used for fault diagnosis to obtain the fault diagnosis result of the mechanical hard disk.

[0127] For example, the status data of a hard disk drive can be monitored using the following methods.

[0128] Through the self-monitoring, analysis, and reporting technology built into the hard drive firmware, parameters such as "seek error rate," "rotational retry count," and "head loading / unloading count" are read in real time, and warnings are issued based on preset thresholds. For example, "reallocation sector count" > 0 indicates the presence of bad sectors.

[0129] Vibration and temperature monitoring involves installing accelerometers in the hard drive bracket to detect abnormal vibrations, such as server rack shaking that could cause the read / write heads to scratch the platters. Temperature data is read through the hard drive interface; overheating can accelerate disk aging.

[0130] In this embodiment of the application, when multiple hardware components include solid-state drives (SSDs), fault diagnosis is performed on at least one of the SSD's chip temperature data, read / write speed data, hard disk capacity data, and hard disk data integrity to obtain the SSD's fault diagnosis result.

[0131] For example, the status data of a solid-state drive can be monitored using the following methods.

[0132] Controller and flash memory health: Read information such as "flash memory write volume," "write / erase cycles," and "remaining lifespan percentage" (for example, if the total write volume of a certain model of SSD exceeds a preset target, it indicates that its lifespan is about to end). Monitor the temperature of the SSD's controller chip (e.g., normal temperature ≤ 70℃), as overheating may cause speed drops or data errors.

[0133] For read / write performance testing, perform short-term random / sequential read / write tests periodically and compare the results with the baseline performance. If the continuous read / write speed drops by more than 30%, it may indicate that the flash memory chip is damaged or the controller is faulty.

[0134] In the embodiments of this application, when multiple hardware components include memory, fault diagnosis is performed on at least one of the memory's voltage data, clock signal data, and temperature data to obtain the memory's fault diagnosis result.

[0135] For example, the following methods can be used to monitor memory status data.

[0136] Electrical signal monitoring involves deploying voltage monitoring circuits near the memory slots to detect the memory power supply in real time. For example, if the standard voltage is 1.2V and a voltage fluctuation of ±5% is detected, it is considered an anomaly. The frequency stability and phase difference of the clock signal are monitored using an oscilloscope or a dedicated chip; clock anomalies can lead to data transmission errors.

[0137] Parity checking and error correction code verification are supported. Server memory that supports error correction codes can detect and correct single-bit errors in real time. If multi-bit errors occur or the number of verification failures is frequent (e.g., more than once per minute), it indicates that the memory chips are damaged. Ordinary memory can be periodically scanned with operating system tools to detect the presence of bad blocks.

[0138] Temperature and compatibility testing involves installing temperature sensors on the memory heatsinks. Overclocking or poor heat dissipation can cause excessively high temperatures; for example, the normal operating temperature should be ≤80℃. The system log records whether the memory frequency and timings are compatible with the motherboard.

[0139] In this embodiment of the application, when multiple hardware components include network cards, at least one of the physical link status data, packet loss rate data, temperature data, and power consumption data of the network card is used for fault diagnosis to obtain the fault diagnosis result of the network card.

[0140] For example, the status data of the network card can be monitored using the following methods.

[0141] Physical link status monitoring involves reading "link speed" and "duplex mode" through the network card driver and checking the indicator lights on the RJ45 interface (solid light indicates a working link, flashing indicates data transmission). If the indicator light is off or has an abnormal color (such as green turning orange), it may indicate poor network cable contact or a damaged interface.

[0142] Signal quality and packet loss rate can be assessed using dedicated network testing tools. Send data packets to a fixed address and record the packet loss rate (e.g., normal packet loss rate < 0.1%). If the packet loss rate consistently exceeds 1%, it may indicate electromagnetic interference (such as from nearby strong magnetic field equipment) or chip malfunction. Read the "Error Frame Count" parameter using a network interface card (NIC) management tool; abnormal counts indicate data transmission errors.

[0143] Temperature and power consumption monitoring: High-end network interface cards (NICs) with integrated temperature sensors (such as 10 Gigabit Ethernet cards for servers) can report temperature in real time (e.g., normal temperature ≤ 60℃). Overheating can lead to increased network latency. Monitoring NIC power consumption via the motherboard's power management chip can also help; an abnormally high standby power consumption may indicate an internal short circuit in the chip.

[0144] Through the embodiments of this application, we conduct in-depth analysis of the fault mechanisms of various hardware components and design exclusive detection methods, which can improve the accuracy of fault diagnosis of the status data of various hardware components.

[0145] In some embodiments, the server's processor needs to acquire status data from various hardware components. These components may include, for example, a power supply, hard drive, memory, and network interface card (NIC). Different hardware components use different data transmission methods.

[0146] For example, power can be supplied via an internal integrated circuit bus (I-Integrated Circuit, I-Blocks). 2C) Transmitting Status Data. Hard drives can monitor status data such as bad sector count, temperature, and power-on time using Self-Monitoring, Analysis and Reporting Technology (SMART). Memory can obtain status data such as storage capacity, timing, and voltage through a Serial Presence Detection (SPD) chip. Network interface cards (NICs) can obtain status data such as packet loss rate and link status through Simple Network Management Protocol (SNMP).

[0147] In this embodiment of the application, the server includes a protocol adapter, which is communicatively connected to each of the multiple hardware devices to unify the data model of the heterogeneous interfaces of the various hardware devices.

[0148] For example, a protocol adapter could be a multi-protocol converter chip used to convert raw signals into standard data frames. A multi-protocol converter chip can convert status data from various hardware components into the same type of data for transmission to the processor or local edge node.

[0149] According to another aspect of the embodiments of this application, a server hardware detection device is also provided, comprising: a first acquisition module, configured to acquire status data of each hardware component among a plurality of hardware components of a server; a diagnosis module, configured to perform fault diagnosis on the status data of each hardware component respectively, and obtain a fault diagnosis result; a first determination module, configured to, in response to the fault diagnosis result indicating the presence of abnormal status data among the multiple status data of the multiple hardware components, determine the timestamp of the abnormal status data as a target time, wherein the timestamp indicates the generation time of the status data; a second determination module, configured to determine the query value of each status data component among the multiple status data components based on the target time and the timestamps of the multiple status data components; and a third determination module, configured to query a preset rule based on the query value of each status data component to obtain the hardware fault type of the server, wherein the preset rule represents the mapping relationship between the multiple status data components and the hardware fault type.

[0150] It should be noted that the first acquisition module in this embodiment can be used to perform the above operation S210, the diagnosis module in this embodiment can be used to perform the above operation S220, the first determination module in this embodiment can be used to perform the above operation S230, the second determination module in this embodiment can be used to perform the above operation S240, and the third determination module in this embodiment can be used to perform the above operation S250.

[0151] The embodiments provided in this application perform fault diagnosis on the status data of each hardware component individually, obtaining the detection results for each hardware component and identifying potential faults in each component. When the fault diagnosis results indicate abnormal status data, the status data of each hardware component is combined and analyzed. By combining the status data of multiple hardware components and determining the type of hardware fault in the server according to preset rules, false alarms can be effectively avoided, improving the accuracy of server hardware fault detection results.

[0152] Optionally, the second determining module includes: a first determining submodule, used to determine the value corresponding to each state data at the target time as the query value of each state data according to the target time and the timestamp of the state data, wherein the timestamp of the query value of each state data is the target time or is located before the target time.

[0153] Optionally, the second determining module includes: a second determining submodule, used to determine a target state dataset whose timestamps are located within a target time window from multiple state data based on the target time and the timestamps of the state data, wherein the target time is located within the target time window. The value corresponding to at least one time within the target time window for each state data in the target state dataset is determined as the query value for each state data.

[0154] Optionally, the third determining module includes a third determining submodule, used to determine the hardware fault type corresponding to the target rule as the hardware fault type of the server when the query value of each state data satisfies the threshold range indicated by the target rule in the preset rules. The target rule includes the threshold range corresponding to each state data and the hardware fault type corresponding to multiple state data.

[0155] Optionally, the device further includes a fourth determining module, used to determine the hardware fault type of the server based on the fault diagnosis results when the query value of each state data does not meet the threshold range indicated by the target rule.

[0156] Optionally, the device further includes: a second acquisition module, configured to acquire a historical fault dataset of the server, wherein the historical fault dataset includes multiple historical state data of multiple hardware components when the server experienced a hardware fault in a historical period. A fifth determination module, configured to determine, based on the historical fault dataset, at least one historical abnormal state data corresponding to any hardware fault, wherein the historical abnormal state data is the state data that is abnormal among the multiple state data when the server experienced any hardware fault. A construction module, configured to construct preset rules based on any hardware fault and at least one historical abnormal state data.

[0157] Optionally, the construction module includes: a fourth determination submodule, used to determine, based on the historical fault dataset, the number of times each historical abnormal state data occurs when the server experiences any hardware failure during a historical period. A fifth determination submodule, used to determine the probability value of each historical abnormal state data based on the total number of times the server experiences any hardware failure during a historical period and the number of times each historical abnormal state data occurs. A sixth determination submodule, used to determine the probability value of each combination of historical abnormal state data based on the probability values ​​of each historical abnormal state data, wherein each combination of historical abnormal state data includes at least one historical abnormal state data, and different combinations of historical abnormal state data include different types of historical abnormal state data. A seventh determination submodule, used to add the mapping relationship between any historical abnormal state data combination and any hardware failure to a preset rule in response to the probability value of any historical abnormal state data combination exceeding a preset threshold.

[0158] Optionally, the device further includes: a sixth determining module, used to determine the faulty hardware and fault handling operations based on the fault diagnosis results in response to the presence of abnormal state data among multiple state data representing multiple hardware components; and an execution module, used to invoke the faulty hardware to perform the fault handling operations.

[0159] Optionally, the diagnostic module includes: a first diagnostic submodule, used to perform fault diagnosis on at least one of the following: voltage data, temperature data, capacitance data, power data, and voltage ripple, when multiple hardware components include a power supply, to obtain a fault diagnosis result for the power supply. A second diagnostic submodule, used to perform fault diagnosis on at least one of the following: vibration data, temperature data, hard drive capacity data, and hard drive data integrity, when multiple hardware components include a hard disk drive (HDD), to obtain a fault diagnosis result for the HDD. A third diagnostic submodule, used to perform fault diagnosis on at least one of the following: chip temperature data, read / write speed data, hard drive capacity data, and hard drive data integrity, when multiple hardware components include a solid-state drive (SSD), to obtain a fault diagnosis result for the SSD. A fourth diagnostic submodule, used to perform fault diagnosis on at least one of the following: voltage data, clock signal data, and temperature data, when multiple hardware components include memory, to obtain a fault diagnosis result for the memory. A fifth diagnostic submodule, used to perform fault diagnosis on at least one of the following: physical link status data, packet loss rate data, temperature data, and power consumption data, when multiple hardware components include a network interface card (NIC), to obtain a fault diagnosis result for the NIC.

[0160] According to another aspect of the embodiments of this application, an electronic device is also provided, including a memory and a processor, wherein the memory stores a computer program and the processor is configured to perform the steps of any of the above method embodiments through the computer program.

[0161] In one exemplary embodiment, the electronic device may further include a transmission device and an input / output device, wherein the transmission device is connected to the processor and the input / output device is connected to the processor.

[0162] Specific examples in this embodiment can be found in the examples described in the above embodiments and exemplary implementations, and will not be repeated here.

[0163] According to another aspect of the embodiments of this application, a computer-readable storage medium is also provided, the computer-readable storage medium including a stored program, wherein the program executes the steps in any of the above method embodiments when it is run.

[0164] In one exemplary embodiment, the aforementioned computer-readable storage medium may include, but is not limited to, various media capable of storing computer programs, such as a USB flash drive, read-only memory (ROM), random access memory (RAM), portable hard disk, magnetic disk, or optical disk.

[0165] According to another aspect of the embodiments of this application, a computer program product is provided, the computer program product including a computer program / instructions comprising program code for performing the method shown in the flowchart. In such an embodiment, reference is made to... Figure 7 The computer program can be downloaded and installed from a network via the communication section 709, and / or installed from the removable medium 711. When the computer program is executed by the central processing unit 701, it performs various functions provided in the embodiments of this application. The sequence numbers of the embodiments of this application above are for descriptive purposes only and do not represent the superiority or inferiority of the embodiments.

[0166] refer to Figure 7 , Figure 7 A schematic block diagram of a computer system for an electronic device according to an embodiment of this application is shown.

[0167] Figure 7 A schematic block diagram of a computer system architecture for implementing embodiments of the present application is shown. Figure 7As shown, the computer system 700 includes a central processing unit (CPU) 701, which can perform various appropriate actions and processes based on programs stored in read-only memory (ROM) 702 or programs loaded from storage section 708 into random access memory (RAM) 703. The RAM 703 also stores various programs and data required for system operation. The CPU 701, ROM 702, and RAM 703 are interconnected via a bus 704. An input / output interface 704 (I / O interface) is also connected to the bus 704.

[0168] The following components are connected to the input / output interface 704: an input section 706 including a keyboard, mouse, etc.; an output section 707 including a cathode ray tube (CRT), liquid crystal display (LCD), etc., and speakers, etc.; a storage section 708 including a hard disk, etc.; and a communication section 709 including a network interface card such as a local area network card, modem, etc. The communication section 709 performs communication processing via a network such as the Internet. A drive 710 is also connected to the input / output interface 704 as needed. A removable medium 711, such as a disk, optical disk, magneto-optical disk, semiconductor memory, etc., is installed on the drive 710 as needed so that computer programs read from it can be installed into the storage section 708 as needed.

[0169] Specifically, according to embodiments of this application, the processes described in the various method flowcharts can be implemented as computer software programs. For example, embodiments of this application include a computer program product comprising a computer program carried on a computer-readable medium, the computer program containing program code for performing the methods shown in the flowcharts. In such embodiments, the computer program can be downloaded and installed from a network via communication section 709, and / or installed from removable medium 711. When the computer program is executed by central processing unit 701, it performs various functions defined in the system of this application.

[0170] It should be noted that, Figure 7 The computer system 700 of the electronic device shown is merely an example and should not impose any limitation on the functionality and scope of use of the embodiments of this application.

[0171] Obviously, those skilled in the art should understand that the modules or steps of the embodiments of this application described above can be implemented using general-purpose computing devices. They can be centralized on a single computing device or distributed across a network of multiple computing devices. They can be implemented using computer-executable program code, and thus can be stored in a storage device for execution by a computing device. In some cases, the steps shown or described can be performed in a different order than those presented here, or they can be fabricated as separate integrated circuit modules, or multiple modules or steps can be fabricated as a single integrated circuit module. Thus, the embodiments of this application are not limited to any particular combination of hardware and software.

[0172] The above are merely preferred embodiments of this application and are not intended to limit the embodiments of this application. For those skilled in the art, various modifications and variations can be made to the embodiments of this application. Any modifications, equivalent substitutions, improvements, etc., made within the principles of the embodiments of this application should be included within the protection scope of the embodiments of this application.

Claims

1. A server hardware testing method, characterized in that, include: Obtain the status data of each hardware component in the server's multiple hardware components; Fault diagnosis is performed on the status data of each hardware component to obtain the fault diagnosis results; In response to the fault diagnosis result indicating the presence of abnormal state data among the multiple state data of the multiple hardware components, the timestamp of the abnormal state data is determined as the target time, wherein the timestamp indicates the time when the state data was generated; Based on the target time and the timestamps of the multiple state data, determine the query value for each state data in the multiple state data; Based on the query values ​​of the various status data, a preset rule is used to obtain the hardware fault type of the server, wherein the preset rule represents the mapping relationship between the multiple status data and the hardware fault type; The method further includes: Obtain a historical fault dataset of the server, wherein the historical fault dataset includes multiple historical state data of multiple hardware components when the server experienced hardware failures during historical periods; Based on the historical fault dataset, at least one historical abnormal state data corresponding to any hardware fault is determined, wherein the historical abnormal state data is the abnormal state data among the multiple state data when the server experiences any hardware fault. Based on the historical fault dataset, determine the number of times each historical abnormal state data occurred when the server experienced any of the hardware faults during the historical period; Based on the total number of times the server experienced any of the hardware failures during the historical period, and the number of times each historical abnormal state data appeared, the probability value of each historical abnormal state data is determined. Based on the probability values ​​of each historical abnormal state data, the probability value of each combination of historical abnormal state data is determined, wherein each combination of historical abnormal state data includes at least one historical abnormal state data, and different combinations of historical abnormal state data include different types of historical abnormal state data. In response to the probability value of any combination of historical abnormal state data exceeding a preset threshold, the mapping relationship between the combination of historical abnormal state data and the hardware fault is added to the preset rule.

2. The method according to claim 1, characterized in that, The step of determining the query value for each state data among the plurality of state data based on the target time and the timestamp of the state data includes: Based on the target time and the timestamp of the state data, the value of each state data corresponding to the target time is determined as the query value of each state data, wherein the timestamp of the query value of each state data is the target time or is located before the target time.

3. The method according to claim 1, characterized in that, The step of determining the query value for each state data among the plurality of state data based on the target time and the timestamp of the state data includes: Based on the target time and the timestamps of the state data, a target state dataset whose timestamps are located within the target time window is determined from the plurality of state data, wherein the target time is located within the target time window; The value corresponding to each state data in the target state dataset at at least one moment within the target time window is determined as the query value for each state data.

4. The method according to claim 2 or 3, characterized in that, The query based on the preset rules of the query values ​​of the various status data yields the hardware fault types of the server, including: If the query value of each state data satisfies the threshold range indicated by the target rule in the preset rules, the hardware fault type corresponding to the target rule is determined as the hardware fault type of the server. The target rule includes a threshold range corresponding to each state data and a hardware fault type corresponding to the multiple state data.

5. The method according to claim 4, characterized in that, The method further includes: If the query value of each status data does not meet the threshold range indicated by the target rule, the hardware fault type of the server is determined based on the fault diagnosis result.

6. The method according to claim 1, characterized in that, The method further includes: In response to the fault diagnosis result indicating the presence of abnormal state data in multiple state data of the multiple hardware components, the faulty hardware and fault handling operation are determined based on the fault diagnosis result. The faulty hardware is invoked to perform the fault handling operation.

7. The method according to claim 1, characterized in that, The step of performing fault diagnosis on the status data of each hardware component to obtain fault diagnosis results includes: When the plurality of hardware includes a power supply, fault diagnosis is performed on at least one of the voltage data, temperature data, capacitance data, power data, and voltage ripple of the power supply to obtain the fault diagnosis result of the power supply. When the plurality of hardware includes a mechanical hard disk, fault diagnosis is performed on at least one of the vibration data, temperature data, hard disk capacity data, and hard disk data integrity of the mechanical hard disk to obtain the fault diagnosis result of the mechanical hard disk; When the plurality of hardware includes a solid-state drive (SSD), fault diagnosis is performed on at least one of the SSD's chip temperature data, read / write speed data, hard disk capacity data, and hard disk data integrity to obtain the fault diagnosis result of the SSD. When the plurality of hardware includes memory, fault diagnosis is performed on at least one of the voltage data, clock signal data and temperature data of the memory to obtain the fault diagnosis result of the memory; When the plurality of hardware includes a network interface card (NIC), at least one of the physical link status data, packet loss rate data, temperature data, and power consumption data of the NIC is used for fault diagnosis to obtain the fault diagnosis result of the NIC.

8. An electronic device, comprising: One or more processors; Memory, used to store one or more computer programs. The characteristic feature is that the one or more processors execute the one or more computer programs to implement the steps of the method according to any one of claims 1 to 7.

Images