Alarm processing method, system and device, storage medium and program product

Abstract

The invention discloses an alarm processing method, system and device, a storage medium and a program product, and relates to the technical field of computers, and the method comprises the steps: obtaining a configuration file which dynamically configures an alarm filtering rule according to an actual demand after receiving current attribute information set due to sensor alarm, judging whether the current attribute information meets the alarm filtering rule, and if yes, sending the alarm filtering rule to a server; and when the alarm filtering rule is met, the alarm of the sensor is relieved, a series of problems caused by the fact that the alarm cannot be filtered are solved, alarm filtering is performed through the flexible and configurable alarm filtering rule, and the technical effects of reducing redundant log accumulation and improving log management efficiency are achieved.

Description

Technical Field

[0001] The present application relates to the field of computer technology, and in particular to an alarm processing method, system, device, storage medium and program product. Background Art

[0002] With the rapid development of cloud computing and big data, the scale of data centers continues to expand, and the number of server nodes has increased sharply, which has put forward higher requirements for the stability and maintainability of infrastructure. As the core out-of-band management unit of the server, the baseboard management controller (BMC) bears the important responsibility of real-time monitoring of the server hardware status. Among them, the collection and alarm processing of sensor data are the key links to ensure the stable operation of the system.

[0003] However, during the startup and operation of the BMC, some sensor alarms are normal initialization behaviors, non-critical state changes, or non-essential alarms that can be ignored. If all alarms are recorded indiscriminately, a large number of redundant logs will be generated, resulting in inefficient log management. Summary of the invention

[0004] The present application provides an alarm processing method, system, device, storage medium and program product to at least solve the problem of a large number of redundant alarms in the related art.

[0005] The present application provides an alarm processing method, including: Obtain current attribute information and current state information of the target sensor; When the current state information is an alarm state, obtaining a pre-built configuration file, wherein the configuration file includes an alarm filtering rule of the target sensor; When the current attribute information meets the alarm filtering rules, the alarm state of the target sensor is released.

[0006] The present application also provides an alarm processing device, comprising: A first acquisition module, used to acquire current attribute information and current state information of the target sensor; A second acquisition module is used to acquire a pre-built configuration file when the current state information is an alarm state, wherein the configuration file includes an alarm filtering rule of the target sensor; The filtering module is used to release the alarm state of the target sensor when the current attribute information meets the alarm filtering rules.

[0007] The present application also provides an alarm processing system, which includes an alarm processing module, an alarm filtering module and a fault updating module, wherein: The alarm processing module is used to obtain the current attribute information and current status information of the target sensor; The alarm filtering module is used to receive the current attribute information and the current state information transmitted by the alarm processing module, and when the current state information is an alarm state, obtain a pre-built configuration file, wherein the configuration file includes the alarm filtering rules of the target sensor, and determine whether the current attribute information meets the alarm filtering rules. When the current attribute information meets the alarm filtering rules, release the alarm state of the target sensor; The fault update module is used to receive the alarm processing result fed back by the alarm filtering module, and update the fault log of the target sensor based on the alarm processing result.

[0008] 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 processing methods when executing the computer program.

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

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

[0011] Through this application, after receiving the current attribute information set due to the sensor alarm, a configuration file that dynamically configures the alarm filtering rules according to actual needs is obtained, and it is determined whether the current attribute information meets the alarm filtering rules. If the alarm filtering rules are met, the sensor alarm is cleared. Therefore, this application solves the problem of accumulation of redundant alarm logs caused by the inability to filter alarms, and performs alarm filtering through flexible and configurable alarm filtering rules, thereby achieving the technical effect of reducing the accumulation of redundant logs and improving log management efficiency. BRIEF DESCRIPTION OF THE DRAWINGS

[0012] 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 paying any creative work.

[0013] Figure 1 A flowchart of an alarm processing method provided in an embodiment of the present application; Figure 2 A schematic diagram of a sensor status code and event description provided in an embodiment of the present application; Figure 3A schematic diagram of alarm processing and event description provided by an embodiment of the present application; Figure 4 A schematic flowchart of an alarm processing method provided by an embodiment of the present application; Figure 5 A schematic flowchart of an alarm processing device provided by an embodiment of the present application; Figure 6 A schematic structural diagram of an alarm processing system provided by an embodiment of the present application. Detailed implementation manners

[0014] Next, the technical solutions in the embodiments of the present application will be clearly and completely described in conjunction with the accompanying drawings in the embodiments of the present application. Obviously, the described embodiments are only a part of the embodiments of the present application, rather than all the embodiments. Based on the embodiments in the present application, all other embodiments obtained by those of ordinary skill in the art without creative efforts shall fall within the protection scope of the present application.

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

[0016] To enable those skilled in the art of the present technology to better understand the solution of the present application, the present application will be further described in detail below in conjunction with the accompanying drawings and specific implementation manners.

[0017] Combined with the specific application environment architecture or specific hardware architecture on which the execution of the alarm processing method depends, the specific application environment architecture or specific hardware architecture is described herein.

[0018] With the rapid development of information technologies such as cloud computing and big data, the data center, as the key infrastructure supporting the modern information society, has continuously expanded in scale and complexity. To ensure the stable operation of the data center, the monitoring of the hardware health status of server nodes has become particularly important. In this context, the BMC (Baseboard Management Controller) serves as the core out-of-band management unit of the server and undertakes the important responsibility of remotely monitoring and managing hardware resources.

[0019] BMC collects various hardware status information through sensors, and generates alarm logs based on set thresholds or status changes to timely detect potential faults and assist in operation and maintenance decisions. Among them, sensors are mainly divided into threshold sensors and discrete sensors. Threshold sensors are used to monitor continuously changing physical quantities, such as temperature, voltage, current, power, etc.; discrete sensors reflect the existence of equipment or whether specific events have occurred in the form of binary or status codes, such as power supply status, abnormal fan speed, AC input loss, etc.

