Alarm method, device, electronic equipment, medium and product

Abstract

The present application discloses an alarm method, device, electronic device, medium and product, which relate to the field of equipment management technology. When the device to be detected works abnormally, de-jitter detection processing is first performed to determine whether the cause of the abnormal work is a fault or jitter. This can avoid alarming for jitter that does not affect the work of the device to be detected, thereby improving the accuracy of the alarm.

Description

Technical Field

[0001] The present application relates to the field of equipment management technology, and in particular to alarm methods, devices, electronic equipment, media and products. Background Art

[0002] During device operation, equipment failures may occur due to various factors, such as changes in power supply status, device temperature, or operating environment. Managing equipment and promptly detecting and resolving faults is crucial to maintaining normal operation.

[0003] In related technologies, the working parameters of the equipment are detected and the working status of the equipment is determined based on the working parameters. If the working status is abnormal, an alarm is directly processed to improve the operation and maintenance personnel's ability to handle faults. However, this method has the problem of low alarm accuracy. Summary of the Invention

[0004] The present application provides an alarm method, device, electronic device, medium and product to at least solve the problem of low alarm accuracy in related technologies.

[0005] The present application provides an alarm method, including: receiving a detection request, the detection request including at least one device identifier to be detected; determining, based on the detection request, at least one device to be detected corresponding to the at least one device identifier to be detected; determining the working status of the device to be detected; if the working status is abnormal, performing de-jitter detection processing on the device to be detected to obtain a detection result, and performing alarm processing based on the detection result.

[0006] The present application also provides an alarm device, including: a receiving module for receiving a detection request, the detection request including at least one device identifier to be detected; a determination module for determining, based on the detection request, at least one device to be detected corresponding to the at least one device identifier to be detected; an acquisition module for determining the working status of the device to be detected; and a detection module for performing de-jitter detection processing on the device to be detected to obtain a detection result if the working status is abnormal, and performing alarm processing based on the detection result.

[0007] The present application also provides an electronic device, comprising: a memory for storing a computer program; and a processor for implementing the steps of any of the above-mentioned alarm methods when executing the computer program.

[0008] The present application also provides a computer-readable storage medium, in which a computer program is stored. When the computer program is executed by a processor, the steps of any of the above-mentioned alarm methods are implemented.

[0009] The present application also provides a computer program product, including a computer program, which implements the steps of any of the above-mentioned alarm methods when executed by a processor.

[0010] Through this application, when the device to be detected works abnormally, de-jitter detection processing is first performed to determine whether the cause of the abnormal operation is a fault or jitter, which can avoid alarming for jitter that does not affect the operation of the device to be detected, thereby improving the accuracy of the alarm. BRIEF DESCRIPTION OF THE DRAWINGS

[0011] In order to more clearly illustrate the embodiments of the present application, the following is a brief introduction to the drawings required for use in the embodiments. Obviously, the drawings described below are only some embodiments of the present application. For ordinary technicians in this field, other drawings can be obtained based on these drawings without any creative work.

[0012] Figure 1 A schematic diagram of an application scenario of an alarm method provided in an embodiment of the present application;

[0013] Figure 2 A flowchart of an alarm method provided in an embodiment of the present application;

[0014] Figure 3 A flowchart of an alarm method provided in an embodiment of the present application;

[0015] Figure 4 A schematic diagram of the work strategy provided in the embodiment of the present application;

[0016] Figure 5 A schematic diagram of debounce detection provided in an embodiment of the present application;

[0017] Figure 6 A schematic diagram of a lighting strategy provided in an embodiment of the present application;

[0018] Figure 7 A schematic diagram of a controller alarm provided in an embodiment of the present application;

[0019] Figure 8 A schematic diagram of the structure of an alarm device provided in an embodiment of the present application;

[0020] Figure 9 A schematic diagram of the structure of an alarm device provided in an embodiment of the present application;

[0021] Figure 10 A schematic diagram of the structure of an electronic device provided in an embodiment of the present application. DETAILED DESCRIPTION

[0022] The following will be combined with the accompanying drawings in the embodiments of this application to clearly and completely describe the technical solutions in the embodiments of this application. Obviously, the embodiments described are only part of the embodiments of this application, not all of them. Based on the embodiments in this application, all other embodiments obtained by ordinary technicians in this field without making creative efforts are within the scope of protection of this application.

[0023] It should be noted that, in the description of this application, the terms "comprises," "includes," or any other variations thereof are intended to cover non-exclusive inclusion, such that a process, method, article, or device comprising a series of elements includes not only those elements, but also other elements not explicitly listed, or elements inherent to such process, method, article, or device. The terms "first," "second," etc., in this application are used to distinguish similar objects, and are not used to describe a particular order or sequence.

[0024] For example, during device operation, a fault or jitter may occur. A fault is a serious anomaly that can severely impact device operation and must be addressed promptly. Failure to do so may result in the device failing to fully or incompletely function, potentially impacting other devices. Jitter can be a transient fluctuation during device operation. During this period, the device is in a transient state, and the jitter is within a safe and controllable range, not impacting normal device operation.

[0025] In real-world applications, multiple devices can work together. For example, a large data center includes multiple devices that work together to realize the functions of the large data center. Failure of some devices can cause the large data center to malfunction or even damage other equipment. Therefore, accurate alarms for these failures are necessary to prompt operations and maintenance personnel to promptly address the failures and restore normal functions of the large data center.

[0026] In related technologies, both faults and jitter can cause equipment anomalies, the difference being the severity and duration of the anomaly. Jitter does not require processing, and accordingly, no alarms are generated. If both faults and jitter are not distinguished and alarms are generated, false alarms may occur, and the handling of false alarms by maintenance personnel will affect equipment maintenance. For example, when multiple devices generate alarms, maintenance personnel must investigate each one individually to determine whether the alarm is caused by jitter or a fault. Handling alarms caused by jitter will affect the efficiency of handling alarms caused by faults, and failure to address faults in a timely manner will affect the normal operation of the equipment.

[0027] In order to enable those skilled in the art to better understand the present application, the present application is further described in detail below with reference to the accompanying drawings and specific implementation methods.

[0028] In conjunction with the specific application environment architecture or specific hardware architecture on which the execution of the alarm method depends, the specific application environment architecture or specific hardware architecture is described here. Figure 1 , Figure 1 The figure is a schematic diagram of an application scenario of the alarm method. The device is detected and processed to obtain the working status of the device. The working status is normal or abnormal. If the working status is abnormal, an alarm is processed.

[0029] In the related art, an alarm is directly issued without distinguishing whether the abnormal working state is caused by a fault or a jitter, which may cause a false alarm problem.

[0030] In this application, when it is determined that the working status of the equipment is abnormal, a judgment is made to determine whether the abnormal working status is caused by a fault or jitter, and an alarm is only issued for the abnormal working status caused by the fault, avoiding the problem of false alarms, thereby improving the accuracy of the alarm.

[0031] Figure 2 A flowchart of the alarm method provided in the embodiment of the present application is shown in FIG. Figure 2 As shown, the embodiment of the present application provides an alarm method, which is described in detail as follows:

