WO2016161760A1 - Method and apparatus for processing alarm test - Google Patents

Abstract

Disclosed are a method and apparatus for processing an alarm test. The method comprises: receiving an alarm message for an alarm test; and verifying the alarm message, and when the verification succeeds, judging whether to perform the alarm test on a recovery alarm message corresponding to the alarm message or not. By means of the present invention, the problem of incapability of performing an automatic recovery test on an alarm message in the related art is solved, thereby performing the automatic recovery test on the alarm message.

Description

Alarm test processing method and device Technical field

The present invention relates to the field of communications, and in particular, to a test processing method and apparatus for an alarm.

Background technique

With the rapid development of the network, the number of network devices has maintained rapid growth, and the management capabilities of network management software have also maintained strong demand. In the basic functions of network management technology, alarms occupy an extremely important position. Because the alarm module monitors the running status of the network at all times, it can display various conditions of the network element, and can provide early warning information and solutions for emergencies. At the same time, the alarm is also related to the topology, rack diagram, performance, configuration and other modules. Therefore, in system testing and various field tests and network access tests, the alarm test is a must.

In the past, the alarm test was performed. The manual method was used to manually generate an alarm on the device. Then, check whether it was received on the NMS, and check whether the related processing is correct. This method is not automated, the efficiency is low, and coverage is limited. It must also rely on real device alerts, which are often not possible when the device environment is not available.

If you use a tester, it is costly and complicated to use. And can not send complex data packets, especially a variety of customized snmp trap messages.

The analog network element is generally used in the stress test. Although the device simulation software is powerful, it is impossible to realize flexible control of data transmission because it is a complete simulation of the device.

The number of analog network elements is limited by computer resources, making it difficult to conduct large-scale stress tests. Moreover, it is necessary to record the relevant data of the network element in advance, and the workload is large. This system only cares about the alarm itself, so there is no such limitation.

When using network element simulation, you need to consider how the alarm network element triggers the alarm, but you do not need to consider using this system test.

For the related art, the problem that the automatic recovery test of the alarm message cannot be performed has not yet provided an effective solution.

Summary of the invention

The embodiment of the invention provides a test processing method and device for alarms, so as to solve at least the problem that the related technology cannot perform automatic recovery test on the alarm message.

According to an aspect of the embodiments of the present invention, a test processing method for an alarm is provided, including: receiving an alarm message for an alarm test; verifying the alarm message, and determining whether the verification is successful Performing a recovery alarm test on the alarm corresponding to the alarm message.

Further, determining whether to perform the recovery alarm test on the alarm corresponding to the alarm message includes: acquiring a first configuration command for resolving the fault corresponding to the alarm message if the determination result is yes.

Further, after acquiring the first configuration command for resolving the fault corresponding to the alarm message, the method includes: comparing the first configuration command with a second configuration command in the preset script; And configuring, according to the first configuration command and the test script, the recovery alarm message; if the comparison result is inconsistent, assembling a script for resolving the failure to obtain an assembled script, according to the assembled script And the test script constructs the recovery alarm message, or constructs the recovery alarm message according to the preset script and the test script.

Further, acquiring the first configuration command for resolving the fault corresponding to the alarm message comprises: retrieving the configuration command in the configuration script library according to the attribute information of the alarm message.

Further, the alarm message is obtained according to a test script.

According to another aspect of the present invention, a test processing apparatus for alerting is provided, the device comprising: a receiving module configured to receive an alert message for an alert test; and a determining module configured to set the alert The packet is verified, and if the verification is passed, it is determined whether the alarm corresponding to the alarm packet is restored.

Further, the device further includes: an obtaining module, configured to acquire, when the determination result is yes, a first configuration command for resolving a fault corresponding to the alarm message.

Further, the device further includes: a comparison module, configured to compare the first configuration command with a second configuration command in the preset script; the first constructing module is configured to, if the comparison result is consistent, according to The first configuration command and the test script construct the recovery alarm message; the second constructing module is configured to assemble a script for resolving the fault to obtain an assembled script if the comparison result is inconsistent, according to the The assembled script and the test script construct the recovery alarm message, or construct the recovery alarm message according to the preset script and the test script.

Further, the acquiring module is further configured to retrieve the configuration command in the configuration script library according to the attribute information of the alarm message.

Further, the alarm message is obtained according to a test script.