[0020] However, in actual applications, it is found that during the startup and normal operation of the BMC, some sensor alarms are normal behaviors in the system initialization phase, such as the memory and fan status alarms; at the same time, although some threshold alarms exceed the preset range, they do not affect the overall performance of the server. Users do not want to record them in the alarm log, nor do they want such alarms to affect the overall health status assessment of the server. Since the existing BMC lacks an effective dynamic alarm filtering mechanism, all sensor alarms are uniformly processed and recorded in the System Event Log (SEL), resulting in a large number of redundant logs. Such redundant logs not only waste storage space, but also increase the difficulty of log analysis and troubleshooting, and reduce operation and maintenance efficiency. This problem is particularly prominent in large-scale data center environments, which seriously restricts the further development of intelligent operation and maintenance systems.

[0021] In the current BMC-based server hardware monitoring system, the sensor alarm mechanism has several key defects, which affects the flexibility, maintainability and intelligent management level of the system.

[0022] First, threshold sensors rely on fixed thresholds to determine alarm states and lack dynamic adaptability. For example, although the outlet temperature exceeds the preset CriticalHigh threshold, the user believes that this abnormal value does not affect the overall performance of the server and does not want to record it as a valid alarm. However, the existing system cannot dynamically adjust the filtering strategy according to the actual operating environment or user needs, and can only circumvent the problem by modifying the original threshold, which will destroy the original sensor logic rules and does not meet the requirements of engineering practice.

[0023] Secondly, the discrete sensor's handling of the Offset in EventData (status code) is rigid and difficult to meet flexible filtering requirements. For example, the PSU (Power Supply Unit) in-place event is a normal initialization behavior during the BMC startup phase, but the system still generates redundant log records. The existing solution only supports manually modifying the json file to shield the alarm information corresponding to a specific Offset, lacks an application layer interface for configuration management, and the modified content cannot be persisted.

[0024] Furthermore, the static nature of alarm filtering rules seriously restricts system flexibility. Whether it is a threshold-type or discrete sensor, its alarm rules are statically fixed in the system, and it is impossible to enable or disable specific alarm items on demand during runtime. If users need to change sensor behavior, they can only do so by modifying the underlying file. The lack of a unified and standardized application layer control interface reduces operation and maintenance efficiency and automation.

[0025] Finally, the relevant technology lacks a complete persistent storage and recovery mechanism. When users modify the json file through the BMC console to implement alarm filtering, since the path of the json file is located in the system read-only file system, it will be erased and reset to the default configuration when the BMC is restored to factory settings or the firmware is upgraded, resulting in the loss of user-defined sensor alarm rules and the system state being restored to the initial state, which seriously affects configuration consistency and long-term availability.

[0026] In summary, the existing BMC sensor alarm mechanism has obvious deficiencies in flexibility, configurability and persistence, and it is difficult to meet the needs of modern data centers for refined and intelligent hardware management.

[0027] In response to the above technical problems, the present application provides a dynamic alarm processing method and a flexible and configurable alarm filtering mechanism. It can effectively block unnecessary alarms without affecting the reporting of key alarms, reduce redundant logs, improve log quality and system management efficiency, and realize persistent storage of configuration files.

[0028] Before explaining the present application in detail, it is preferred to explain the technical terms involved.

[0029] A baseboard management controller (BMC) is a dedicated microcontroller embedded on the server motherboard and is used to remotely monitor and manage the hardware status of the server.

[0030] The System Event Log (SEL) is an important component of the BMC used to record server hardware status and events. It mainly collects and stores data and alarm information from various sensors through the IPMI protocol.

[0031] Intelligent Platform Management Interface (IPMI) is a standardized hardware management interface protocol used to monitor and manage the hardware status of a server. Even if the operating system crashes or the system is shut down, it can remotely monitor, record alarms, and control power on the server out-of-band.

[0032] The Desktop Bus (D-Bus) is an inter-process communication mechanism in the Linux system, which is used to efficiently and securely transfer messages between different applications or services.

[0033] Redfish is an open standard hardware management interface specification developed by the DMTF, aiming to provide a unified, secure, and scalable way to remotely manage IT infrastructure such as servers, storage devices, and network devices.

[0034] The Distributed Management Task Force (DMTF) is a global industry organization dedicated to promoting the standardization of IT system management.

[0035] The Power Supply Unit (PSU) is an important component in electronic devices, mainly used to convert the input alternating current (AC) into stable direct current (DC) for the various components inside the device to use.

[0036] The Intelligent Platform Management Interface (IPMI) is an open standard hardware management interface specification, commonly used in servers and workstations.

[0037] The embodiments of this application provide an alarm processing method, which is described in detail in combination with the execution process of the alarm processing method.

[0038] Figure 1 It is a schematic flowchart of an alarm processing method provided by the embodiments of this application, specifically including the following Figure 1 steps as shown below: S101. Obtain the current attribute information and current status information of the target sensor.

[0039] Among them, the current attribute information is used to characterize the current alarm status of the target sensor.

[0040] It is understandable that the current status information reflects whether the target sensor currently triggers the alarm condition and thus is in the alarm state, that is, it indicates whether the sensor is in the alarm state. The current attribute information is the current configuration or characteristic information of the target sensor. The current attribute information includes information such as the basic information related to the sensor, the attribute name, the attribute type, and the attribute value. The basic information includes information such as the bus name, the object path, and the interface name. The current attribute information can be understood as the information stored on the DBus. The fault status of all sensors will be updated to the DBus in real time. The core of the DBus is to achieve cross-process communication through bus message routing and standardized interfaces. Therefore, the basic information includes information such as the bus name, the object path, and the interface name. In addition, the alarm attribute information such as the attribute name, the attribute type, and the attribute value in the current attribute information characterizes the current alarm state of the target sensor. That is to say, based on the current status information, it is determined whether the sensor is in the alarm state, and based on the current attribute information, the type of the current alarm state in which the sensor is located is determined. For example, the current alarm state is an alarm for too high temperature, an alarm for power on, or an alarm for power failure, etc.