[0032] S201: Receive a detection request, where the detection request includes at least one identification of a device to be detected.

[0033] Exemplarily, the device identifier to be detected is used to identify the device to be detected, and different devices to be detected can be accurately distinguished through the device identifier to be detected.

[0034] Optionally, the identification of the device to be detected includes but is not limited to at least one of the following: a device code, a device serial number, or a device identification code, etc.

[0035] Exemplarily, the detection request is used to trigger alarm processing, and the alarm processing is started according to the instruction of the detection request.

[0036] Optionally, the detection request may be accompanied by a time limit, which is used to indicate the duration of the alarm processing. During the duration, real-time alarm processing is performed on the device to be detected, thereby continuously monitoring whether there is any abnormality in the device to be detected.

[0037] S202: Determine, according to the detection request, at least one device to be detected corresponding to at least one device identifier to be detected.

[0038] Exemplarily, there is a one-to-one correspondence between the device identifier to be detected and the device to be detected, and each device identifier to be detected corresponds to one device to be detected, thereby accurately determining the device to be detected.

[0039] In combination with the scenario example, the device to be detected is a device that is running or about to run, and an alarm is issued to the device to be detected to promptly handle the fault of the device to be detected so that the device to be detected can continue to run.

[0040] In conjunction with the scenario example, the device to be detected includes but is not limited to at least one of the following: a device in a switch, a device in a server, etc.

[0041] S203: Determine the working status of the device to be detected.

[0042] For example, normal operation indicates that the device under test is operating according to a preset state, while abnormal operation indicates that the device under test is not operating according to the preset state. For example, the preset state may be a preset operating parameter range. If the real-time operating parameters of the device under test are not within the preset operating parameter range, an abnormal operation is indicated. The preset state may be a preset function. If the device under test does not implement the preset function (for example, power supply is stopped, heat dissipation is stopped, or calculation is not performed), an abnormal operation is indicated.

[0043] Combined with the scenario example, a device failure or device jitter will cause the device to work abnormally. However, if the device jitter is within a controllable range, it will not affect the device's operation and does not require any processing.

[0044] S204: If the working state is abnormal, de-jitter detection processing is performed on the device to be detected to obtain a detection result, and alarm processing is performed according to the detection result.

[0045] Exemplarily, the de-jitter detection process includes a de-jitter operation, through which the working abnormality caused by jitter can be filtered out. The detection result obtained by the de-jitter detection process is the detection result after the jitter is filtered out. If the detection result is abnormal, it is an abnormality caused by a fault.

[0046] For example, if the operating abnormality is caused by jitter, it will recover within a short period of time. If the operating abnormality is caused by a fault, it will persist for a period of time. The de-jitter detection process can accurately distinguish the cause of jitter.

[0047] For example, if the working state is abnormal, further de-jitter detection is performed, and it is determined based on the detection result whether the abnormal working state is caused by a fault or jitter, thereby avoiding alarming for jitter.

[0048] Combined with the scenario example, when the working status is abnormal, de-jitter detection processing is continued to be performed to further judge the working abnormality, so as to determine whether the working abnormality is caused by a fault or jitter, thereby improving the accuracy of alarm processing.

[0049] The alarm method provided in the embodiment of the present application receives a detection request, the detection request includes at least one device identifier to be detected; determines at least one device to be detected corresponding to the at least one device identifier to be detected based on the detection request; determines the working status of the device to be detected; if the working status is abnormal, performs de-jitter detection processing on the device to be detected to obtain a detection result, and performs alarm processing based on the detection result. In the above scheme, when the device to be detected is working abnormally, de-jitter detection processing is first performed to determine whether the cause of the abnormal working is a fault or jitter, which can avoid alarming for jitter that does not affect the operation of the device to be detected, thereby improving the accuracy of the alarm.

[0050] Based on any of the above embodiments, Figure 3 , describes the detailed process of the alarm.

[0051] Figure 3 This is a flow chart of an alarm method provided in an embodiment of the present application. Figure 3 As shown, the method includes:

[0052] S301: Receive a detection request, where the detection request includes at least one identification of a device to be detected.

[0053] It should be noted that the execution process of S301 refers to S201 and will not be repeated here.

[0054] S302: Determine, according to the detection request, at least one device to be detected corresponding to at least one device identifier to be detected.

[0055] It should be noted that the execution process of S302 refers to S202 and will not be repeated here.

[0056] S303: Obtain a working strategy message of the device to be detected, where the working strategy message includes a current working strategy instructing the device to be detected to execute.

[0057] Exemplarily, the current working strategy is used to indicate the working parameters that the device to be detected currently needs to execute.

[0058] Optionally, the operating parameters include but are not limited to at least one of the following: voltage, current, speed, or frequency.

[0059] Optionally, the current working policy is encapsulated as a message for transmission, and the message is parsed to obtain the current working policy.

[0060] In this scenario, let's take a cooling fan installed in a switch as an example. The fan's current speed is 500 rpm, and the switch's current temperature is higher than the temperature threshold. This indicates that the fan's speed is insufficient to dissipate heat from the switch. To effectively dissipate heat, the switch can increase the fan's speed by sending a working policy message. The working policy corresponds to a working policy message. Conversely, if the switch's current temperature is lower than the temperature threshold, the switch can reduce the fan's speed by sending a working policy message.

[0061] S304: Determine the historical working strategy of the device to be detected.

[0062] For example, the historical working strategy may be the working parameters last executed by the device to be detected.

[0063] Optionally, a policy record is maintained for each device, the policy record stores the working policy executed each time, and the historical working policy is obtained through the policy record.

[0064] Optionally, obtain historical work strategies from log files.

[0065] S305: If the current working strategy is the same as the historical working strategy, determine the working status of the device to be detected.

[0066] Exemplarily, the current working strategy is the same as the historical working strategy, indicating that the working strategy of the device to be detected has not changed. At this time, the device to be detected will not jitter due to the change in the working strategy, and the working status of the device to be detected is determined.

[0067] For example, if the current operating strategy is the same as the historical operating strategy, the target indicator light is controlled to display a second light, indicating that the device under test is normal. If the current operating strategy is the same as the historical operating strategy, it means that the operating strategy of the device under test has changed. When the current operating strategy is executed, the device under test is operating normally, and the operating parameters of the device under test may be unstable. Forcing the target indicator light to display the second light can avoid false alarms, thereby achieving debounce operation.

[0068] Exemplarily, the historical working strategy is updated after executing the current working strategy.

[0069] Next, combine Figure 4 Explain the work strategy for distribution.

[0070] Figure 4 This is a schematic diagram of the work strategy provided in the embodiment of this application. Figure 4As shown, determine whether the device to be tested has stopped working. If so, end the process. If the device to be tested is working, generate the current working strategy based on the real-time status (for example, the speed of the cooling fan is too low). Determine whether the current working strategy is different from the historical working strategy. If different, generate a change message; if the same, generate an unchanged message. The change message or unchanged message is used to indicate whether to perform the debounce operation. Use the current working strategy as the historical working strategy to update the historical working strategy, and issue the current working strategy. The generation or termination of the working strategy can be executed multiple times.

