System event alerting method and apparatus

Abstract

The application provides a system event alarm method and device. The system event alarm method comprises: determining that a system event to be viewed needs to be alarmed based on a preset alarm event rule list; determining a component needing to be alarmed and an alarm type based on an event type of the system event to be viewed; identifying whether the system event to be viewed is repeated with a previous system event of the component needing to be alarmed based on a repeated event identification rule corresponding to the alarm type; generating an event code indicating the event type based on the system event to be viewed when the system event to be viewed is not repeated with the previous system event; storing the event code and allocating an associated event code identifier; wherein the event code identifier is unique within a current baseboard management controller running cycle; and sending the event code identifier and the event code to an out-of-band management device to view the event code based on the event code identifier to obtain the event type of the system event to be viewed.

Description

TECHNICAL FIELD

[0001] The present application relates to the communication technology, in particular to a system event alarm method and device. BACKGROUND

[0002] IPMI is an (Intelligent Platform Management Interface, intelligent platform management interface) standard, which can monitor the physical health characteristics of a server, such as temperature, voltage, fan working state, power state, etc.

[0003] The core of the IPMI system is BMC (Baseboard Management Controller, baseboard management controller), which executes corresponding IMPI functions by sending instructions specified by the IPMI standard to the BMC. The BMC receives the instructions and records event messages in the SEL (System Event Log, system event log) component of the IPMI system. The IPMB (Intelligent Platform Management Bus, intelligent platform management bus) of the IPMI system connects various controllers and I 2 C devices, so that system management software can read sensor data through the IPMB. The specific configuration information of these sensors, such as alarm thresholds and whether event triggering is allowed, is saved in the SDR (Sensor Data Record, sensor data record) component of the IPMI system, and the system events generated by these sensors are also saved in the SEL (System Event Log) component.

[0004] When a server fails, the failure events stored in the SEL are displayed through a web page, or an operation and maintenance personnel views the system events stored in the SEL through a remote instruction, analyzes the failure components and failure causes, and requires a large amount of manual analysis work. If the failure components and alarms are output based on the SEL recorded data, the manual input of maintenance personnel can be reduced, and even maintenance automation can be realized to quickly respond to failures, ensure business recovery, which is a technical problem to be solved.

[0005] The existing solution is to record a self-defined failure code in the event data field (event data) of each event information recorded in the SEL, and the maintenance personnel retrieves the self-defined failure code of the SEL data field, and analyzes the failure alarm information corresponding to the self-defined failure code through a private analysis tool. However, this method cannot be compatible with the needs of the IPMI standard, requires users to install a matching private analysis tool, and cannot achieve compatible processing of various source devices. SUMMARY

[0006] The purpose of the present application is to provide a fault alarm method, which generates an event code indicating the event type of a system event that needs to be alarmed, so as to view the event code by an out-of-band management device to obtain the event type of the system event that needs to be alarmed.

[0007] To achieve the above purpose, the present application provides a system event alarm method, which comprises: determining that a to-be-viewed system event needs to be alarmed based on a preset alarm event rule list; determining an alarm type based on the event type of the to-be-viewed system event; identifying whether the to-be-viewed system event is repeated with a previous system event based on a repeated event identification rule corresponding to the alarm type; generating an event code indicating the event type of the to-be-viewed system event when the to-be-viewed system event is not repeated with the previous system event; storing the event code and assigning an associated event code identifier; wherein the event code identifier is unique within a current baseboard management controller running cycle; and sending the event code identifier and the event code to an out-of-band management device to view the event code based on the event code identifier to obtain the event type of the to-be-viewed system event.

[0008] To achieve the above purpose, the present application further provides a device for implementing the above system event alarm method, which comprises a processor, a memory, a baseboard management controller, a sensor, a communication interface and a bus. The baseboard management controller implements the system event alarm method of the present application by running processor executable instructions in the memory.

[0009] The present application has the beneficial effect of generating a fault code based on a system event to indicate the event type of the system event, so that an operation and maintenance personnel can obtain the alarm type according to the event code, thereby reducing the operation and maintenance workload of the operation and maintenance personnel in calling, viewing and analyzing system event logs to analyze the fault reason. The present application can be compatible with the IPMI standard without the need for a private device analysis tool to analyze a custom fault code. BRIEF DESCRIPTION OF DRAWINGS