[0041] Optionally, obtaining the current attribute information of the target sensor includes: When the target sensor is a threshold-type sensor, receiving the interface signal of the target sensor; comparing the interface signal with the safety threshold statically configured in advance for the target sensor, where there is a corresponding alarm state identifier for the safety threshold; when the current value in the interface signal is inconsistent with the safety threshold, triggering an alarm and setting the current attribute information based on the alarm state identifier.

[0042] It can be understood that a threshold sensor is a sensor used to monitor physical quantities (such as temperature, voltage, current, etc.). The process of obtaining the current attribute information of a threshold sensor is as follows: by monitoring the PropertiesChanged signal of DBus, the values of all threshold sensors are collected in real time to obtain an interface signal, wherein the PropertiesChanged signal is a standard signal in D-Bus, which is used to notify the listener that the attribute value of an object has changed, that is, the interface signal includes an actual value that can reflect the current alarm state of the sensor. Subsequently, the actual value in the interface signal is compared with the safety threshold to obtain a comparison result, wherein the safety threshold is a normal value or a limit value statically configured in advance based on the threshold rule. For example, the normal temperature of the air outlet is 38 degrees, and CriticalHigh (critical high limit) is 65 degrees. If the current air outlet temperature has an abnormal value of 70 degrees (actual value), 65 degrees is set as the safety threshold. The actual value 70 is greater than the safety threshold 65, and the CriticalHigh alarm will be triggered at this time. The comparison result is that the actual value is greater than the safety threshold, that is, the actual value and the safety threshold are inconsistent. CriticalHigh refers to the alarm state identifier. Subsequently, the current attribute information is set based on the alarm status identifier. For example, the attribute name can be directly set to CriticalHigh, or set to CriticalAlarmHigh corresponding to CriticalHigh, and the attribute value of CriticalAlarmHigh is set to true, indicating that an alarm is to be generated. Subsequently, according to the attribute value of CriticalAlarmHigh in the current attribute information, it can be determined that the sensor is in a severe alarm state, that is, the current alarm state is a severe alarm state.

[0043] In one embodiment, the critical high threshold (CriticalHigh) of the outlet temperature corresponds to the attribute name (CriticalAlarmHigh) of the critical alarm state. When the actual value is greater than the critical threshold (i.e., the safety threshold), the alarm module will actively update the attribute value of CriticalAlarmHigh in DBus from false to true, that is, generate an alarm. On the contrary, if the actual value is less than the critical threshold, the alarm module will actively update the attribute value of CriticalAlarmHigh in DBus from true to false, that is, release the alarm.

[0044] Optionally, obtain the current attribute information of the target sensor, including: In the case where the target sensor is a discrete sensor, state change information after the discrete sensor generates an alarm is read; and current attribute information is set based on the state change information.

[0045] It is understandable that discrete sensors are divided into Host - side sensors and BMC - side sensors. Among them, the Host - side sensors are for the monitoring module to passively receive change information. It can also be understood as the Host - side sensors passively received by the monitoring module, which are held and updated by the monitoring module. The Host notifies the monitoring module to update the EventData attribute through the IPMI protocol. The BMC - side sensors are further divided into BMC - side sensors maintained by the monitoring module and BMC - side sensors listened to by the monitoring module. Among them, the BMC - side sensors maintained by the monitoring module are held by the monitoring module, and other processes are responsible for updating their EventData attributes. For the BMC - side sensors listened to by the monitoring module, other processes hold and update the EventData, and among them, the attribute information of the sensors includes EventData. It is understandable that discrete sensors maintain the Event Data of all discrete sensors, as well as the alarm description information / alarm status information by loading the / usr / share / sel - config.json file.

[0046] It is understandable that the process of obtaining the current attribute information of discrete BMC-side sensors is as follows. Monitor hardware status changes (such as the presence status of the PSU). Specifically, the object path of discrete BMC-side sensors is created and managed by the monitoring module. For example, / com / otrd / system / chassis / motherboard / PSU0_Status (the storage path of the status information of power supply unit 0). The PSU monitoring process will regularly read the high and low status of the GPIO (General Purpose Input / Output) of PSU0. If the GPIO changes, it will synchronously update the EventData through the Sensor.Status interface and notify the alarm handling module to update the EventData. Among them, EventData is a 16-bit unsigned integer (uint16), and each bit (bit) corresponds to the offset (Offset) of the SEL log. For example, the event that the PSU is not present (the power supply is not present) is mapped to Offset1, corresponding to the binary bit 0000 0000 0000 0001. The object paths of the monitored BMC-side sensors are created and managed by other processes. The monitoring module is responsible for listening for changes in the EventData of Sensor.Status under these sensor object paths. For example, / com / otrd / state / PSU0_Redundant (power redundancy), where PSU0 refers to power supply unit 0. The PSU monitoring process will regularly read the presence and operating status of all power supplies on the server. If all presence statuses change or a fault such as power loss occurs, it will synchronously update the EventData of PSU0_Redundant, and the monitoring module will receive this status change information and notify the alarm handling module to update the EventData.

[0047] It is understandable that the process of obtaining the current attribute information of discrete Host-side sensors is as follows. Receive the fault code sent by the operating system through the IPMI protocol, and then call the Notify method of DBus to pass the fault event to the alarm handling module for subsequent processing. Specifically, the passively received Host-side sensors are created and managed by the monitoring module. The operating system sends the faults of the sensors to the ipmid process through the IPMI protocol. After the ipmid process preliminarily parses the EventData attribute, it calls the Notify method of the monitoring module. After parsing the event data1, event data2, and eventdata3 of the sensor alarm, it updates the EventData of Sensor.Status.

[0048] Exemplarily, see Figure 2 , Figure 2A schematic diagram of sensor status codes and event descriptions provided by the embodiments of the present application Figure 2 In Figure 2 , the EventData is 0000 0000 0000 0000, bit0 represents the 0th bit, Offset represents the attribute value of the 0th bit. When Offset = 0, it means de-asserting the alarm (DeAssert). If Offset = 1, it means asserting the alarm (Assert).