[0071] In this scenario, let's take a cooling fan as an example. If the historical operating policy is 500 rpm and the current operating policy is 700 rpm, the cooling fan speed will be unstable while the current policy is being used to adjust the speed to 700 rpm. This short-lived state is considered jitter. In this case, forcing the target indicator to display a second light can effectively prevent false alarms.

[0072] A feasible implementation method can determine the working status of the device to be detected by the following method, including: performing in-situ detection processing on the device to be detected to obtain in-situ information of the device to be detected, and the in-situ information is normal or abnormal; if the in-situ information is normal, the working status of the device to be detected is determined.

[0073] For example, the in-position information indicates whether the device to be tested is correctly set at the corresponding position, and the normal in-position information indicates that the device to be tested is correctly set at the corresponding position. The normal in-position information is a prerequisite for the normal operation of the device to be tested. The working status determined on this basis can be unaffected by the presence of abnormalities.

[0074] In this feasible implementation, through on-site detection processing, the interference of on-site abnormalities on the working status can be avoided, thereby improving the accuracy of determining the working status and further improving the accuracy of the alarm.

[0075] In a feasible implementation manner, the alarm method further includes: if the presence information indicates presence abnormality, controlling the target indicator light not to display light.

[0076] For example, an in-place abnormality indicates that the device to be tested is not installed correctly. The target indicator light does not light to indicate an in-place abnormality, prompting operation and maintenance personnel to handle it in a timely manner. In the case of an in-place abnormality, the device to be tested cannot work properly, and the alarm processing process is not performed, which can reduce operations.

[0077] Optionally, if an abnormality occurs in place, a prompt will be sent to the host computer to promptly prompt the operation and maintenance personnel to handle it in time and eliminate the abnormality.

[0078] In this feasible implementation, by controlling the target indicator light not to display light, operation and maintenance personnel can be promptly notified to handle the problem, thereby improving the reliability of the equipment to be tested.

[0079] S306: Determine a window stack and a target window width corresponding to the device to be detected. The window stack is used to temporarily store detection data, and the target window width is an upper limit on the amount of detection data temporarily stored in the window stack.

[0080] Exemplarily, the de-jitter detection process of the present application includes multiple detections, and the de-jitter detection result is obtained based on the detection data of the multiple detections. A window stack is used to temporarily store the detection data, and the detection result is obtained based on the detection data in the window stack. In the process of determining the detection result, the detection data in the window stack is used as a basis.

[0081] In this scenario, an anomaly caused by a fault persists for a long time or cannot be recovered on its own. Continuous detection data is stored in the window stack. If all continuous detection data in the window stack are abnormal, it can be determined that the anomaly is caused by the fault.

[0082] Illustratively, the target window width controls the amount of detection data in the window stack, and the detection data in the window stack can be partially retrieved or cleared.

[0083] For example, the window stack is bound to the device to be detected, and the detection data of the device to be detected can only be temporarily stored in the window stack. The window stack can temporarily store the detection data of the bound device to be detected. It can be understood that through the binding process, interference between detection data of different devices is avoided, thereby improving the accuracy of the alarm.

[0084] A feasible implementation method can determine the target window width by the following method, including: determining the historical alarm records and historical window widths of the device to be detected; determining the window width mapping relationship table and the window width reference value; determining the window width offset value corresponding to the device to be detected based on the historical alarm records, historical window widths, and the window width mapping relationship table; determining the target window width based on the window width reference value and the window width offset value.

[0085] Exemplarily, the historical alarm record includes multiple alarm records of the device to be detected, including the time corresponding to each alarm record. The historical window width is the width of the window stack used historically by the device to be detected.

[0086] Exemplarily, the window width offset value indicates the degree of offset of the target window width relative to the window width reference value.

[0087] Optionally, the window width mapping relationship table is used to map a matching window width offset value according to historical alarm records and historical window widths.

[0088] In this scenario example, historical alarm records can be used to determine the frequency and / or severity of historical alarms. If historical alarms occur frequently or are severe, strict alarm processing should be performed on the device under test. This means setting a smaller target window width to avoid missing faults. The historical window width is a previously used window width and can be used as a reference. If the historical window width is 4, it indicates that a window width of 4 is suitable for the device under test, and the target window width can be determined around 4. The window width mapping table is used to reflect the reference relationship between historical alarm records and historical window widths and the target window width.

[0089] Exemplarily, the target window width is the sum of the window width reference value and the window width offset value.

[0090] Combined with the scenario example, if the window width base value is 6 and the window width offset value is -1, the target window width is determined to be , that is 5.

[0091] In this feasible implementation, the target window width is dynamically determined based on historical alarm records and historical window widths, so that the target window width can better match the fault occurrence of the device to be detected, thereby improving the accuracy of the alarm.

[0092] S307 , continuously detect the working status of the device to be detected to obtain a plurality of detection data, and add the plurality of detection data to the window stack. The detection data is normal or abnormal.

[0093] Exemplarily, there is a sequence relationship between the plurality of detection data, and the installation sequence relationship adds the plurality of detection data to the window stack in sequence, so that the detection data in the window stack accurately reflects abnormal changes of the device to be detected.

[0094] Combined with the scenario example, if all the detection data in the window stack are abnormal, it means that the abnormality of the data to be detected is continuous rather than instantaneous jitter, and it is considered that the device to be detected has a fault.

[0095] Optionally, a detection interval is determined, and the working status of the detection device is continuously detected and processed according to the fixed detection interval to obtain multiple detection data. It can be understood that using a fixed detection interval can accurately reflect the changes in multiple detection data, thereby improving the accuracy of the alarm.

[0096] S308 : Perform de-jitter detection processing according to the consistency of the multiple detection data in the window stack to obtain a detection result.

[0097] For example, the detection data may be normal or abnormal, and the consistency of multiple detection data indicates whether the multiple detection data are all normal or all abnormal. The consistency judgment can eliminate the interference of instantaneous jitter on the alarm, thereby improving the accuracy of the alarm.

[0098] A feasible implementation method can perform de-jitter detection processing to obtain a detection result by the following method, including: if multiple detection data in the window stack are different, clearing the window stack, and re-performing continuous detection processing on the working status of the detection device and adding the detection data to the window stack until the multiple detection data in the window stack are the same; if the multiple detection data in the window stack are the same, and the multiple detection data in the window stack are all working normally, then determining that the detection result is normal detection; if the multiple detection data in the window stack are the same, and the multiple detection data in the window stack are all working abnormally, then determining that the detection result is abnormal detection.

[0099] For example, if multiple detection data in the window stack are different, that is, normal and abnormal data exist in multiple detection data at the same time, it means that the working state of the device to be detected is in a transitional state of jitter. At this time, de-jitter detection processing is performed, that is, no alarm is issued for the jitter until the jitter is eliminated, so as to avoid jitter interference alarm. All detection data in the window stack are cleared, and new detection data are added in sequence until the detection data in the window stack are the same, indicating that the jitter has been eliminated, and alarm processing can be performed at this time.