In the embodiment of the present invention, an alarm message for receiving an alarm test is received; the alarm message is verified, and if the verification is passed, it is determined whether the alarm test is performed on the recovery alarm message corresponding to the alarm message. The problem that the automatic recovery test of the alarm packet cannot be performed in the related art is solved, and the automatic recovery test of the alarm packet can be implemented.

DRAWINGS

The drawings are intended to provide a further understanding of the embodiments of the present invention, and are intended to be a part of the present invention, and the description of the present invention is not intended to limit the invention. In the drawing:

1 is a flowchart of a test processing method of an alarm according to an embodiment of the present invention;

2 is a block diagram showing the structure of a test processing apparatus for an alarm according to an embodiment of the present invention;

3 is a structural block diagram (1) of a test processing apparatus for an alarm according to an embodiment of the present invention;

4 is a structural block diagram (2) of a test processing apparatus for an alarm according to an embodiment of the present invention;

FIG. 5 is a flowchart of an alarm test operation according to an embodiment of the present invention; FIG.

6 is a schematic diagram of a system environment of a system test or a network access test according to an embodiment of the present invention;

7 is a flow chart (1) of an alarm test operation according to an embodiment of the present invention;

8 is a simulation diagram of a stress test scenario in accordance with an embodiment of the present invention;

9 is a network diagram of a system test according to an embodiment of the present invention.

detailed description

The invention will be described in detail below with reference to the drawings in conjunction with the embodiments. It should be noted that the embodiments in the present application and the features in the embodiments may be combined with each other without conflict.

In this embodiment, a test processing method for an alarm is provided. FIG. 1 is a flowchart of a test processing method for an alarm according to an embodiment of the present invention. As shown in FIG. 1, the flow includes the following steps:

Step S102: Receive an alarm message for an alarm test.

Step S104: The alarm message is verified, and if the verification is passed, it is determined whether the alarm corresponding to the alarm message is resumed.

Through the above steps, when the received alarm message meets the requirements, the alarm corresponding to the alarm message can be restored, and the alarm test can be performed on the alarm message, which can solve the problem in the related art. The problem of automatic recovery test for alarm packets is implemented, and the automatic recovery test of alarm packets can be implemented. Because some alarms do not need to test recovery alarms, there are related processes such as generating reports. The alarm recovery automation test and the automated test of the associated module can be selected according to the actual situation.

After determining, in step S104, whether to perform a recovery alarm test on the alarm corresponding to the alarm message, in an optional embodiment, if the determination result is yes, acquiring the first fault for resolving the fault corresponding to the alarm message Configuration commands for updating test scripts.

After obtaining the first configuration command for resolving the fault corresponding to the alarm message, comparing the first configuration command with the second configuration command in the preset script. In an optional embodiment, if the comparison result is consistent, the first configuration command is fed back to the test script, and the recovery alarm message is constructed according to the first configuration command and the test script; in another optional embodiment If the comparison result is inconsistent, the script for assembling the fault is assembled, the assembled script is obtained, the assembled script or the preset script is fed back to the test script, and the recovery is constructed according to the assembled script and the test script. The alarm message is configured, or the recovery alarm message is constructed according to the preset script and the test script. Therefore, it provides a prerequisite for performing alarm test on recovering alarm packets.

In the process of obtaining the first configuration command for resolving the fault corresponding to the alarm message, in an optional embodiment, the configuration command is retrieved in the configuration script library according to the attribute information of the alarm message.

In an alternative embodiment, the alert message is obtained from a test script.

In the embodiment, a test processing device for alerting is also provided, which is used to implement the above-mentioned embodiments and preferred embodiments, and has not been described again. As used below, the term "module" may implement a combination of software and/or hardware of a predetermined function. Although the apparatus described in the following embodiments is preferably implemented in software, hardware, or a combination of software and hardware, is also possible and contemplated.

2 is a structural block diagram of a test processing apparatus for an alarm according to an embodiment of the present invention. As shown in FIG. 2, the apparatus includes: a receiving module 22 configured to receive an alarm message for an alarm test; and a determining module 24 configured to The alarm packet is verified, and if the verification succeeds, it is determined whether the alarm corresponding to the alarm packet is restored.

3 is a structural block diagram (1) of a test processing apparatus for an alarm according to an embodiment of the present invention. As shown in FIG. 3, the apparatus further includes: an obtaining module 32, configured to acquire, when the determination result is yes, acquire The first configuration command for resolving the fault corresponding to the alarm message.