[0049] S102. When the current status information is in the alarm state, obtain a pre-constructed configuration file.

[0050] Among them, the configuration file includes the alarm filtering rules of the target sensor.

[0051] It can be understood that, based on S101 above, when the current status information is in the alarm state, that is, the target sensor is in the alarm state at this time, obtain a configuration file that is dynamically configured in advance according to the user's alarm filtering requirements. Among them, the configuration file includes the alarm filtering rules of at least one sensor. The at least one sensor includes the target sensor, and the alarm filtering rules are used to determine whether to mask, de-assert, or ignore the alarm state. The configuration file is denoted as the update-mask file.

[0052] Optionally, before obtaining the pre-constructed configuration file, the method further includes: Obtain the user's alarm filtering requirements for at least one sensor, where the alarm filtering requirements are used to indicate that the at least one sensor does not perform alarm processing when in the preset alarm state; determine the preset character identifier corresponding to the at least one sensor when in the preset alarm state; set the preset attribute identifier, where the preset attribute identifier is used to indicate the preset alarm state of the at least one sensor; for the at least one sensor, establish a mapping relationship between the preset attribute identifier and the preset character identifier to obtain the preset attribute information, where the configuration file includes the preset attribute information.

[0053] It can be understood that the steps of constructing the configuration file are as follows: obtaining the user's alarm filtering requirements for different types of sensors, wherein the alarm filtering requirements represent that a specific sensor does not give an alarm in a specific alarm state, and the specific alarm state is a preset alarm state. For example, the alarm filtering requirement is to filter out the short-term instantaneous temperature fluctuation of sensor a (such as a short-term temperature rise caused by load changes), that is, sensor a does not give an alarm when the temperature rises in a short period of time. Another example is to automatically shield the voltage alarm of sensor b during system startup or power switching, that is, sensor b does not give an alarm when the voltage rises during system startup or power switching. Subsequently, the preset character identifier corresponding to at least one sensor involved in the alarm filtering requirement is determined when it is in a specific alarm state. The preset character identifier is an object path, which can be understood as a string, for example, " / com / otrd / system / chassis / motherboard / PSU0_Status", the storage path of the status information of the power supply unit 0, and the object paths corresponding to different sensors are different. A preset attribute identifier that can characterize that a specific sensor is in a specific alarm state is set, and the preset attribute identifier has multiple attribute values, and the multiple attribute values include a first-class attribute value that identifies the alarm release and a second-class attribute value that identifies the preset alarm state. For example, when sensor a is in the CriticalAlarmHigh alarm state, the first-class attribute value is set to false, indicating that the temperature rise alarm is released, and correspondingly, the second-class attribute value is set to true, indicating that sensor a is in CriticalAlarmHigh, which is the preset alarm state. Alternatively, the attribute value of CriticalAlarmHigh can also be set to a specific value, for example, the first-class attribute value is set to 0, indicating that the temperature rise alarm is released, and correspondingly, the second-class attribute value is set to 1, indicating that sensor a is in CriticalAlarmHigh. The specific setting method is not limited. Subsequently, a mapping relationship between the preset attribute identifier and the preset character identifier is established to obtain preset attribute information. The preset attribute information of multiple sensors constitutes a configuration file, that is, a mapping relationship between attribute values and object paths is established, for example, a mapping relationship between " / com / otrd / system / chassis / motherboard / PSU0_Status" and Offset is established.

[0054] It is understandable that when BMC starts up, it loads the / var / lib / update-mask file into memory, constructs a hash mapping table of sensor object paths and Offset masks, and realizes nanosecond-level alarm filtering rule retrieval. For example, if a user needs to filter the presence alarm status code of the PSU, they can write the corresponding Offset of PSU0_Status (such as Offset = 1) to the configuration file through the doPatch method of Redfish. The system updates the configuration file in memory in real time and ensures data consistency in a multi-threaded environment through atomic operations. When the presence alarm of PSU0_Status is generated again, it is checked whether the current Offset matches the alarm filtering rule according to the sensor object path, that is, it is determined whether the Offset in the configuration file is the same as the Offset in the current attribute information. If both Offsets are 1, it means that the two represent the same alarm status and the alarm status has been marked as filterable. In fact, the configuration file records the ignorable / filterable alarm status. In this case, the Offset in the EventData is ignored and modified to 0, where Offset = 1 represents an alarm and Offset = 0 represents no alarm. The alarm can trigger operations such as SEL recording and fault light indication. It is understandable that the Offset = 1 (1 is the second attribute value) recorded in the current attribute information also indicates that the target sensor is in an alarm state, and the Offset = 0 (0 is the first attribute value) in the updated current attribute information indicates no alarm, thus filtering out the alarm status.

[0055] Optionally, a mapping relationship between a preset attribute identifier and a preset character identifier is established to obtain preset attribute information. After the configuration file includes the preset attribute information, the method further includes: Storing the configuration file in a non-volatile storage medium in a binary storage manner; when performing firmware upgrade and / or factory reset processing, the configuration file is not processed.

[0056] Understandably, using the binary storage format of the Cereal serialization library, the configuration file is encoded into a compact key-value structure, that is, a structure of preset character identifier - attribute value, or object path - attribute value. Through the serialization mechanism, data is efficiently stored in binary form, avoiding redundant characters and structured tags, significantly improving read and write performance and saving storage space. Among them, Key refers to the object path of the sensor, that is, the preset character identifier. The object path is used to uniquely identify the sensor object. Value refers to the Offset mask, that is, the attribute value. For example, "key": " / com / otrd / system / chassis / motherboard / PSU0_Status", "value": 1 (0000 0000 00000001). Among them, "0000 0000 0000 0001" is the EventData attribute of the binary bit. This storage method can reduce the resource consumption of data storage and reading, improve the processing speed, enhance data security, and improve the operation efficiency of the data center.

