Method and system for processing fault information in NMS

• US 20050193285A1
• Filed: 12/10/2004
• Published: 09/01/2005
• Est. Priority Date: 02/11/2004
• Status: Abandoned Application

• Current Assignee: Samsung Electronics Co. Ltd.
• Original Assignee: Samsung Electronics Co. Ltd.
• Inventors: Jeon, Eung-Sun
• Application Number:
  US11/008,293
• Publication Number:
  US 20050193285A1
• Time in Patent Office: Days
• US Class Current: 714/48
• CPC Class Codes: G06F 11/0709 in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
• CPC Class Codes: G06F 11/0748 in a remote unit communicating with a single-box computer node experiencing an error/fault remote testing G06F11/2294
• CPC Class Codes: G06F 11/2294 by remote test

Abstract

A method in which a network management system (NMS) processes information on a fault, such as numerous alarms or events, generated from high-capacity network equipment and forwards the processed fault information to a client in real-time. More particularly, the present invention relates to a fault information processing method and system for processing alarms more rapidly and efficiently using database table modeling to improve a delay in storing data in an alarm database in applications, which is most problematic in processing alarms and events. With the present invention, the temporary storage of the traps in the listener table is simply performed by the fault management module and other additional functions spending time are performed by adopting an asynchronous transaction processing manner through the listener daemon module in order to more rapidly and quickly process a large amount of alarm and event information which could not be satisfied in an existing synchronous manner, thereby realizing real-time processing of a number of traps.

Claims

1. A method of processing fault information in a network management system, the method comprising:

a first process of collecting and storing fault generation information in a listener table, by a fault management module;

a second process of periodically deleting the fault generation information in said listener table on a partition-by-partition basis, by a listener daemon module; and

a third process of updating the fault generation information in an alarm table and an event table and processing a representative alarm, by the listener daemon module.

2. The method according to claim 1, wherein, in said first process, said fault management module parses and stores the collected fault generation information.

3. The method according to claim 1, wherein, in said first process, said fault management module stores the collected fault generation information in said listener table by periodically performing a bulk commit.

4. The method according to claim 1, wherein the fault generation information partitions in said second process are formed on the basis of a certain time.

5. The method according to claim 1, wherein the deletion of said fault generation information on a partition-by-partition basis in said second process refers to deleting old data partitions periodically.

6. The method according to claim 1, wherein said storage of the fault generation information to update the fault generation information in said alarm table and said event table by the listener daemon module in said third process is performed by a bulk commit.

7. The method according to claim 1, wherein said third process selects the representative alarm from a data package for a bulk commit for updating the fault generation information.

8. A network management system for enhancing a fault information processing speed, comprising:

a fault management module for collecting fault generation information from a network;

a listener table for storing the fault generation information periodically sent from said fault management module; and

a listener daemon module for deleting the fault generation information in said listener table on a partition-by-partition basis, updating the fault generation information in an alarm table and an event table, and selecting a representative alarm.

9. The system according to claim 8, wherein said fault management module parses and stores the collected fault generation information.

10. The system according to claim 8, wherein said fault management module stores the collected fault generation information in said listener table by periodically performing a bulk commit.

11. The system according to claim 8, wherein said listener table forms partitions on the basis of a certain time.

12. The system according to claim 8, wherein said listener daemon module performs a bulk commit to update the fault generation information in said alarm table and said event table.

13. The system according to claim 8, wherein said listener daemon module selects the representative alarm from a data package for a bulk commit for updating the fault generation information.

14. The system according to claim 8, wherein said listener daemon module periodically deletes old data partitions to delete the fault generation information on a partition-by-partition basis.

15. A method of processing fault information in a network management system, the method comprising:

when a trap generated in the network arrives at a fault management module, parsing, by said fault management module, the arrived trap data into a storable format and then temporarily storing in a listener table;

when the trap arrives, driving a timer for said fault management module to perform a bulk commit periodically;

periodically fetching, by a listener daemon module, all trap information following the last sequence from said listener table;

storing, by said listener daemon module, the trap information fetched from said listener table, in an alarm table and an event table;

performing collective representative alarm selection according to the selected class by said listener daemon module;

periodically deleting fault generation information in said listener table on a partition-by-partition basis by periodically deleting, by said listener daemon module, old data partition, the alarm information stored in said listener table being for polling by the clients, the already polled information being periodically deleted and with the periodic deletion, the storage in said listener table being temporary storage; and

monitoring, by said listener daemon module, said client list table and comparing the monitoring time to the last polling time of the client to determine whether the abnormal termination is made or not, when it is determined there is abnormal termination, then deleting by said listener daemon module, the list of abnormally terminated clients from said client list table.

16. The method of claim 15, further comprising of:

running, by the client, said fault manager, and then registering an identifier of the client on said client list table by an initial running, the client writing its running time information, and receiving an allocated identifier of the client identifier.

17. The method of claim 16, further comprising of:

after registering the identifier on said client list table, inquiring, by the client, of whether new alarm data is present, and the client performing polling to confirm whether newly arrived alarm information is present in said listener table, and checking whether a number larger than the last sequence number is present to confirm whether the new alarm data arrives.

18. The method of claim 17, further comprised of periodically fetching all traps following the last sequence by periodically polling said listener table to fetch newly arrived alarms, where the last sequence is used to distinguish the newly arrived alarms, and the last sequence, is the sequence number of the last alarm that is read when the clients periodically perform alarm polling.

19. The method of claim 17, wherein said listener daemon module stores the trap information, fetched from said listener table, in said alarm table when it is an alarm, and records the trap information in said alarm table when fault release is generated.

20. The method of claim 19, wherein when overlapped alarm is generated, the listener daemon module accordingly performs a generation count increment.

21. The method of claim 17, wherein said alarm table is formed of a table representing the generation or non-generation, generation times of a particular alarm, whenever faults are individually generated, the generation release or non-generation release and overlapped generation or non-overlapped generation are recorded in said alarm table and the fault generation information is updated.

22. The method of claim 17, wherein, when storing the trap information fetched from said listener table in said alarm table and said event table, said listener daemon module performs the bulk commit in which data is packaged and is collectively processed with a class in the data package showing the highest fault degree being selected.

23. The method of claim 17, further comprised of upon deleting old data including already read data, among alarm information stored in said listener table, deleting the stored data group on a partition-by-partition basis without finding and deleting the old data one by one, at this time, the partitions are created at certain intervals, and alarms contained in the certain interval are all stored in the same partition, when the time has elapsed, the old partition of the certain interval unit is deleted where the data contained in the partition is deleted at one time.

24. The method of claim 17, wherein said listener daemon module periodically deletes a list of abnormally terminated clients from said client list table, when said alarm manager has been normally terminated, each of the clients no longer performing the polling and deleting its information from said client list.

25. The method of claim 17, wherein said client performing direct network management by connecting to the network management system and collecting necessary network fault information.

26. A network management system for enhancing a fault information processing speed, comprising:

a fault management module parsing the arrived trap data into a storable format and then temporarily storing in said listener table, when a trap generated in the network arrives at said fault management module, when the trap arrives, driving a timer for said fault management module to perform a bulk commit periodically; and

a memory including a listener daemon module periodically fetching all trap information following the last sequence from said listener table, said listener daemon module storing the trap information fetched from said listener table, in said alarm table and said event table, said listener daemon module performing collective representative alarm selection according to the selected class by, said listener daemon module periodically deleting fault generation information on a partition-by-partition basis by periodically deleting old data partition, the alarm information stored in said listener table being for polling by the clients, the already polled information being periodically deleted and with the periodic deletion, the storage in said listener table being temporary storage, said listener daemon module monitoring said client list table and comparing the monitoring time to the last polling time of the client to determine whether the abnormal termination is made, when it is determined there is abnormal termination, then deleting by said listener daemon module, the list of abnormally terminated clients from said client list table, the client registering an identifier of the client on said client list table, the client writing its running time information, and receiving an allocated identifier of the client identifier, after registering the identifier on said client list table, inquiring, by the client, of whether new alarm data is present, and the client performing polling to confirm whether newly arrived alarm information is present in said listener table, and checking whether a number larger than the last sequence number is present to confirm whether the new alarm data arrives.

27. A computer-readable medium having computer-executable instructions for performing a method of processing fault information in a network management system, comprising:

when a trap generated in the network arrives, parsing the arrived trap data into a storable format and then temporarily storing in a first table;

when the trap arrives, performing a bulk commit periodically;

periodically fetching all trap information following the last sequence from said first table;

storing the trap information fetched from said first table, in a second table and said third table;

performing collective representative alarm selection according to the selected class;

periodically deleting fault generation information in said first table on a partition-by-partition basis by periodically deleting old data partition, the alarm information stored in said first table being for polling by the clients, the already polled information being periodically deleted and with the periodic deletion, the storage in said first table being temporary storage, upon deleting old data including already read data, among alarm information stored in said first table, deleting the stored data group on a partition-by-partition basis without finding and deleting the old data one by one;

monitoring a fourth table and comparing the monitoring time to the last polling time of the client to determine whether the abnormal termination is made or not, when it is determined there is abnormal termination, then deleting the list of abnormally terminated clients from said fourth table;

registering an identifier of the client on said fourth table, the client writing its running time information, and receiving an allocated identifier of the client identifier; and

after registering the identifier on said fourth table, inquiring, by the client, of whether new alarm data is present, and the client performing polling to confirm whether newly arrived alarm information is present in said first table, and checking whether a number larger than the last sequence number is present to confirm whether the new alarm data arrives.

28. A computer-readable medium having stored thereon a data structure comprising:

a first field containing data representing collecting and storing fault generation information in a listener table, by a fault management module;

a second field containing data representing periodically deleting the fault generation information in said listener table on a partition-by-partition basis, by a listener daemon module; and

a third field containing data representing updating the fault generation information in an alarm table and an event table and processing a representative alarm, by the listener daemon module.