4 is a structural block diagram (2) of a test processing apparatus for an alarm according to an embodiment of the present invention. As shown in FIG. 4, the apparatus further includes: a comparison module 42 configured to set the first configuration command and the preset script The second configuration command is compared. The first configuration module 44 is configured to feed back the first configuration command to the test script if the comparison result is consistent, and construct the recovery alarm according to the first configuration command and the test script. a second construction module 46, configured to assemble a script for resolving the fault to obtain an assembled script, and to feed back the assembled script or the preset script to the test script, if the comparison result is inconsistent. And the recovery alarm message is constructed according to the assembled script and the test script, or the recovery alarm message is constructed according to the preset script and the test script.

Optionally, the obtaining module 32 is further configured to retrieve the configuration command in the configuration script library according to the attribute information of the alarm message.

Optionally, the alarm message is obtained according to the test script.

It should be noted that each of the above modules may be implemented by software or hardware. For the latter, the foregoing may be implemented by, but not limited to, the foregoing modules are all located in the same processor; or, the above modules are respectively located. In the first processor, the second processor, and the third processor.

For the above problems existing in the related art, the following description will be made in conjunction with specific alternative embodiments, which are combined with the above-described alternative embodiments and alternative embodiments thereof.

The main purpose of the embodiment of the present invention is to solve the technical problem of the automated intelligent test in the network management alarm. It can improve the efficiency of system testing and reduce various costs, thus laying a solid foundation for field testing and network testing, and has guiding significance for solving actual network faults, and ultimately improving the quality and user satisfaction of network management software.

The optional embodiment provides a closed loop system. As shown in FIG. 5, the system portal is a service scenario to be tested. Automatically generate alarm packets based on service parameters. After the NMS receives the received, displayed, and feedback processing results and solutions, if a recovery alarm is generated, it is sent to the NMS again to test the recovery process. The exit is the result of processing the alarm information and the like.

This alternative embodiment can simulate all the alarms in the scene if the correct parameters have been obtained. Tested frequently The important alarms are: interface down, link broken link, NE status disconnected, Open Shortest Path First (OSPF) neighbor DOWN, non-self-generated link state broadcast in OSPF link state database The number of the Link-State Advertisement (LSA) exceeds the maximum value, and the neighbor relationship is rolled back from 2WAY to 2WAY. The Intermediate System-to-Intermediate System (ISIS) receives the illegal packet and the routing information. The neighboring information of the routing information protocol (RIP) is invalid. The number of prefixes received from the neighbors of the Border Gateway Protocol (BGP) exceeds the configured maximum number of prefixes. The number of routes entering the vrf exceeds the configured alarm limit. The over-limit, ring-switching event, hot-standby switchover, tunnel switchover event, Bidirectional Forwarding Detection (BFD) session failure, remote continuous severe errored second (FECSES) limit, power over-temperature protection alarm. In the system test, such important alarms are simulated first. By continuously enriching the test script library, the test automation, intelligence level and coverage rate can be gradually improved, and finally the goal that is difficult to achieve by manual testing is achieved.

The following is a further explanation of the specific process:

According to the system test or the network test design scenario environment, as shown in Figure 6, the network element type and version, the network element management IP address, the network segment and the mask, the interface IP address and mask, and the head and tail of the link have been defined. Endpoint and link attributes, Open Shortest Path First (OSPF)/Intermediate system to intermediate system (ISIS)/BGP routing protocol type and advertising network segment, two or three Virtual Private Network (VPN)/Tunnel Service Type and Protection Information, CFM, BFD, Virtual Router Redundancy Protocol (VRRP), Operation Administration and Maintenance (Operation Administration and Maintenance) , referred to as OAM) key parameters such as detection type.

Write alarm test plans and test cases, define test procedures, and configure configuration scripts if you need to test recovery alarms. Use the alarm simulation tool defined in this system to write an automated test script. The parameters of the script use the business parameters planned in the previous step.

The alarm simulation tool automatically generates alarm traps in the test cases based on the test scripts and sends them to the NMS through the network card. This process simulates the process by which a real network element sends an alert. Therefore, the NMS considers that it receives a normal alarm and processes it according to common logic.

For the alarms that need to test the recovery logic, the flow chart is shown in Figure 5.

For the alarms reported, test the alarm details and statistics displayed by the NMS. For each alarm, detailed information such as alarm number, NE location, generation time, level, alarm code, location, type, and confirmation status of the NE can be displayed. All attributes are correct and conform to the specifications. Can be filtered according to different dimensions, such as current and historical alarms, alarms and notifications, acknowledged and unacknowledged alarms, etc. According to the results, the following treatments are divided into