[0057] Understandably, the modified sensor alarm code will be stored in the configuration file. If the actual requirement of the user is that when the BMC performs a factory reset or firmware upgrade, all modified sensor alarm status codes should not be reset to the pre-factory state, but the updated sensor alarm status codes need to be persisted. In this case, the present application proposes a persistence mechanism. Specifically, when the BMC performs a factory reset or firmware upgrade, it will dynamically erase the Flash and remount the file system using the content of the rw partition. Therefore, before erasing, the configuration file can be temporarily stored in other directories such as / tmp, and then the configuration file can be restored after the file system is mounted.

[0058] Understandably, a configuration file can be created in the / var / lib directory and added to the whitelist to ensure that the file is persistently retained during firmware upgrade and factory reset. When the BMC restarts abnormally, the configuration file can be quickly loaded to avoid repeated configuration. After the configuration file is stored in the Binary storage format of Cereal, the configuration file is encrypted by a high-strength encryption algorithm. Compared with the json file involved in the related technology, the Binary format configuration file effectively reduces the storage space occupied by redundant characters, and at the same time significantly improves the complexity of key cracking, has stronger anti-brute-force cracking and cryptanalysis capabilities, and comprehensively guarantees the security and confidentiality of data throughout the life cycle, providing reliable protection for the storage and transmission of sensitive information in the data center.

[0059] S103: When the current attribute information meets the alarm filtering rule, cancel the alarm state of the target sensor.

[0060] It is understandable that, based on the above S102, if the current attribute information meets the alarm filtering rules, the alarm state of the target sensor is automatically released, that is, this type of fault does not require an alarm, and alarm filtering is completed to avoid invalid alarm reporting and log recording.

[0061] Optionally, when the current attribute information meets the alarm filtering rule, the alarm state of the target sensor is released, which can be specifically achieved through the following steps: In the process of processing the current attribute information, the next attribute information of the target sensor is obtained, wherein the next attribute information is used to represent the next alarm state of the target sensor, and the next alarm state is different from the current alarm state represented by the current attribute information; the target attribute information is calculated based on the current attribute information and the next attribute information, wherein the target attribute information is used to represent the next alarm state and / or the current alarm state represented by the current attribute information; when the target attribute information meets the alarm filtering rules, the next alarm state of the target sensor and / or the current alarm state represented by the current attribute information are released.

[0062] It is understandable that in the process of performing alarm filtering on the current attribute information, if the next attribute information of the target sensor is obtained, that is, the target sensor generates two alarms at this time, wherein the next attribute information represents the next alarm state of the target sensor. In one possible case, the next alarm state is different from the current alarm state, for example, the next alarm state is a power failure alarm, and the current alarm state is a power supply in place alarm, and the power failure alarm and the power supply in place alarm belong to different alarm types. In another possible case, the next alarm state is the same as the current alarm state, which is a repeated alarm, for example, both alarms are power failure alarms. In this case, the target attribute information is calculated based on the current attribute information and the next attribute information, and the target attribute information represents the next alarm state and / or the current alarm state represented by the current attribute information. For example, if it is a repeated alarm, an attribute value or an alarm status code of an alarm state is retained in the target attribute information, and if it is two types of alarms, the alarm status codes of the next alarm state and the current alarm state are retained in the target attribute information. Subsequently, it is determined whether the target attribute information meets the alarm filtering rules. When the alarm status codes of the next alarm state and the current alarm state are retained in the target attribute information, that is, in the case of two alarms, it is determined whether the next alarm state and / or the current alarm state represented by the current attribute information recorded in the release configuration file is filterable. That is, in the case of multiple alarms, the specific alarm state that meets the alarm filtering rules is released, and other alarms except the specific alarm state are generated among the multiple alarms.

[0063] Exemplarily, refer to Figure 3 , Figure 3 , which is a schematic diagram of alarm processing and event description provided by an embodiment of the present application. Figure 3 In Figure 3 , the initial state of EventData is 0000 0000 0000 0000, the default PSU0 is present, and a Presencedetected alarm is generated, that is, a power presence alarm is generated. The current alarm state is the power presence alarm, that is

[0064] Optionally, the method further includes: Obtaining adjustment information for the alarm filtering rule; updating the configuration file based on the adjustment information.

[0065] It can be understood that the adjustment information (such as adding, modifying or deleting filtering items) of the alarm filtering rule by the user or the system is obtained. Subsequently, the corresponding configuration file is updated according to the adjustment information to keep the alarm filtering rule in the latest state.

[0066] The alarm processing method provided by the present application supports users to realize secondary filtering of threshold sensor alarms by dynamically modifying the configuration file without modifying the original threshold. It solves the problem of false alarms that are easy to occur when the fixed threshold is switched in the related technology. In addition, users can also adjust the alarm filtering rules at any time according to actual needs without modifying the underlying rules of the system, effectively reducing the false alarm rate of key component sensors in scenarios such as over-limit. At the same time, for discrete sensor alarms from multiple sources on the BMC side and the Host side, cross-protocol alarm filtering is achieved through a unified status code identifier (such as the mapping relationship between the object path and the attribute value recorded in the attribute information), which significantly improves the accuracy of alarm classification. It further enables operation and maintenance personnel to avoid frequently adjusting firmware configurations or manually intervening in alarm strategies, reduces maintenance costs, enhances the autonomy and convenience of data management, and further broadens the scope of application of the BMC system. In addition, during the firmware upgrade process, there is no need to re-adapt the alarm filtering rules, which reduces the frequency of manual intervention and ensures the continuity of server management.

[0067] Based on the above embodiments, see Figure 4 , Figure 4 A flowchart of an alarm processing method provided by an embodiment of the present application. Optionally, when the current attribute information meets the alarm filtering rule, the alarm state of the target sensor is released, specifically including the following steps: Figure 4 The following steps are shown: S401: Compare current attribute information with preset attribute information.

[0068] It is understandable that the current attribute information is compared with the preset attribute information, specifically the object path and the attribute value representing the alarm state are compared to generate a comparison result, which includes whether the object path and / or the attribute value are consistent.