[0100] For example, if multiple detection data in the window stack are the same and all the detection data in the window stack are working normally, it means that the working state of the device to be detected has stabilized and is in a normal working state, and the detection result can be determined to be normal.

[0101] For example, if multiple detection data in the window stack are the same and all of the detection data in the window stack are abnormal, it means that the working state of the device to be detected is abnormal and no longer changes, and the detection result can be determined to be abnormal.

[0102] Next, combine Figure 5 Debounce detection is described.

[0103] Figure 5 This is a schematic diagram of the de-jitter detection provided by the embodiment of the present application. Figure 5As shown, a window stack is set up and in-place detection is performed. If there is an in-place abnormality, multiple abnormality identifiers are added to the window stack to indicate that an abnormality currently exists. Next, the lighting strategy is executed and debounce detection is not required. If the in-place detection is normal, continuous detection processing is performed to obtain multiple detection data, and the detection data is added to the window stack. If the number of detection data in the window stack reaches the target window width, it is determined whether the window stack data is consistent. If not, the window stack is cleared and the detection data is re-added to the window stack. If the window stack data is consistent, it is determined whether the latest detection data in the detection data is the same as the data in the window stack. If they are the same, the lighting strategy is executed. If they are not the same, the window stack is cleared and the detection data is re-added to the window stack. If the window stack data is not full, it is determined whether the window stack data is consistent. If not, the window stack is cleared and the detection data is re-added to the window stack. If they are consistent, the lighting strategy is executed. In the lighting strategy, if the window stack data is not full, it means that there is less detection data or the detection request only specifies a small number of detection times. To avoid false alarms, a second light is displayed to indicate that the device is normal. If the window stack data is full, the detection data in the window stack is judged to be normal or abnormal. If it is normal, the second light is displayed; if it is abnormal, the first light indicating the device abnormality is displayed.

[0104] In this feasible implementation, the stability of the detection data in the window stack can be determined based on the consistency of the multiple detection data, and whether the jitter is eliminated can be determined based on the stability, thereby improving the accuracy of the detection result.

[0105] A feasible implementation method, the alarm method also includes: determining a first delay time corresponding to the device to be detected; if multiple detection data in the window stack are the same, and multiple detection data in the window stack are all working abnormalities, then after the first delay time, the working status of the device to be detected is detected and processed to obtain a detection result.

[0106] Exemplarily, the first delay duration is used to further verify the fault to avoid misjudging jitter as a fault.

[0107] In this scenario example, when the operating status of the device under test is abnormal and no longer changes, the test result of the device under test is temporarily not considered abnormal. After a delay of a certain period, namely the first delay period, the operating status of the device under test is tested and processed to obtain test data. If the test data at this time still shows abnormality, it means that the abnormality cannot be automatically eliminated, and it can be determined that the device under test is faulty. If the test data at this time changes to normal, it means that the abnormality of the device under test has been eliminated, and it can be determined that the abnormality of the device under test is caused by jitter.

[0108] In this feasible implementation, further verification processing is performed on the anomaly through the first delay period, and jitter can be effectively identified based on the result of the further verification, thereby improving the accuracy of the alarm.

[0109] A feasible implementation method can determine the first delay duration of the device to be detected by the following method, including: determining the historical jitter records and historical delay durations of the device to be detected; determining the delay duration mapping relationship table and the delay duration reference value; determining the delay duration offset value corresponding to the device to be detected based on the historical jitter records, historical delay durations, and the delay duration mapping relationship table; determining the first delay duration based on the delay duration reference value and the delay duration offset value.

[0110] Exemplarily, the historical jitter record includes multiple jitter records that occurred in the history of the device to be detected, including the time corresponding to each jitter record.

[0111] Exemplarily, the delay duration offset value indicates the degree of offset of the first delay duration relative to the delay duration reference value.

[0112] Optionally, the delay duration mapping relationship table is used to map out matching delay duration offset values ​​according to historical jitter records and historical delay durations.

[0113] Combined with the scenario example, the frequency and / or regularity of historical jitter can be determined through historical jitter records. If historical jitter occurs frequently, it means that the device to be tested is prone to jitter, and the test results of the device to be tested should be strictly verified, that is, a longer first delay time should be set to avoid judging the jitter as a fault. If historical jitter occurs regularly, for example, jitter occurs at a high frequency in a period of time or jitter occurs at a low frequency in a period of time, and the periods alternate, then strict verification should be performed in the period of high-frequency jitter, and loose verification should be performed in the period of low-frequency jitter. The historical delay time is the delay time that has been used and can be used for reference. The longer the historical delay time, the more the device to be tested needs to be de-jittered, and the first delay time can be increased. The window width mapping relationship table is used to reflect the reference relationship between historical jitter records and historical delay time to the first delay time.

[0114] Exemplarily, the first delay duration is the sum of the delay duration reference value and the delay duration offset value.

[0115] In this feasible implementation, the first delay duration is dynamically determined based on historical jitter records and historical delay durations, so that the first delay duration can better match the jitter occurrence of the device to be detected, improve the accuracy of jitter recognition, and thus improve the accuracy of the alarm.

[0116] A feasible implementation method. Alarm processing can be performed using the following method, including: if the detection result is normal and the detection data all indicate normal operation, or if the working status is normal, then alarm processing is performed based on the device type of the device to be detected; if the detection result is abnormal and the detection data all indicate abnormal operation, then determining the target indicator light corresponding to the device to be detected, and controlling the target indicator light to display a first light to perform alarm processing.

[0117] Optionally, during alarm processing, the device to be tested can be retested and the alarm processed based on the test results. If the retest results show normal detection and the test data in the window stack are all normal, it indicates that the device to be tested experienced jitter and has recovered. At this point, alarm processing is performed based on the device type to eliminate the device anomaly.

[0118] Combined with the scenario example, if there is an abnormality in the device type, it will not be reflected in the detection data. The detection process cannot detect the abnormality of the device type, and a separate alarm processing is required for the device type.

[0119] For example, if the detection result is abnormal and the detection data are all abnormal, it means that the detection data in the window stack has been abnormal continuously. If the abnormality is still found after re-detection, it is considered that the abnormality is caused by a fault and cannot be recovered by itself. In this case, a clear alarm result is obtained, and the alarm result is reflected by the light.

[0120] Exemplarily, the first light indicates that a fault occurs in the device to be detected.

[0121] In conjunction with the scenario example, a corresponding indicator light can be set for each device to be detected, or a common indicator light can be set for multiple devices to be detected. In the scenario where multiple devices to be detected share a common indicator light, if at least one device to be detected is abnormal, the common indicator light will display the first light. Taking the example of setting a corresponding indicator light for each device to be detected, the indicator light corresponding to the cooling fan will display the working status of the cooling fan, the indicator light corresponding to the power supply will display the working status of the power supply, the indicator light corresponding to the CPU will display whether the CPU is overheating or temperature loss, etc., the indicator light corresponding to the switching chip will display whether the switching chip is overheating or temperature loss, etc., the indicator light corresponding to the Basic Input / Output System (BIOS) will display whether the Basic Input / Output System has started abnormally, and the indicator light corresponding to the controller will display whether the controller has started abnormally.