[0010] Figure 1 Flowchart of the system event alarm method provided by the present application;

[0011] Figure 2 Flowchart of the fault event alarm embodiment provided by the present application;

[0012] Figure 3 Flowchart of the fan system event alarm embodiment provided by the present application;

[0013] Figure 4 Flowchart of the trigger type and release type system event alarm embodiment provided by the present application;

[0014] Figure 5 Schematic diagram of the system event alarm device embodiment provided by the present application. DETAILED DESCRIPTION

[0015] Examples will be described in detail with reference to the accompanying drawings. In the following detailed description, numerous specific details are set forth in order to provide a thorough understanding of the present application. Known methods, procedures, components, and circuits have not been described in detail since such are well understood to those of ordinary skill in the art.

[0016] In the use of the terms, the term "comprising" means including, but not limited to; the term "containing" means including, but not limited to; the terms "above", "within" and "below" include the number; the terms "greater than", "less than" do not include the number. The term "based on" means at least based on part of it.

[0017] Figure 1 A system event alarm method is provided in the present application, and the system event alarm method comprises the following steps:

[0018] Step 101, determining that the system event to be viewed needs to be alarmed based on a preset alarm event rule list;

[0019] Step 102, determining an alarm type based on the event type of the system event to be viewed;

[0020] Step 103, identifying whether the system event to be viewed is repeated with a previous system event based on the repeated event identification rule corresponding to the alarm type;

[0021] Step 104, generating an event code indicating the event type based on the system event to be viewed when the system event to be viewed is not repeated with the previous system event;

[0022] Step 105, generating an event code indicating the event type based on the system event to be viewed when the system event to be viewed is not repeated with the previous system event;

[0023] The event code is unique in the current baseboard management controller running cycle;

[0024] Step 106, sending the event code identifier and the event code to an out-of-band management device;

[0025] The event code is viewed based on the event code identifier to obtain the event type of the system event to be viewed.

[0026] In the present application, the system event to be viewed which does not need to be alarmed is sent to a system event log output channel, such as a Web page, to be viewed, so that the operation and maintenance personnel can obtain corresponding processing suggestions and other information according to the event code to obtain corresponding maintenance processing suggestions.

[0027] Figure 1The embodiment has the advantages that the fault code is generated based on the system event to indicate the event type of the system event, so that the operation and maintenance personnel can obtain the alarm type according to the event code, and the operation and maintenance workload of the operation and maintenance personnel in calling, checking and analyzing the system event log to analyze the fault reason is reduced. The application can be compatible with the IPMI standard and does not need a private device analysis tool to analyze the custom fault code.

[0028] Figure 2 The flowchart of the fault event alarm embodiment provided in the application is shown in the following figure;

[0029] The IPMI standard stipulates that each SEL includes 2 bytes of Record ID (record identification), 1 byte of record type (Record Type), 4 bytes of event occurrence time, 2 bytes of Gen ID, 1 byte of event message format version (EvMev, Event Message format version), 1 byte of sensor type, 1 byte of sensor value, 1 byte of event feature description type (EvtDirType), 1 byte of first event data (EvtData1), 1 byte of second event data (EvtData2), and 1 byte of third event data (EvtData3).

[0030] In the application, the server also records the event code of the SEL, which is used to indicate a type of event, and the event code can be used by an out-of-band management device (for example, a Red Fish management system) to query the event type, which is beneficial for the operation and maintenance personnel to obtain corresponding help from various dimensional information (such as an official website and a manual).

[0031] In the application, the coding strategy of the event code includes component type data, event major category data, first event minor category, and second event minor category. The component type data is obtained from the sensor type field of the SEL event, the event major category data is obtained from the event feature description type field of the SEL, the first event minor category data is obtained from the first event data field of the SEL, and the second event minor category data is obtained from the second event data field of the SEL.