If the alarm is incorrect, collect the fault information and end the process.

If the alarm is correct, determine whether to continue testing the recovery alarm according to the test case. If the test is not performed, the process is terminated. If the test is performed, the fault value of the interface, routing protocol, service, etc. is determined by the attribute value in the alarm information, and the configuration command that can solve the fault is retrieved in the configuration script library. Compare the search results with the preset script, if it is correct, then feed back The service scenario solves the fault and creates the prerequisites for alarm recovery. If it is incorrect, assemble the correct script or use the preset script, and feed back to the business scenario. At the same time, update the script library and set the new data to be used.

After the fault is rectified in the service scenario, the alarm simulation tool is configured to automatically generate a recovery alarm for the alarm and send it to the NMS. Whether the test alarm can be recovered normally. If not, collect the fault information and end the process. If the fault can be recovered normally, submit the script to be used in the configuration script library. The status is set to available and the process ends.

The flow chart of other test cases is shown in Figure 7:

According to the preset time interval, the network management automatically generates statistical reports. The content includes statistics summary of various types of alarms in a specific period of time, such as the number of alarms received, the number of discarded packets, the type of alarms, the network element, and the level distribution. This serves as a basis for judging the network operating status and provides early warning of major problems. The test result is fed back into the test scenario. If the result is correct, the test ends; if it is not correct, return to the network management to find the specific fault.

Some alarms can trigger other modules. After the performance of the out-of-bounds alarm is reported, the intelligent configuration module can be triggered to issue the modified cir and pir values. After receiving such alarms, the NMS generates intelligent configuration instances, creates version files, configures file management tasks, schedules database backups, deletes operations, and performs dual-machine switching. The test result is fed back into the test scenario. If the result is correct, the test ends; if it is not correct, return to the network management to find the specific fault.

After receiving the alarm, the NMS performs the following operations: confirmation/reconfirmation, filtering and filtering, forwarding, clearing, setting rules, and exporting. After the internal processing of the alarm module, check whether the alarm is correctly confirmed/reconfirmed, filtered, forwarded, cleared, and so on. The test result is fed back into the test scenario. If the result is correct, the test ends; if it is not correct, return to the network management to find the specific fault.

The stress test scenario is shown in Figure 8. With 5-10 alarm simulation tools, each tool sends an alarm every 30MS-40MS, each tool continuously sends 12000 alarms, or the tool sends a total of 120,000 alarms. The verification alarm module can handle up to 120,000 alarms without packet loss. The average processing is about 250 per second. Record the test time, number of alarms, and packet loss each time after multiple tests. The test result is fed back into the test scenario. If the result is correct, the test ends; if it is not correct, return to the network management to find the specific fault.

Service alarms are generally associated with modules such as rack map, topology, and configuration management. After receiving the alarm, the NMS automatically determines whether the color of the rack, the chassis, the board, and the port is correctly displayed on the rack. The hidden board is hidden and the recovered alarm is automatically refreshed. The NE is updated in the topology. The status and color of the link and the packet indicate the path after the service is switched. After the switchover, the primary path is restored. In the configuration management, information such as the interface down and the routing protocol neighbor down is displayed. The test result is fed back into the test scenario. If the result is correct, the test ends; if it is not correct, return to the network management to find the specific fault.

The implementation of the system of the present invention will be further described in detail below with reference to the accompanying drawings.

Step 1: Design a system test scenario (see Figure 9) and plan various parameters, including interface address, routing protocol, service type, and protection path.

Address planning

2. OSPF planning:

3. LDP planning:

Step 2: Write an alarm test case, test the alarm, and resume the alarm process. Based on the parameters of the previous step, create a test script that is not connected to the Ethernet port.

Type: alarm code [1024] Ethernet port is not connected 1356074143: 242282/10.46.60.93->/10.46.35.19protocol (17) priority(0) hop(252) offset(0)ident(21326)UDP 161>162

TrapOid: .1.3.6.1.4.1.3902.3.302.8.1

SMI_GAUGE32,1056,.1.3.6.1.4.1.3902.3.302.1.1.1

SMI_GAUGE32, 1024, .1.3.6.1.4.1.3902.3.302.1.1.2

SMI_INTEGER,1,.1.3.6.1.4.1.3902.3.302.1.1.3

SMI_INTEGER,1,.1.3.6.1.4.1.3902.3.302.1.1.4