[0122] In this feasible implementation, the detection data in the integrated window stack and the results of the re-detection process can reduce the error in fault judgment, thereby improving the accuracy of alarm processing.

[0123] A feasible implementation method can perform alarm processing according to the device type of the device to be detected through the following method, including: determining the current device type and preset device type corresponding to the device to be detected; performing device type detection processing on the device to be detected according to the current device type and the preset device type to obtain a device type detection result, and the device type detection result is that the device type is normal or the device type is abnormal; if the device type detection result is that the device type is abnormal, controlling the target indicator light to display a first light for alarm processing; if the device type detection result is that the device type is normal, controlling the target indicator light to display a second light to indicate that the device to be detected is a normal device, and the second light is different from the first light.

[0124] For example, device type detection is used to detect whether the device to be detected is used in accordance with preset requirements. Device type detection can detect anomalies that are not detected by debounce detection processing. Device type detection is used to detect and process the device to be detected from another dimension.

[0125] For example, different lights are displayed through lighting strategies, and different lights are used to indicate different equipment states to operation and maintenance personnel.

[0126] Optionally, the presence detection may be repeated after the debounce detection process to eliminate the situation where the presence information changes from normal to abnormal, thereby improving the accuracy of the alarm.

[0127] Next, combine Figure 6 The lighting strategy is explained.

[0128] Figure 6 This is a schematic diagram of the lighting strategy provided in the embodiment of the present application. Figure 6 As shown, the device to be tested is tested for in-place status. If the in-place status is abnormal, no light is displayed. If the in-place status is normal, the operating status is further determined. If the operating status is normal, the device type is detected. If the operating status is abnormal, debounce detection is performed, and after debounce detection, the in-place test is repeated. If the in-place detection is normal, an alarm is generated based on the detection result of the debounce detection. If the detection result is abnormal, the first light is displayed. If the detection result is normal, the type detection is performed. If the device type detection result is normal, the second light is displayed. If the device type detection result is abnormal, the first light is displayed.

[0129] In this feasible implementation, alarm processing is performed by combining device type detection and debounce detection, which can comprehensively detect the devices to be detected, thereby improving the accuracy of the alarm.

[0130] In a feasible implementation, the current device type includes at least one of the following: a device power supply type, a device identifier, or a device direction.

[0131] In related technologies, after confirming the presence of a device, the device type is not detected. This can lead to situations where the device's operating parameters are stable but the device type is abnormal, causing the device to malfunction. Failure to detect this can result in missed alarms, impacting the device's use or affecting other devices.

[0132] In this scenario example, the device power supply type can be a power source, specifically including direct current (DC), alternating current (AC), power supply voltage, or power supply current. The device identifier can be the device model, serial number, or identification code. The device orientation can be a cooling fan, specifically including the direction of fan blade rotation (forward or reverse).

[0133] In this feasible implementation, by setting up multiple current devices for detection, it is possible to determine whether the device to be detected is working normally from multiple dimensions, thereby reducing the problem of missed alarms and improving the accuracy of alarms.

[0134] A feasible implementation method is to perform de-jitter detection processing on the device to be detected to obtain the detection result, and also includes: determining a second delay time corresponding to the device to be detected; after the second delay time, performing de-jitter detection processing on the device to be detected to obtain the detection result.

[0135] For example, the second delay period is used before the de-jitter detection process to filter the jitter of the device to be detected and provide a buffer period for the jitter. If the detection result obtained after the second delay period is still abnormal, the possibility of jitter can be ruled out.

[0136] In this feasible implementation, by setting the second delay time, it is possible to further avoid misjudging jitter as a fault, thereby improving the accuracy of the alarm.

[0137] A feasible implementation method is that the device to be detected is a controller, and the alarm method also includes: performing de-jitter detection processing on the controller to determine whether the controller fails to start from both the primary and backup flash memories; if so, controlling the target indicator light to display the first light for alarm processing; if not, detecting and processing the startup method of the controller to obtain a startup detection result, and performing alarm processing based on the startup detection result.

[0138] In the related art, for a controller, if startup fails, an alarm is directly issued according to the fault. However, the startup process of the controller includes various situations, and direct alarm has the problem of low accuracy.

[0139] Optionally, the controller may be a baseboard management controller or a basic input / output system, etc., which is not limited in this application.

[0140] In this scenario example, if the controller fails to boot from the primary flash memory, it automatically attempts to boot from the backup flash memory. If the backup flash memory still fails, the controller stops booting and determines a fault, triggering an alarm through the first light. The process of switching from primary flash memory to backup flash memory can involve various situations. By detecting and determining the specific situation and issuing an alarm, the corresponding situation can be accurately reflected, allowing operation and maintenance personnel to quickly locate the problem of the device under inspection.

[0141] In this feasible implementation, specific detection processing is performed on the startup mode of the controller, so that the alarm processing can accurately reflect the corresponding startup situation, thereby improving the accuracy of the alarm.

[0142] A feasible implementation method, the startup detection result includes successful startup from the main flash memory, startup from the backup flash memory, and successful startup from the backup flash memory; alarm processing is performed according to the startup detection result, including: if the startup detection result is successful startup from the main flash memory, controlling the target indicator light to display the second light; if the startup detection result is startup from the backup flash memory, controlling the target indicator light to flash and display a third light, the third light being different from the second light; if the startup detection result is successful startup from the backup flash memory, controlling the target indicator light to display the third light.

[0143] Next, combine Figure 7 Describes controller alarms.

[0144] Figure 7 This is a schematic diagram of a controller alarm provided in an embodiment of the present application. Figure 7 As shown, the device to be tested is de-jittered to eliminate jitter. If the test result shows that booting from both the primary and backup flash memories fails, the first light indicating a device abnormality is displayed. If booting from the primary flash memory fails and the device to be tested is booting from the backup flash memory, the third light flashes to remind the operator that the device is currently in the boot process. If booting from the primary flash memory fails but booting from the backup flash memory succeeds, the device to be tested has completed the boot and can operate normally. The third light is displayed to remind the operator that there is a fault in the primary flash memory to avoid missing alarms. If booting from the primary flash memory succeeds, the second light is displayed to indicate that the device to be tested is normal.

[0145] In this feasible implementation, different startup states of the device to be detected are respectively displayed with corresponding lights for alarm processing, which can accurately reflect the startup state of the device to be detected, thereby improving the accuracy of the alarm.

[0146] A feasible implementation method is that the number of devices to be detected is multiple, and the alarm method also includes: performing de-jitter detection processing on the multiple devices to be detected to obtain multiple detection results; if the multiple detection results are that the devices are normal, the indicator light of the whole machine is controlled to display the second light; if there is at least one detection result among the multiple detection results that the device is abnormal, the indicator light of the whole machine is controlled to display the first light.