[0032] Figure 2 In the application, the BMC of the server uses the recorded SEL in a componentized manner, and sends the componentized system event log to a web page of the SEL before displaying the SEL. Figures 2-4 The embodiment judges whether the SELs that need to be sent to the web page have event logs that need to be alarmed.

[0033] Step 201, determine whether the system event sent to the web page display needs to be alarmed based on the preset alarm event rule list; if yes, execute step 202, if no, execute step 203.

[0034] The application takes the alarm event rule list shown in Table 1 as an example:

[0035]

[0036]

[0037] Table 1

[0038] Step 202, determine whether it is a resource class system event, if no, execute step 211, if yes, execute step 310.

[0039] Based on the sensor type field of the SEL, the sensor that generates the current system event can be known, and based on the sensor value, the description information of the sensor in the IPMI standard can be obtained; based on the event characteristic description type (EvDirType) field, the event type can be known; the highest bit of the event itself is marked as 0 to identify a triggered event, and as 1 to identify a non-triggered event, and the remaining low seven bits represent types such as discrete and continuous, and the low four bits of the first event data field are offset data (Offset data) which is a further classification standard for event types, such as identifying in or not in position; the second event data and the third event data can be used for extension of data description information.

[0040] Therefore, the type of the current system event can be identified according to the fields of the system event. Figure 2 If the current system event sent to the web page display is not a resource class system event, but a fault alarm event, step 211 is executed.

[0041] Step 211, determine whether it is a normal fault system event; if yes, execute step 212, if no, execute step 215.

[0042] The non-resource class fault system event has different fault registrations, and is divided into normal system events and abnormal fault system events based on fault levels. Whether it is a normal fault alarm event is determined according to the fault registration of the fault system event.

[0043] Step 212, determine whether there is an uneliminated same normal fault system event, if yes, execute step 213, if no, execute step 214.

[0044] Based on the recorded SEL, the type, value, event characteristic description and occurrence time of the sensor that has generated the fault system event can be determined, so that whether there is an uneliminated same normal fault system event of the device that needs to be alarmed can be known.

[0045] Step 213, associating the event code identification of the same normal fault system event previously generated with the current normal fault system event.

[0046] Because the same normal fault system event does not need to be repeatedly alarmed, only internal record is needed to associate the current normal fault system event with the event code identification of the same normal fault system event previously existing, and the fault type of the repeatedly generated normal fault system event is displayed through the corresponding event code of the same event code identification, so as to avoid repeated alarm.

[0047] In the present application, the event code identification can be counted from 1, and the maximum value is a UINT integer value (4 bytes), that is, the maximum is theoretically 4294967295, and when reaching the maximum 4294967295, it starts to count again from 1. The event code identification is only valid within the current BMC running period, and when the BMC restarts, the event code identification starts to count from 1.

[0048] For example, when the normal fault system event is a network card fault event, if it is found that the event code 1 has been allocated to the network card fault event of the same network card previously, the event code 1 is associated with the current network card fault event; and the repeatedly generated network card fault event of the same network card is managed through the event code 1.

[0049] Step 214, generating an event code for the current normal fault system event and allocating an event code identification.

[0050] According to the above event code strategy, the event code indicating the current normal fault system event is obtained from each field of the current normal fault system event, and a new event code is allocated.

[0051] For example, when the fault system event is a different network card fault event, the technical event code strategy generates an event code indicating the fault type of the network card fault and allocates event code 2, so that it can be known through the event code 1 and the event code 2 that although the fault types are the same, the faults of different devices occur.

[0052] The recorded device type can obtain the description information of the sensor in the IPMI standard based on the sensor value; the event type can be known based on the event characteristic description (EvDirType) field; the highest bit of the event type is 0, indicating a triggered event, and 1 indicating a non-triggered event, and the remaining low seven bits represent types such as discrete, continuous, etc., the low four bits of the first event data field are offset data (Offset data), which is a further classification standard for event types, such as indicating in place or not in place; the second event data and the third event data can be used for extension of data description information.

[0053] Step 215, judging whether there is an uneliminated same abnormal fault system event, if yes, executing step 216, if no, executing step 217.

[0054] Step 216, associating the event code identification of the same normal fault system event generated before with the current normal fault system event.