SMI_INTEGER,0,.1.3.6.1.4.1.3902.3.302.1.1.5

SMI_GAUGE32, 980471928, .1.3.6.1.4.1.3902.3.302.1.1.6

SMI_GAUGE32, 980471947, .1.3.6.1.4.1.3902.3.302.1.1.7

SMI_GAUGE32,203,.1.3.6.1.4.1.3902.3.302.1.1.8

SMI_STRING,fe:00:06:fe:04:ff:ff:ff:fe:04:01:fe:fe:fe:fe:fe:fe:fe:fe:fe:fe:fe:fe:fe: Fe:fe:fe:fe:fe:fe,.1.3.6.1.4.1.3902.3.302.1.1.9

SMI_INTEGER,1,.1.3.6.1.4.1.3902.3.302.1.1.10

SMI_INTEGER,0,.1.3.6.1.4.1.3902.3.302.1.1.11

SMI_INTEGER,0,.1.3.6.1.4.1.3902.3.302.1.1.12

SMI_STRING, 00:00:00:00:00:00:00:00:00:00,.1.3.6.1.4.1.3902.3.302.1.1.13

SMI_GAUGE32,0,.1.3.6.1.4.1.3902.3.302.1.1.14

SMI_STRING, Ethernet Port Link Down, .1.3.6.1.4.1.3902.3.302.1.1.19

SMI_GAUGE32,839,.1.3.6.1.4.1.3902.3.302.12.1

Step 3: Use the alarm simulation tool to generate an alarm packet and send it to the NMS. After the network management is received, the alarm module performs the following processing:

The detailed information of the alarm is displayed in the current alarm. The alarm number is 1411008035312, the severity is the severity, and the value is red. The type is the communication alarm. The time is the time sent by the alarm simulation tool. The alarm code is DOWN (2151). The confirmation status is unconfirmed. The IP address of the NE is 10.46. 60.93, the network element type is a ZTE model router, the positioning frame in the network element is =0, the chassis =0, the alarm is caused by the unsuccessful negotiation of the port link (50901), and the additional text alarm type: LACP; The interface (index= 20, name=Gei_0/0/0/10) turns into INACTIVE; generated by alarm synchronization.

Step 4: According to the test case, it needs to be restored immediately. Through the attribute value in the alarm information, the fault cause is the interface Gei_0/0/0/10 down of the network element 10.46.60.93, which is retrieved in the configuration script library. The configuration command that can solve the fault is to configure no shutdown in interface mode. The search result is compared with the preset script and is completely matched. In this scenario, the fault of the interface down can be solved and the alarm recovery is continued.

Step 5: After receiving the request, the alarm simulation tool automatically generates a recovery alarm according to the same parameter and sends it to the network management system. After the alarm is restored, the port is not connected to the alarm and the alarm is cleared from the current alarm interface. The test case ends. If there is a script in the script library to be used, you need to submit the script state as available before ending the use case.

Step 6: Check the statistics report automatically generated by the NMS. The content is a summary of all kinds of alarms in the test period. A serious alarm is received. There is no packet loss. The NE type is a model of ZTE. It is a major problem that needs to be solved immediately. The result is correct and the test case ends.

Step 7: After the alarm is restored, the NMS automatically triggers the intelligent configuration module. According to the predefined instance, run the show version, show ip interface, and show l2vpn to check the port and service recovery. Save the execution result file to the specified client. The result is correct and the test case ends.

Step 8: Interface alarm association topology, rack diagram, configuration management and other modules. After the NMS receives the alarm, the rendering port Gei_0/0/0/10 is red in the rack, and the rack and chassis are both 0. The NE, link, and packet color are red in the topology. The status is disconnected; in the configuration management, the service main path is disconnected, the traffic after the protection switching enters the standby path, and returns to the main path after the switchback; the interface is displayed in the interface management Gei_0/0/0/10down Display information such as OSPF and BGP neighbor down in the routing protocol. The result is correct and the test case ends.

Step 9: After the alarm is reported, confirm/de-confirm, filter, forward, clear, etc. The result is correct and the test case ends.

Step 10: In the stress test environment, the verification alarm module can process up to 120,000 alarms without losing packets. After multiple tests, record the test results:

B05 version of the alarm stress test process:

1. Alarm start time: 2013-12-05 10:23 points received a total of 120,000 alarms, the alarm start time 2013-12-05 10:24:19.000, the alarm end time is 2013-12-05 10:31:49.000, and the alarm processing speed is: 120000/450=266.67/s.