[0147] For example, if there are multiple devices to be detected, and the multiple devices to be detected share one whole-machine indicator light, then the whole-machine indicator light reflects the fault conditions of the multiple devices to be detected.

[0148] In this scenario, let's take a cooling fan group as an example. A cooling fan group corresponds to one device indicator. A cooling fan group includes multiple cooling fans, and the device to be tested has multiple cooling fans. If all cooling fans are normal, the second light is displayed. If all cooling fans are abnormal, the first light is displayed. If some of the multiple cooling fans are abnormal, the second light is displayed.

[0149] Combined with the scenario example, take the whole machine as an example. The whole machine includes multiple devices to be detected. The working status of the whole machine is displayed by the whole machine indicator light. First, it is detected whether the CPU is overheated or the CPU temperature is lost. If it is overheated or lost, the debounce detection process is performed to determine whether the CPU is overheated or the CPU temperature is lost. If it is overheated or lost, the whole machine indicator light is set to display the first light; otherwise, further detect whether the switching chip is overheated or the switching chip temperature is lost. If it is overheated or lost, the debounce detection process is performed to determine whether the switching chip is overheated or the switching chip temperature is lost. If it is overheated or lost, the whole machine indicator light is set to display the first light; otherwise, further detect whether the multiple cooling fans are all in abnormal status. If the status is abnormal, the debounce detection process is performed to determine whether the multiple cooling fans are all in abnormal status. If the status is abnormal, the whole machine indicator light is set to display the first light; otherwise, further detect whether the multiple in-place power supplies are all in abnormal status. If the status is abnormal, the debounce detection process is performed Determine whether multiple in-place power supplies are all in abnormal status. If all are abnormal, set the whole machine indicator light to display the first light; otherwise, further detect whether the basic input and output system fails to boot from the primary and backup flash memories. If so, set the whole machine indicator light to display the first light; otherwise, further detect whether the basic input and output system fails to boot from the primary flash memory and is booting from the backup flash memory, set the whole machine indicator light to display the first light; otherwise, further detect whether the basic input and output system fails to boot from the primary flash memory but successfully boots from the backup flash memory, set the whole machine indicator light to display the third light; otherwise, further detect whether the controller fails to boot from the primary and backup flash memories. If so, set the whole machine indicator light to display the first light; otherwise, further detect whether the controller fails to boot from the primary flash memory and is booting from the backup flash memory, set the whole machine indicator light to flash and display the third light; otherwise, further detect whether the controller fails to boot from the primary flash memory but successfully boots from the backup flash memory, set the whole machine indicator light to display the third light; otherwise, set the whole machine indicator light to display the second light.

[0150] In this feasible implementation, alarm processing is performed for abnormal display of corresponding lights for some detection devices among multiple devices to be detected. The abnormality of some detection devices can be accurately reflected through an indicator light, thereby improving the accuracy of the alarm.

[0151] Through the description of the above implementation methods, those skilled in the art can clearly understand that the method according to the above embodiment can be implemented by means of software plus the necessary general hardware platform, and of course it can also be implemented by hardware, but in many cases the former is a better implementation method.

[0152] Figure 8 This is a schematic diagram of the structure of the alarm device provided in the embodiment of the present application. Figure 8As shown, an embodiment of the present application further provides an alarm device, the alarm device 80 may include: a receiving module 81, a determining module 82, an acquiring module 83, and a detecting module 84, wherein:

[0153] The receiving module 81 is configured to receive a detection request, where the detection request includes at least one identification of a device to be detected.

[0154] The determination module 82 is configured to determine, according to the detection request, at least one device to be detected corresponding to at least one device to be detected identifier.

[0155] The acquisition module 83 is used to determine the working status of the device to be detected.

[0156] The detection module 84 is used to perform de-jitter detection processing on the device to be detected to obtain a detection result if the working status is abnormal, and perform alarm processing according to the detection result.

[0157] Optionally, the receiving module 81 may execute Figure 2 S201 in the embodiment.

[0158] Optionally, the determination module 82 may execute Figure 2 S202 in the embodiment.

[0159] Optionally, the acquisition module 83 may execute Figure 2 S203 in the embodiment.

[0160] Optionally, the detection module 84 may execute Figure 2 S204 in the embodiment.

[0161] It should be noted that the alarm device shown in the embodiment of the present application can execute the technical solution shown in the above method embodiment, and its implementation principle and beneficial effects are similar, which will not be repeated here.

[0162] In a possible implementation, the detection module 84 is specifically configured to:

[0163] Determine the window stack and target window width corresponding to the device to be detected. The window stack is used to temporarily store detection data, and the target window width is the upper limit of the amount of detection data temporarily stored in the window stack.

[0164] According to the target window width, the device to be detected is debounced and detected to obtain the detection result.

[0165] In a possible implementation, the detection module 84 is specifically configured to:

[0166] Determine the historical alarm records and historical window width of the equipment to be tested;

[0167] Determine a window width mapping relationship table and a window width reference value;

[0168] Determine the window width offset value corresponding to the device to be detected based on historical alarm records, historical window widths, and a window width mapping relationship table;

[0169] Determine the target window width based on the window width reference value and the window width offset value.

[0170] In a possible implementation, the detection module 84 is specifically configured to:

[0171] Continuously detect the working status of the device to be detected, obtain multiple detection data, and add the multiple detection data to the window stack. The detection data is normal or abnormal.

[0172] De-jitter detection processing is performed based on the consistency of multiple detection data in the window stack to obtain a detection result.

[0173] In a possible implementation, the detection module 84 is specifically configured to:

[0174] If the multiple detection data in the window stack are not the same, the window stack is cleared, and the working status of the device to be detected is continuously detected again and the detection data is added to the window stack until the multiple detection data in the window stack are the same;

[0175] If the plurality of detection data in the window stack are the same and the plurality of detection data in the window stack are all working normally, then the detection result is determined to be normal;

[0176] If the plurality of detection data in the window stack are the same, and the plurality of detection data in the window stack are all abnormal, then the detection result is determined to be abnormal.

[0177] Figure 9 This is a schematic diagram of the structure of an alarm device provided in an embodiment of the present application. Figure 8 Based on the embodiment shown, Figure 9 As shown, the alarm device 90 further includes: an execution module 85, a delay module 86, a judgment module 87, an in-position detection module 88, a startup detection module 89, and a whole machine detection module 810, wherein:

[0178] The execution module 85 is used to:

[0179] Determine a first delay duration corresponding to the device to be detected;

[0180] If the multiple detection data in the window stack are the same and all the detection data in the window stack are abnormal, then after a first delay time, the working state of the device to be detected is detected and processed to obtain a detection result.

[0181] In a possible implementation, the execution module 85 is specifically configured to:

[0182] Determine the historical jitter records and historical delay duration of the device to be tested;

[0183] Determine the delay duration mapping relationship table and the delay duration benchmark value;