[0055] Similarly, the abnormal fault system does not need to repeat the alarm, only needs to record internally, associates the current abnormal fault system event with the event code identification of the same abnormal fault system event existing before, displays the fault type of the repeatedly generated abnormal fault system event through the corresponding event code of the same event code identification, and avoids repeated alarm.

[0056] For example, when the abnormal fault system event is a CPU temperature alarm event, if it is found that the event code 3 has been allocated for the CPU temperature alarm event before, the event code 3 is associated with the current CPU temperature alarm event.

[0057] Step 217, generating an event code for the current abnormal fault system event and allocating an event code identification.

[0058] According to the above event code strategy, the event code indicating the current normal fault system event is obtained from each field of the current abnormal fault system event. For example, the current abnormal fault system event is a server POST alarm event, and a new event code 4 is generated for the event.

[0059] Step 218, obtaining the event code and the event code identification.

[0060] Step 219, sending the event code identification and the event code to the out-of-band management device.

[0061] The event code and the event code identification of the system event needing alarm are sent to the out-of-band management device, and the operation and maintenance personnel can identify the number of alarm events according to the event code identification, and can view the corresponding fault type corresponding to the event code according to the alarm code identification.

[0062] Step 310, processing according to the conventional SEL process.

[0063] After the event code and the event code identification processing of the present application Figure 2 , the system event can be processed according to the conventional system event log, for example, sent to the Web page displaying the system event log, and the recorded system event log is viewed.

[0064] Figure 3 The flowchart of the fan system event alarm embodiment provided by the present application;

[0065] Step 310, determine whether the resource class system event is a fan system event; if yes, execute step 311, if no, execute step 410.

[0066] The alarm levels of the resource class system events in the present application are the same, and the alarm levels of the resource class system events are not judged. However, the identification rules of the repeated system events of the fan system events and other resource class system events are different, and whether it is a fan system event can be determined according to the data of the componentized system events sent to the Web page for display.

[0067] Step 311, determine whether it is a fan in place system event; if yes, execute step 312, if no, execute step 314.

[0068] Step 312, determine whether there is a previous in place system event of the same fan; if yes, execute step 318; if no, execute step 313.

[0069] The event offset of the in place system event of the same fan and the fan out of place system event is different, and the in place system event of the same fan is considered as a pair of corresponding events of triggering and releasing, and does not need to be repeatedly alarmed.

[0070] In this step, if the event code 4 has been allocated for the in place system event of the same fan, the event code identification of the fan in place system event of the same fan does not need to be allocated, and is associated with the event code 4.

[0071] Step 313, generate an event code for the current fan in place system event and allocate an event code identification.

[0072] In this step, if there is no fan in place system event of the same fan, generate an event code for the current fan in place system event and allocate a new event code identification 5.

[0073] Step 314, determine whether there is a previous in place system event of the same fan; if yes, execute step 318; if no, execute step 315.

[0074] As above, the in place system event of the same fan is considered as a pair of corresponding events of triggering and releasing, and does not need to be repeatedly alarmed. In this step, if the event code 6 has been allocated for the out of place system event of the same fan, the event code identification of the fan in place system event of the same fan does not need to be allocated, and is associated with the event code 6.

[0075] Step 315, generate an event code for the current fan out of place system event and allocate an event code identification.

[0076] In this step, if there is no fan off-site system event generated by the same fan, an event code is generated for the current fan off-site system event, and a new event code identifier 7 is assigned.

[0077] Step 316, the event code and the event code identifier are obtained.

[0078] Step 317, the event code identifier and the event code are sent to the out-of-band management device.

[0079] The event code and the event code identifier of the fan system event that needs to be alarmed are sent to the out-of-band management device, and the operation and maintenance personnel can identify the number of fan system events according to the event code identifier, and can view the corresponding fan alarm according to the alarm code identifier.

[0080] Step 318, the SEL process is processed according to the conventional process.

[0081] After the event code and the event code identifier of the application Figure 3 are processed, the system event log is processed according to the conventional process, for example, sent to the Web page displaying the system event log, and the recorded fan alarm system event is viewed.