[0069] In one embodiment, the high threshold alarm of the outlet temperature (Outlet_Temp) of the discrete sensor is stored on DBus as follows: Bus name: com.otrd.HwmonTempSensor Object path: / com / otrd / sensors / temperature / Outlet_Temp Interface name: com.otrd.Sensor.Threshold.Critical Property name: CriticalAlarmHigh Property type: bool Property value: true In another embodiment, the in-position alarm of the power supply state (PSU0_Status) of the discrete sensor is stored on the DBus as follows: Bus name: com.otrd.Sensor.Monitor Object path: / com / otrd / sensors / chassis / motherboard / PSU0_Status Interface name: com.otrd.Sensor.Status Attribute name: EventData Attribute type: map<uint8,map<uint8, vector <uint8>>> Property value: 0 The acquired sensor attribute information may be a storage method of different alarm states on DBus, and the attribute information represents a specific alarm state, that is, an actual alarm state, such as the above-mentioned power supply alarm and high temperature threshold alarm.

[0070] It is understandable that both the preset attribute information and the current attribute information record the object path and the attribute value, so it is possible to compare whether the object path and the attribute value are consistent.

[0071] S402: If the character identifiers recorded in the current attribute information and the preset attribute information are consistent, and the current alarm state is consistent with the preset alarm state, then the current attribute information is updated to release the alarm state of the target sensor.

[0072] It can be understood that, based on the above S401, if the current attribute information is consistent with the character identifier recorded in the preset attribute information (that is, the object path is consistent), and the current alarm state is consistent with the preset alarm state (that is, it is for the same alarm event), or the character identifier is consistent and the current attribute value in the current attribute information is consistent with the preset attribute value in the preset attribute information (that is, the Offset is the same, both are 1 or both are true), then it is confirmed that the alarm state can be released, the alarm event does not need to be alarmed, and the current attribute information is updated at the same time to release the alarm state of the target sensor.

[0073] Optionally, update the current attribute information, which can be achieved through the following steps: Determine a first attribute value corresponding to a preset attribute identifier indicating the release of an alarm; update a second attribute value corresponding to a current attribute identifier set for a current alarm state in current attribute information to a first attribute value, wherein the second attribute value indicates the generation of an alarm, wherein the first attribute value and the second attribute value are different.

[0074] It is understandable that the preset attribute identifier is used to identify that the alarm state can be ignored, and the preset attribute identifier can also be understood as an alarm release identifier, which specifically corresponds to multiple attribute values. For example, setting the first attribute value to a indicates that the alarm is released, and setting the second attribute value to b indicates that an alarm is generated. The current attribute information is generated when the target sensor is in an alarm state. Therefore, the current attribute identifier in the current attribute information represents the generation of an alarm. For example, the attribute value corresponding to the current attribute identifier is the second attribute value b. If the current alarm state can be filtered, the attribute value corresponding to the current attribute identifier is changed from b to a, that is, the alarm is released. In the above-mentioned embodiment of the severe alarm state of the outlet temperature, false can be understood as the first attribute value for releasing the alarm, and true can be understood as the second attribute value for triggering / generating an alarm.

[0075] Optionally, update the current attribute information, which can be achieved through the following steps: In the case where the current attribute information is set based on the previous attribute information, the current attribute information is updated to the previous attribute information, wherein the previous attribute information is used to characterize the previous alarm state of the target sensor, the previous alarm state is different from the current alarm state, and the previous alarm state does not comply with the alarm filtering rules.

[0076] It is understandable that before generating the current attribute information, the target sensor has generated the previous attribute information, and the current attribute information is generated based on the previous attribute information. In this case, the previous alarm state represented by the previous attribute information is maintained or re-triggered, wherein the current alarm state is a filterable specific alarm state, and the previous alarm state is an unfilterable alarm state.

[0077] It can be understood that the EventData (identification code in the previous attribute information) of the PSU0_Status alarm is 00000000 0000 0010, and the previous alarm state is the power failure alarm. If the PSU generates a power in place alarm, the EventData (identification code in the current attribute information) is 0000 0000 0000 0001, and the updated EventData (identification code in the target attribute information) calculated according to the current attribute information and the previous attribute information is 0000 00000000 0011. However, since the power in place alarm has been marked as ignored in the configuration file, that is, the current alarm state is an ignorable specific alarm state, after secondary filtering of the configuration file, the new EventData is still 0000 00000000 0010. Therefore, the power in place alarm will not be generated, but the power failure alarm will be generated or maintained.

[0078] Optionally, after releasing the alarm state of the target sensor, the method further includes: An alarm clearing log is generated according to the preset character identifier of the target sensor, the updated current attribute information and / or the alarm level of the current alarm state.

[0079] It is understandable that when the SEL log record and the corresponding hardware operation are triggered, the alarm status needs to be updated, and the sensor object path, EventData, alarm level and other information need to be organized into a SEL structure to generate corresponding SEL log entries, such as triggering an alarm log or clearing an alarm log, etc., and driving the fault light to perform corresponding actions based on the current alarm status, such as being always on, off or flashing.

[0080] The alarm processing method provided by this application avoids the modification of the original sensor configuration file (such as json file) and the default threshold value by creating a configuration file. When performing alarm filtering, the alarm filtering rules will be automatically applied to shield the alarm status marked as ignored, such as the outlet temperature briefly exceeding the threshold, the power module in place, and other alarm states, so that the marked sensor fault status code can be ignored without restarting the BMC service or reloading the firmware.

[0081] 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 a necessary general hardware platform, and of course by hardware, but in many cases the former is a better implementation method.

[0082] The embodiment of the present application further provides an alarm processing device, the alarm processing device 500 includes a first acquisition module 501, a second acquisition module 502 and a filtering module 503, wherein: The first acquisition module 501 is used to acquire current attribute information and current state information of the target sensor; The second acquisition module 502 is used to acquire a pre-built configuration file when the current state information is an alarm state, wherein the configuration file includes an alarm filtering rule of the target sensor; The filtering module 503 is used to release the alarm state of the target sensor when the current attribute information meets the alarm filtering rule.