[0184] Determine the delay offset value corresponding to the device to be tested based on historical jitter records, historical delay durations, and a delay duration mapping relationship table;

[0185] A first delay duration is determined according to the delay duration reference value and the delay duration offset value.

[0186] In a possible implementation, the execution module 85 is specifically configured to:

[0187] If the test result is normal and the test data are all working normally, or if the working status is working normally, an alarm is processed according to the device type of the device to be tested;

[0188] If the detection result is abnormal detection and the detection data are all abnormal operation, the target indicator light corresponding to the device to be detected is determined, and the target indicator light is controlled to display the first light for alarm processing.

[0189] In a possible implementation, the execution module 85 is specifically configured to:

[0190] Determine the current device type and the preset device type corresponding to the device to be detected;

[0191] The execution module is further configured to perform device type detection on the device to be detected according to the current device type and the preset device type, and obtain a device type detection result, wherein the device type detection result is a normal device type or an abnormal device type;

[0192] The execution module is further configured to control the target indicator light to display a first light for alarm processing if the device type detection result is that the device type is abnormal;

[0193] The execution module is further configured to control the target indicator light to display a second light to indicate that the device to be detected is a normal device if the device type detection result is that the device type is normal, and the second light is different from the first light.

[0194] In a possible implementation, the current device type includes at least one of the following: a device power supply type, a device identifier, or a device direction.

[0195] The delay module 86 is used to:

[0196] Determine a second delay time corresponding to the device to be detected;

[0197] After the second delay time, the device to be detected is de-jittered and detected to obtain a detection result.

[0198] The judgment module 87 is used to:

[0199] Obtaining a working strategy message of the device to be detected, where the working strategy message includes a current working strategy to be executed by the device to be detected;

[0200] Determine the historical working strategy of the equipment to be tested;

[0201] If the current working strategy is the same as the historical working strategy, the working status of the device to be detected is determined.

[0202] In a possible implementation, the determination module 87 is specifically configured to:

[0203] Perform in-situ detection on the device to be detected to obtain in-situ information of the device to be detected, which can be normal or abnormal.

[0204] If the in-place information indicates that the device is in place and normal, the working status of the device to be detected is determined.

[0205] The presence detection module 88 is used to:

[0206] If the in-position information indicates an in-position abnormality, the target indicator light will be controlled to not display light.

[0207] The device to be detected is a controller, and the detection module 89 is started to:

[0208] Perform debounce detection on the controller to determine whether the controller fails to boot from both the primary and backup flash memories;

[0209] If yes, the target indicator light is controlled to display a first light for warning processing;

[0210] If not, the startup mode of the controller is detected to obtain a startup detection result, and an alarm is processed according to the startup detection result.

[0211] In a possible implementation, the boot detection result includes successful booting from the primary flash memory, intermediate booting from the backup flash memory, and successful booting from the backup flash memory; the boot detection module 89 is specifically configured to:

[0212] If the startup detection result is that the startup from the main flash memory is successful, the target indicator light is controlled to display the second light;

[0213] If the startup detection result is that it is booting from the backup flash memory, the target indicator light will be controlled to flash and display a third light, which is different from the second light;

[0214] If the startup detection result is that the startup from the backup flash memory is successful, the target indicator light is controlled to display the third light.

[0215] There are multiple devices to be tested, and the whole device testing module 810 is used to:

[0216] Perform debounce detection on multiple devices to be detected to obtain detection results corresponding to each device to be detected;

[0217] If the test results corresponding to each device to be tested are all normal, the indicator light of the whole device will be controlled to display the second light;

[0218] If the test results corresponding to each device to be tested are all abnormal, the indicator light of the whole device will be controlled to display the first light;

[0219] If part of the test results corresponding to each device to be tested shows that the device is abnormal, the indicator light of the entire device is controlled to display the third light.

[0220] For the description of the features in the embodiment corresponding to the alarm device, please refer to the relevant description of the embodiment corresponding to the alarm method, and no further details will be given here.

[0221] Figure 10 This is a schematic diagram of the structure of the electronic device provided in this application. Figure 10 As shown, the electronic device 100 provided in this embodiment includes: at least one processor 1001 and a memory 1002. Optionally, the electronic device 100 further includes a communication component 1003. The processor 1001, the memory 1002 and the communication component 1003 are connected via a bus.

[0222] During the specific implementation process, at least one processor 1001 executes the computer execution instructions stored in the memory 1002, so that the at least one processor 1001 executes the above-mentioned alarm method embodiment.

[0223] The specific implementation process of the processor 1001 can be found in the above method embodiment. Its implementation principle and technical effects are similar and will not be repeated here in this embodiment.

[0224] In the above embodiments, it should be understood that the processor may be a central processing unit (CPU), other general-purpose processors, digital signal processors (DSP), application-specific integrated circuits (ASIC), etc. A general-purpose processor may be a microprocessor or any conventional processor. The steps of the method disclosed in the application may be directly executed by a hardware processor or by a combination of hardware and software modules within the processor.

[0225] The memory may include random access memory (RAM) and may also include non-volatile memory (NVM), such as at least one disk storage.

[0226] A bus can be an Industry Standard Architecture (ISA) bus, a Peripheral Component Interconnect (PCI) bus, or an Extended Industry Standard Architecture (EISA) bus. Buses can be categorized as address buses, data buses, and control buses. For ease of illustration, the buses in the drawings of this application are not limited to just one bus or just one type of bus.

[0227] An embodiment of the present application further provides a computer-readable storage medium, in which a computer program is stored. The computer program is configured to execute the steps of any of the above-mentioned alarm method embodiments when running.

[0228] In an exemplary embodiment, the computer-readable storage medium may include, but is not limited to, various media that can store computer programs, such as a USB flash drive, a read-only memory (ROM), a random access memory (RAM), a mobile hard disk, a magnetic disk, or an optical disk.

[0229] An embodiment of the present application further provides a computer program product, which includes a computer program. When the computer program is executed by a processor, the steps in any of the above-mentioned alarm method embodiments are implemented.

[0230] An embodiment of the present application further provides another computer program product, including a non-volatile computer-readable storage medium, wherein the non-volatile computer-readable storage medium stores a computer program, and when the computer program is executed by a processor, the steps in any of the above-mentioned alarm method embodiments are implemented.

[0231] Professionals may further appreciate that the units and algorithm steps of each example described in conjunction with the embodiments disclosed herein can be implemented in electronic hardware, computer software, or a combination of the two. In order to clearly illustrate the interchangeability of hardware and software, the above description has generally described the components and steps of each example according to their functions. Whether these functions are performed in hardware or software depends on the specific application and design constraints of the technical solution. Professionals and technicians may use different methods to implement the described functions for each specific application, but such implementation should not be considered beyond the scope of this application.

[0232] The above is a detailed introduction to an alarm method, device, electronic device, medium and product provided by the present application. Specific examples are used herein to illustrate the principles and implementation methods of the present application. The description of the above embodiments is only used to help understand the method and core idea of ​​the present application. It should be pointed out that for ordinary technicians in this technical field, without departing from the principles of the present application, several improvements and modifications can be made to the present application, and these improvements and modifications also fall within the scope of protection of the claims of the present application.