[0082] Figure 4 The flowchart of the trigger type and the release type system event alarm embodiment provided by the application;

[0083] Step 410, it is judged whether the resource type system event is a trigger type system event; if not, step 411 is executed, and if yes, step 414 is executed.

[0084] The alarm levels of the resource type system events of the application are the same, and the alarm levels of the resource type system events are not judged, and the trigger type or the release type system event can be identified according to the event characteristic description field of the system event.

[0085] Step 411, it is judged whether the same device release type system event has been generated before; if yes, step 412 is executed, and if not, step 413 is executed.

[0086] Step 412, the event code identifier of the previously generated release type system event is associated with the current release type system event.

[0087] In this step, if the current resource type system event is a memory CE release event, the recorded SEL is searched to determine that the same memory CE release event has been generated before and the event code identifier is event code identifier 7; and the current memory CE release event is associated with the event code identifier 7 of the same memory CE release event that has been assigned.

[0088] Step 413, an event code is generated for the current release type system event and an event code identifier is assigned.

[0089] In this step, if the current resource class system event is a memory CE release event, the recorded SEL is searched to determine whether a same memory CE trigger event has been generated before, and the current release class system event is a new release class event of the same memory; or a CE release event of different memory, the current memory CE release event is a new resource class system event, and an alarm needs to be given, an event code is generated based on the current CE release event, and the event code identifier 8 is allocated.

[0090] Step 414, it is judged whether a trigger class system event of the same device has been generated before; if yes, step 415 is executed; if no, step 416 is executed.

[0091] Step 415, the event code identifier of the trigger class system event generated before is associated with the current trigger class system event.

[0092] In this step, if the current resource class system event is a memory CE trigger event, the recorded SEL is searched to determine whether a same memory CE trigger event has been generated before and the event code identifier is event code identifier 9; the current memory CE trigger class event is associated with the event code identifier 9 of the CE trigger event of the same memory which has been allocated.

[0093] Step 416, an event code is generated for the current trigger class system event and the event code identifier is allocated.

[0094] In this step, if the current resource class system event is a memory CE trigger event, the recorded SEL is searched to determine whether a same memory CE release event has been generated before, the current trigger event is a new CE trigger event of the same memory or a CE trigger event of different memory, the current memory CE trigger event is identified as a new resource class system event, an alarm needs to be given, an event code is generated based on the current CE trigger event, and the event code identifier 10 is allocated.

[0095] Step 417, the event code and the event code identifier are obtained.

[0096] Step 418, the event code identifier and the event code are sent to the out-of-band management device.

[0097] The event code and the event code identifier of the system event which needs to be alarmed are sent to the out-of-band management device, and the number of the fan system events which occur can be identified according to the event code identifier by the operation and maintenance personnel, and the corresponding fan alarm corresponding to the event code can be viewed according to the alarm code identifier.

[0098] Step 419, the SEL process is processed according to the conventional process.

[0099] After the application Figure 4After the event code and event code identifier processing, the resource class system event is processed according to a conventional resource class system event log, such as being sent to a web page displaying the resource class system event log, and the recorded resource class system event is viewed.

[0100] Figure 5 The device 500 for sending keep-alive packets provided by the embodiment of the application further includes a processor, a memory, a baseboard management controller, a sensor (not shown), a communication interface, and a bus. Figures 2-4 The system event alarm method shown.

[0101] The above only describes the preferred embodiments of the present application and is not intended to limit the present application. Any modification, equivalent replacement, improvement, etc. made within the spirit and principle of the present application shall be included in the protection scope of the present application.

Claims

1. A system event alarm method, characterized in that, The method includes: The system events to be viewed that require alerts are determined based on a pre-defined list of alarm event rules. The components requiring alarms and the alarm types are determined based on the event types of the system events to be viewed; Based on the duplicate event identification rules corresponding to the alarm type, identify whether the system event to be viewed is a duplicate of the previous system event of the device that needs to be alarmed; When the system event to be viewed does not repeat the previous system event, an event code indicating the event type is generated based on the system event to be viewed; the event code is stored and an associated event code identifier is assigned; wherein, the event code identifier is unique within the current baseboard management controller operating cycle; the event code identifier and the event code are sent to the out-of-band management device to view the event code based on the event code identifier to obtain the event type of the system event to be viewed.