[0083] Optionally, the alarm processing device 500 is further configured to: Acquiring an alarm filtering requirement of a user for at least one sensor, wherein the alarm filtering requirement is used to indicate that at least one sensor does not perform alarm processing when in a preset alarm state; Determine a preset character identifier corresponding to at least one sensor being in a preset alarm state; Setting a preset attribute identifier, wherein the preset attribute identifier is used to represent a preset alarm state of at least one sensor; For at least one sensor, a mapping relationship between a preset attribute identifier and a preset character identifier is established to obtain preset attribute information, wherein the configuration file includes the preset attribute information.

[0084] The current attribute information is used to characterize the current alarm state of the target sensor.

[0085] Optionally, the filtering module 503 is used to: Compare current attribute information with preset attribute information; If the character identifiers recorded in the current attribute information and the preset attribute information are consistent, and the current alarm state is consistent with the preset alarm state, the current attribute information is updated to release the alarm state of the target sensor.

[0086] Optionally, the filtering module 503 is used to: Determine a preset attribute identifier set for a preset alarm state in the preset attribute information, wherein the preset attribute identifier is a first attribute value representing the release of the alarm; Determine a first attribute value corresponding to a preset attribute identifier indicating that an alarm is released; The second attribute value corresponding to the current attribute identifier set for the current alarm state in the current attribute information is updated to the first attribute value, wherein the second attribute value indicates that an alarm is generated, and wherein the first attribute value and the second attribute value are different.

[0087] Optionally, the filtering module 503 is used to: In the case where the current attribute information is set based on the previous attribute information, the current attribute information is updated to the previous attribute information, wherein the previous attribute information is used to characterize the previous alarm state of the target sensor, the previous alarm state is different from the current alarm state, and the previous alarm state does not comply with the alarm filtering rules.

[0088] Optionally, the alarm processing device 500 is further configured to: An alarm clearing log is generated according to the preset character identifier of the target sensor, the updated current attribute information and / or the alarm level of the current alarm state.

[0089] Optionally, the filtering module 503 is used to: In the process of processing the current attribute information, the next attribute information of the target sensor is obtained, wherein the next attribute information is used to represent the next alarm state of the target sensor, and the next alarm state is different from the current alarm state represented by the current attribute information; Calculate target attribute information according to the current attribute information and the next attribute information, wherein the target attribute information is used to represent the next alarm state and / or the current alarm state represented by the current attribute information; When the target attribute information meets the alarm filtering rule, the next alarm state of the target sensor and / or the current alarm state represented by the current attribute information are released.

[0090] Optionally, the filtering module 503 is used to: The configuration file is stored in a non-volatile storage medium by binary storage; When performing a firmware upgrade and / or factory reset process, the configuration files are not processed.

[0091] Optionally, the first acquisition module 501 is used to: In the case where the target sensor is a threshold type sensor, receiving an interface signal of the target sensor; Compare the interface signal with a pre-statically configured safety threshold of the target sensor, wherein the safety threshold has a corresponding alarm status indicator; When the current value in the interface signal is inconsistent with the safety threshold, an alarm is triggered and the current attribute information is set based on the alarm status identifier.

[0092] Optionally, the first acquisition module 501 is used to: When the target sensor is a discrete sensor, read the state change information after the discrete sensor generates an alarm; Set current property information based on state change information.

[0093] Optionally, the alarm processing device 500 is further configured to: Get adjustment information for alarm filtering rules; Update the configuration file based on the adjustment information.

[0094] For the description of the features in the embodiment corresponding to the alarm processing device, reference can be made to the relevant description of the embodiment corresponding to the alarm processing method, which will not be repeated here.

[0095] Figure 6 A schematic diagram of the structure of an alarm processing system provided in an embodiment of the present application, the alarm processing system includes an alarm processing module, an alarm filtering module and a fault update module, wherein: The alarm processing module is used to obtain the current attribute information and current status information of the target sensor; It can be understood that the current EventData and the previous EventData of the sensor are calculated to generate the latest EventData, and the fault update module is notified of the fault generated by the sensor and the resolved fault.

[0096] The alarm filtering module is used to receive the current attribute information and the current state information transmitted by the alarm processing module, and when the current state information is an alarm state, obtain a pre-built configuration file, wherein the configuration file includes the alarm filtering rules of the target sensor, and determine whether the current attribute information meets the alarm filtering rules. When the current attribute information meets the alarm filtering rules, release the alarm state of the target sensor; It can be understood that the alarm filtering module serves as the core middleware between the alarm processing module and the fault update module, and as a dynamic rule engine and an alarm status arbitrator, wherein the dynamic rule engine is used to obtain a pre-built configuration file, and the alarm status arbitrator is used to determine whether the current attribute information complies with the alarm filtering rules. When the current attribute information complies with the alarm filtering rules, the alarm status of the target sensor is released.

[0097] The fault update module is used to receive the alarm processing result fed back by the alarm filtering module, and update the fault log of the target sensor based on the alarm processing result.

[0098] Understandably, the fault update module is used to determine whether a fault needs to trigger SEL logging and hardware actions through the result fed back by the previous-stage alarm filtering module.

[0099] Among them, the alarm processing system further includes a sensor monitoring module, and the sensor monitoring module is used to monitor the numerical changes of all sensors and update the alarm attribute values.

[0100] Understandably, for the specific implementation steps of the alarm processing system, refer to the above embodiments, which will not be elaborated here.

[0101] An embodiment of the present application further provides an electronic device, including a memory and a processor. A computer program is stored in the memory, and the processor is configured to run the computer program to execute the steps in any of the above-mentioned embodiments of the alarm processing method.

[0102] 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 in any of the above-mentioned embodiments of the alarm processing method when running.

[0103] In an exemplary embodiment, the above computer-readable storage medium may include, but is not limited to: USB flash drives, read-only memories (ROM for short), random access memories (RAM for short), mobile hard disks, magnetic disks, or optical disks and other various media that can store computer programs.