Claims

1. An alarm method, characterized in that: include: receiving a detection request, wherein the detection request includes at least one identification of a device to be detected; Determining, according to the detection request, at least one device to be detected corresponding to the at least one device to be detected identifier; Determining the working status of the device to be detected; If the working state is abnormal, debounce detection processing is performed on the device to be detected to obtain a detection result; if the detection result is normal and the detection data are all normal, or if the working state is normal, the current device type and the preset device type corresponding to the device to be detected are determined, where the current device type includes at least one of the following: device power supply type, device identification, and device direction; Performing device type detection on the device to be detected according to the current device type and the preset device type to obtain a device type detection result, wherein the device type detection result is that the device type is normal or the device type is abnormal; If the device type detection result is that the device type is abnormal, the target indicator light corresponding to the device to be detected is controlled to display a first light to perform an alarm process.

2. The alarm method according to claim 1, characterized in that: Performing debounce detection processing on the device to be detected to obtain a detection result, including: Determine a window stack and a target window width corresponding to the device to be detected, wherein the window stack is used to temporarily store detection data, and the target window width is an upper limit on the amount of detection data temporarily stored in the window stack; According to the target window width, de-jitter detection processing is performed on the device to be detected to obtain the detection result.

3. The alarm method according to claim 2, characterized in that: Determining the target window width corresponding to the device to be detected includes: Determine the historical alarm records and historical window width of the device to be detected; Determine a window width mapping relationship table and a window width reference value; Determine the window width offset value corresponding to the device to be detected according to the historical alarm record, the historical window width, and the window width mapping relationship table; The target window width is determined according to the window width reference value and the window width offset value.

4. The alarm method according to claim 3, characterized in that: Performing debounce detection processing on the device to be detected according to the target window width to obtain the detection result includes: Continuously detecting the working state of the device to be detected to obtain a plurality of detection data, and adding the plurality of detection data to the window stack, wherein the detection data is normal or abnormal; De-jitter detection processing is performed according to the consistency of multiple detection data in the window stack to obtain the detection result.

5. The alarm method according to claim 4, characterized in that: Performing de-jitter detection processing according to consistency of multiple detection data in the window stack to obtain the detection result includes: If the plurality of detection data in the window stack are not identical, the window stack is cleared, and the working state of the device to be detected is continuously detected again and the detection data is added to the window stack until the plurality of detection data in the window stack are identical; If the plurality of detection data in the window stack are the same and the plurality of detection data in the window stack are all working normally, determining that the detection result is normal; If the plurality of detection data in the window stack are the same, and the plurality of detection data in the window stack are all abnormal, then the detection result is determined to be abnormal.

6. The alarm method according to claim 5, characterized in that: The method further comprises: Determine a first delay duration corresponding to the device to be detected; If the multiple detection data in the window stack are the same and all the detection data in the window stack are abnormal, then after the first delay time, the working status of the device to be detected is detected to obtain a detection result.

7. The alarm method according to claim 6, characterized in that: Determining a first delay duration corresponding to the device to be detected includes: Determine the historical jitter records and historical delay duration of the device to be detected; Determine the delay duration mapping relationship table and the delay duration benchmark value; Determine the delay duration offset value corresponding to the device to be detected according to the historical jitter record, the historical delay duration, and the delay duration mapping relationship table; The first delay duration is determined according to the delay duration reference value and the delay duration offset value.

8. The alarm method according to claim 6, characterized in that: Also includes: If the detection result is a detection abnormality and the detection data are all working abnormalities, the target indicator light corresponding to the device to be detected is determined, and the target indicator light is controlled to display a first light for alarm processing.

9. The alarm method according to claim 8, characterized in that: Also includes: If the device type detection result is that the device type is normal, the target indicator light is controlled to display a second light to indicate that the device to be detected is a normal device, and the second light is different from the first light.

10. The alarm method according to claim 1, characterized in that: Performing debounce detection processing on the device to be detected to obtain a detection result, including: Determining a second delay duration corresponding to the device to be detected; After the second delay period, de-jitter detection processing is performed on the device to be detected to obtain the detection result.

11. The alarm method according to claim 1, characterized in that: Determining the working status of the device to be detected includes: Obtaining a working strategy message of the device to be detected, wherein the working strategy message includes a current working strategy instructing the device to be detected to execute; Determining a historical working strategy of the device to be detected; If the current working strategy is the same as the historical working strategy, the working status of the device to be detected is determined.

12. The alarm method according to claim 11, characterized in that: Determining the working status of the device to be detected further includes: Performing an in-situ detection process on the device to be detected to obtain in-situ information of the device to be detected, wherein the in-situ information indicates that the device is in-situ normal or in-situ abnormal; If the in-place information indicates that the device is in-place and normal, the working status of the device to be detected is determined.

13. The alarm method according to claim 12, characterized in that: The method further comprises: If the in-position information indicates an in-position abnormality, the target indicator light is controlled not to display light.

14. The alarm method according to claim 1, characterized in that: The device to be detected is a controller, and the method further includes: Performing a debounce detection process on the controller to determine whether the controller fails to start from both the primary and backup flash memories; If yes, the target indicator light is controlled to display a first light for warning processing; If not, the startup mode of the controller is detected to obtain a startup detection result, and an alarm is performed according to the startup detection result.

15. The alarm method according to claim 14, characterized in that: The startup detection result includes successful startup from the main flash memory, startup from the backup flash memory, and successful startup from the backup flash memory; Performing alarm processing according to the startup detection result includes: If the startup detection result is that the startup from the main flash memory is successful, controlling the target indicator light to display a second light; If the startup detection result is that the system is starting from the backup flash memory, the target indicator light is controlled to flash and display a third light, which is different from the second light; If the startup detection result is that the startup from the backup flash memory is successful, the target indicator light is controlled to display the third light.

16. The alarm method according to claim 1, characterized in that: There are multiple devices to be detected, and the method further includes: Perform debounce detection on multiple devices to be detected to obtain detection results corresponding to each device to be detected; If the detection results corresponding to each of the devices to be detected are all normal, controlling the indicator light of the entire device to display a second light; If the detection results corresponding to each of the devices to be detected are all abnormal, controlling the indicator light of the entire device to display a first light; If part of the detection results corresponding to each device to be detected shows that the device is abnormal, the whole device indicator light is controlled to display a third light.

17. An electronic device, characterized in that: include: memory for storing computer programs; A processor, configured to implement the steps of the alarm method according to any one of claims 1 to 16 when executing the computer program.

18. A computer-readable storage medium, characterized in that The computer-readable storage medium stores a computer program, wherein the computer program, when executed by a processor, implements the steps of the alarm method according to any one of claims 1 to 16.

19. A computer program product comprising a computer program, characterized in that When the computer program is executed by a processor, the steps of the alarm method according to any one of claims 1 to 16 are implemented.

Images