2. The method according to claim 1, characterized in that, The method also includes, When the system event to be viewed is the same as the previous system event, the assigned event code identifier associated with the previous system event is associated with the system event to be viewed, so that the out-of-band management device can view the event code corresponding to the assigned event code to obtain the previous system event and the event type of the system event to be viewed.

3. The method according to claim 2, characterized in that, Based on the event type of the system event to be viewed, the alarm type is determined to be a fault alarm; The rule for identifying whether the system event to be viewed is repeated with a previous system event based on the duplicate event identification rule corresponding to the alarm type includes: when the fault alarm level of the system event to be viewed is a normal alarm, searching for previous system events with the same and unresolved normal alarms; as well as When the fault alarm level of the system event to be viewed is an abnormal alarm, check if there are any previous system events with the same abnormal alarm that have not been cleared.

4. The method according to claim 2, characterized in that, Based on the event type of the system event to be viewed, the alarm type is determined to be a fan resource alarm; The step of identifying whether the system event to be viewed is a duplicate of a previous system event based on the duplicate event identification rule corresponding to the alarm type includes: when the system event to be viewed is a fan-in-position triggered alarm event, checking whether there is a fan-out-of-position triggered alarm event; and... When the system event to be checked is a fan not in place alarm event, check if there is a same fan in place alarm event.

5. The method according to claim 1, characterized in that, Based on the event type of the system event to be viewed, the alarm type is determined to be a trigger-based alarm; The rule for identifying whether the system event to be viewed is a duplicate of a previous system event based on the alarm type includes: checking whether there are any trigger-type alarm events of the same device that have not been cleared.

6. The method according to claim 1, characterized in that, Based on the event type of the system event to be viewed, the alarm type is determined to be a clearance alarm; The rule for identifying whether the system event to be viewed is a duplicate of a previous system event based on the alarm type includes: checking whether there are any unresolved alarm events for the same device.

7. The method according to claim 2, characterized in that, The event code includes: component type information, event category information, first event subcategory information, and second event subcategory information; wherein... The component type information is obtained from the sensor type field of the system event to be viewed; The event category information is obtained from the event feature description field of the system event to be viewed; The first event subcategory information is obtained from the first event data field of the system event to be viewed; The second event subcategory information is obtained from the second event data field of the system event to be viewed.

8. The method according to claim 3, characterized in that, The event type of the system event to be viewed is a fault alarm type and the alarm level is a normal alarm. The assigned event code identifier of the previous system event of the same normal alarm that has not been cleared is associated with the system event to be viewed. or, The system event to be viewed is of the fault alarm type and the alarm level is the abnormal alarm. The assigned event code identifier of the previous system event of the same and unresolved abnormal alarm is associated with the system event to be viewed.

9. The method according to claim 1, characterized in that, The method further includes sending the system event to be viewed to the system event log web page for viewing when it is determined based on a preset alarm event list that the system event to be viewed does not require an alarm.

10. The method according to claim 4, characterized in that, The event type of the system event to be viewed is determined to be a fan resource alarm and the system event to be viewed is a fan absence triggered alarm event. The assigned event code identifier of the same fan absence triggered alarm event is associated with the system event to be viewed. or, The system event to be viewed is a fan absence alarm event and a fan presence alarm event. The assigned event code identifier of the same fan absence alarm event is associated with the system event to be viewed.

11. The method according to claim 5, characterized in that, The event type of the system event to be viewed is determined to be a trigger-type alarm, and the assigned event code identifier of the trigger-type alarm event of the same device is assigned to the system event to be viewed.

12. The method according to claim 6, characterized in that, The event type of the system event to be viewed is determined to be an alarm clearing event. The assigned event code identifier of the clearing alarm event of the same device is assigned to the system event to be viewed.

13. A system event alarm device, characterized in that, It includes a processor, a memory, a baseboard management controller, a communication interface, and a bus; the baseboard management controller implements the system event alarm method of any one of claims 1-12 by running processor-executable instructions in the memory.

Images