[0104] An embodiment of the present application further provides a computer program product. The above computer program product includes a computer program, and the computer program realizes the steps in any of the above-mentioned embodiments of the alarm processing method when executed by a processor.

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

[0106] Those skilled in the art may further realize that the units and algorithm steps of each example described in combination with the embodiments disclosed herein can be implemented by electronic hardware, computer software, or a combination of both. To clearly illustrate the interchangeability of hardware and software, the composition and steps of each example have been generally described according to functions in the above description. Whether these functions are executed in a hardware or software manner depends on the specific application and design constraints of the technical solution. Those skilled in the art can use different methods to implement the described functions for each specific application, but such implementation should not be considered to exceed the scope of this application.

[0107] The above has introduced in detail an alarm processing provided by this application. Specific examples are used herein to elaborate on the principle and implementation manner of this application. The description of the above embodiments is only used to help understand the method and its core idea of this application. It should be noted that for those of ordinary skill in the art in this technical field, without departing from the principle of this application, several improvements and modifications can still be made to this application, and these improvements and modifications also fall within the protection scope of the claims of this application.

Claims

1. An alarm handling method, characterized in that, include: Obtain current attribute information and current state information of the target sensor; When the current state information is an alarm state, obtaining a pre-built configuration file, wherein the configuration file includes an alarm filtering rule of the target sensor; When the current attribute information meets the alarm filtering rule, the alarm state of the target sensor is released.

2. The method according to claim 1, characterized in that Before obtaining the pre-built configuration file, the method further includes: Acquire an alarm filtering requirement of a user regarding at least one sensor, wherein the alarm filtering requirement is used to indicate that the at least one sensor does not perform alarm processing when in a preset alarm state; Determine a preset character identifier corresponding to when the at least one sensor is in the preset alarm state; Setting a preset attribute identifier, wherein the preset attribute identifier is used to represent a preset alarm state of the at least one sensor; For the at least one sensor, a mapping relationship between the preset attribute identifier and the preset character identifier is established to obtain preset attribute information, wherein the configuration file includes the preset attribute information.

3. The method according to claim 2, wherein The current attribute information is used to represent the current alarm state of the target sensor, and when the current attribute information meets the alarm filtering rule, releasing the alarm state of the target sensor includes: Comparing the current attribute information with the preset attribute information; If the character identifiers recorded in the current attribute information and the preset attribute information are consistent, and the current alarm state is consistent with the preset alarm state, the current attribute information is updated to release the alarm state of the target sensor.

4. The method according to claim 3, characterized in that The updating of the current attribute information includes: Determine a first attribute value corresponding to the preset attribute identifier indicating that the alarm is released; The second attribute value corresponding to the current attribute identifier set for the current alarm state in the current attribute information is updated to the first attribute value, wherein the second attribute value indicates that an alarm is generated, and wherein the first attribute value and the second attribute value are different.

5. The method according to claim 3, characterized in that, The updating of the current attribute information includes: In the case where the current attribute information is set based on the previous attribute information, the current attribute information is updated to the previous attribute information, wherein the previous attribute information is used to characterize the previous alarm state of the target sensor, the previous alarm state is different from the current alarm state, and the previous alarm state does not comply with the alarm filtering rule.

6. The method according to claim 3, characterized in that, After releasing the alarm state of the target sensor, the method further includes: An alarm clearing log is generated according to the preset character identifier of the target sensor, the updated current attribute information and / or the alarm level of the current alarm state.

7. The method according to claim 1, wherein When the current attribute information meets the alarm filtering rule, releasing the alarm state of the target sensor includes: In the process of processing the current attribute information, the next attribute information of the target sensor is obtained, wherein the next attribute information is used to represent the next alarm state of the target sensor; Calculating target attribute information according to the current attribute information and the next attribute information, wherein the target attribute information is used to characterize the next alarm state and / or the current alarm state; When the target attribute information meets the alarm filtering rule, the next alarm state of the target sensor and / or the current alarm state represented by the current attribute information are released.

8. The method according to claim 2, characterized in that After establishing the mapping relationship between the preset attribute identifier and the preset character identifier and obtaining the preset attribute information, the method further includes: Storing the configuration file in a non-volatile storage medium in a binary storage manner; When performing a firmware upgrade and / or restoring factory settings process, the configuration file is not processed.

9. The method according to claim 1, wherein Get the current attribute information of the target sensor, including: In the case where the target sensor is a threshold type sensor, receiving an interface signal of the target sensor; Comparing the interface signal with a pre-statically configured safety threshold of the target sensor, wherein the safety threshold has a corresponding alarm status identifier; When the current value in the interface signal is inconsistent with the safety threshold, an alarm is triggered, and current attribute information is set based on the alarm status identifier.

10. The method according to claim 1, characterized in that Get the current attribute information of the target sensor, including: In the case where the target sensor is a discrete sensor, reading state change information of the discrete sensor after an alarm is generated; Current attribute information is set based on the state change information.

11. The method according to claim 1, characterized in that, The method further comprises: Obtaining adjustment information for the alarm filtering rule; The configuration file is updated based on the adjustment information.

12. An alarm processing system, characterized in that, The alarm processing system includes an alarm processing module, an alarm filtering module and a fault updating module, wherein: The alarm processing module is used to obtain current attribute information and current state information of the target sensor; The alarm filtering module is used to receive the current attribute information and the current state information transmitted by the alarm processing module, and when the current state information is an alarm state, obtain a pre-built configuration file, wherein the configuration file includes the alarm filtering rule of the target sensor, and determine whether the current attribute information meets the alarm filtering rule, and when the current attribute information meets the alarm filtering rule, release the alarm state of the target sensor; The fault updating module is used to receive the alarm processing result fed back by the alarm filtering module, and update the fault log of the target sensor based on the alarm processing result.

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

14. 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 processing method according to any one of claims 1 to 11.

15. 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 processing method according to any one of claims 1 to 11 are implemented.

Images