2. Alarm start time: 2013-12-05 After 11:21, the alarm start time is 2013-12-05 11:22:00.000, and the alarm end time is 2013-12-05 11:29:09.000, which is received in total. The alarm is 120,000, and the alarm processing speed is: 120000/429=279.72/s.

3. Alarm start time: 2013-12-05 16:35 minutes, the alarm start time is 2013-12-05 16:37:04.000, the alarm end time is 2013-12-05 16:43:04.000, received a total of There are 120000 alarms. The alarm processing speed is 120000/360=333.33/sec.

If the above test result is wrong, return to the corresponding module of the network management to find the specific fault.

In summary, the test processing method and device for the alarm provided by the embodiment of the present invention solve the problem that the automatic recovery test of the alarm message cannot be performed in the related art, and the automatic recovery test of the alarm message can be implemented.

In another embodiment, software is also provided for performing the technical solutions described in the above embodiments and preferred embodiments.

In another embodiment, a storage medium is further provided, wherein the software includes the above-mentioned software, including but not limited to: an optical disk, a floppy disk, a hard disk, an erasable memory, and the like.

Obviously, those skilled in the art should understand that the above modules or steps of the embodiments of the present invention can be implemented by a general computing device, which can be concentrated on a single computing device or distributed in multiple computing devices. Alternatively, they may be implemented by program code executable by the computing device such that they may be stored in the storage device by the computing device and, in some cases, may be different from The steps shown or described are performed sequentially, or they are separately fabricated into individual integrated circuit modules, or a plurality of modules or steps thereof are fabricated into a single integrated circuit module. Thus, embodiments of the invention are not limited to any specific combination of hardware and software.

The above description is only the preferred embodiment of the present invention, and is not intended to limit the present invention, and various modifications and changes can be made to the present invention. Any modifications, equivalent substitutions, improvements, etc. made within the spirit and scope of the present invention are intended to be included within the scope of the present invention.

Industrial applicability

The foregoing embodiments of the present invention can be applied to the field of communication, and solve the problem that the automatic recovery test of the alarm message cannot be performed in the related art, and the automatic recovery test of the alarm message can be implemented.

Claims (10)

An alarm processing method includes: Receiving an alarm message for the alarm test; The alarm message is verified, and if the verification is passed, it is determined whether the alarm corresponding to the alarm message is resumed. The method of claim 1, wherein determining whether to perform an alarm recovery test on the alarm corresponding to the alarm message comprises: If the determination result is yes, the first configuration command for resolving the fault corresponding to the alarm message is obtained. The method according to claim 2, wherein after obtaining the first configuration command for resolving the fault corresponding to the alarm message, the method comprises: Comparing the first configuration command with a second configuration command in the preset script; If the comparison result is consistent, constructing the recovery alarm message according to the first configuration command and the test script; If the comparison result is inconsistent, assembling a script for resolving the fault to obtain an assembled script, constructing the recovery alarm message according to the assembled script and the test script, or according to the preset script and the The test script constructs the recovery alarm message. The method according to claim 2, wherein the acquiring the first configuration command for resolving the fault corresponding to the alarm message comprises: And searching, according to the attribute information of the alarm message, the configuration command in the configuration script library. The method according to any one of claims 1 to 4, wherein the alert message is obtained from a test script. An alarm test processing device, the device comprising: a receiving module, configured to receive an alarm message for an alarm test; The judging module is configured to verify the alarm packet, and if the verification succeeds, determine whether to perform an alarm recovery test on the alarm corresponding to the alarm message. The apparatus of claim 6 wherein said apparatus further comprises: The obtaining module is configured to obtain, when the determination result is yes, a first configuration command for resolving a fault corresponding to the alarm message. The apparatus of claim 7 wherein said apparatus further comprises: a comparison module, configured to compare the first configuration command with a second configuration command in the preset script; a first configuration module, configured to construct the recovery alarm message according to the first configuration command and the test script, if the comparison result is consistent; The second constructing module is configured to: after the comparison result is inconsistent, assemble a script for resolving the fault to obtain an assembled script, construct the recovery alarm message according to the assembled script and the test script, or according to the The preset script and the test script construct the recovery alarm message. The apparatus according to claim 7, wherein the obtaining module is further configured to retrieve the configuration command in a configuration script library according to attribute information of the alarm message. The apparatus according to any one of claims 6 to 9, wherein the alarm message is obtained based on a test script.

Images