Preparation of event correlation table for network

Description: TECHNICAL FIELD [Detailed description of the invention]

【0001】

[Technical field to which the invention belongs]

The present invention relates to a network management system that manages failures on a network, and is particularly a network management system having a function of identifying the root cause of a failure from various symptoms of failures observed on the network. On how to create an event correlation table that is used to correlate with the root cause of the failure.

【0002】

[Conventional technology]

The scale of computer-based communication networks is increasing. As communication networks become larger, the effects of failures that occur on the networks are becoming larger and more serious. Therefore, how to manage the network efficiently is very important. The terms related to network management used in this specification are defined below.

【0003】

An "event" is an exceptional condition that occurs in a network. Includes hardware and software failures, outages, performance bottlenecks, network configuration inconsistencies, unintended consequences due to inadequate design, and malicious damage such as computer viruses. "Bug" is used interchangeably with "event".

【0004】

"Symptom" means an observable event. Same as "symptomatology event". For example, "Communication always takes time for a certain destination A and re-transmission is required", "Characters are always garbled for a certain destination B", "Reception confirmation is not always returned for a certain destination C" "And other events. The word "Symptom" is also used interchangeably. "Problem" refers to the root cause of a failure. It is not always observable. For example, the transmitter of the communication device is damaged, the communication cable is broken, and the capacity of the communication line is insufficient. "Problem event" has the same meaning as "problem". The word "Problem" is also used interchangeably.

【0005】

An "object" is anything that has clear boundaries and meanings to a concept, abstraction, or problem of interest. "Object instance" means a specific object belonging to a certain object class described later. Also simply called an "instance". An "object class" is a group of objects that have similar properties (attributes), common behavior (operations), common relationships with other objects, and common meanings. A "class" is the same as an object class. A "subclass" is a class that is included in a class as a subclass of that class. "Attribute" means the data held by each object belonging to the class.

【0006】

"Object diagram" refers to a formal graphical notation for modeling objects, classes, and the relationships between them. A "class diagram" is a schema, pattern, template, etc. for describing many possible instances.

【0007】

The "repository" is a storage unit that aggregates necessary information and stores it in a list format. It should also be called an aggregate list memory. The "event repository" refers to a storage unit that stores a symptom pattern that actually occurs. "Object repository" refers to a repository of network configuration models. This makes it possible to identify in advance the "symptom pattern that occurs when a certain cause is assumed".

【0008】

A single problem event on a resource in the network can trigger many symptomatological events on multiple resources involved. Some problems are observable events, but in general they are not always observable. Therefore, it is necessary to identify the problem that is the root cause of the disorder from multiple symptoms. Therefore, the network administrator must be able to correlate the various symptomatological events observed with the problem in order to identify the root cause problem.

【0009】

However, as the network grows, so does the number of symptomatological events observed. Also, the causal relationship of which problem causes which symptomatology becomes complicated, making it almost impossible for the operator to manually identify the root cause of the failure.

【0010】

U.S. Pat. No. 5,528,516, issued June 18, 1996, is a prior art method for accurately and quickly identifying root cause problems from the vast number of failure symptom events observed on such networks. "PLC and Method for Event Correlation and Problem Reporting") has been proposed.

【0011】

This conventional technique can be divided into the following two techniques. (1) Managed network modeling technology (2) Event correlation technology "Managed network modeling technology" is a technology for accurately and efficiently modeling problem events and symptom events that occur on an actual network. The event correlation technology of (2) is mainly a technology of how to quickly identify the root cause problem from the huge number of observed symptom events. The present invention is not related to (1) the modeling technique of the managed network, but is related to (2) the event correlation technique. Therefore, in the following, the modeling technology of the managed network in (1) will be explained to a minimum. Although the following description is limited to events related to failures, any type of event may be used, and the present invention is not limited to events related to failures.

【0012】

The "managed network modeling technology" proposed in this conventional technology will be briefly described below. First, a managed object that consists of network devices such as routers and hubs, computers such as personal computers and workstations, the network itself that connects them, and software that runs on the computers. Model as. Then, with an emphasis on "relationships" between objects, problem and symptom events that occur on the network are modeled as "propagating" along the relationships set between managed objects. ..

【0013】

The prior art described above abstracts the static aspects of such managed object modeling and event propagation modeling and introduces object-oriented concepts for efficient modeling. That is, various managed objects are modeled as classes. Then define the relationships between the classes. In addition, some events are modeled as propagating along the relationships between classes. There are various textbooks on object-oriented technology, so please refer to them.

【0014】

Model the managed network based on the class system defined in this way. That is, a managed object in the network is abstracted as one instance of a class, and events are sent to these instances (managed objects) according to the relationship established between the class to which that instance belongs and the class to which the other instance belongs. ) Is modeled as propagating. In addition, the correlation between the problem and the symptomatology is pre-identified based on the network thus modeled.

【0015】

First, modeling of the managed object class will be described. Now consider the network shown in Figure 27 as an example of an actual network. This network contains two Ethernet works 534 and 536 that are connected to each other by a bridge 540. It is assumed that host 530 is connected to one Ethernet work 534 and host 532 is connected to the other Ethernet work 536. In the following example, host 530 is assumed to have a network management system (NMS).

【0016】

To model the network shown in FIG. 27 using the above idea: With reference to Figure 28, each box represents an object class (or subclass). Each box in the object class is divided into two boxes. The top box contains the object class name, and the bottom box contains the attributes that an object of that class should have. Relationships are set between each class, and each relationship is indicated by a line drawn between the classes. The name of the relationship is described in the vicinity of each line. In FIG. 28 and other drawings, the managed object model is described using OMT notation.

【0017】

Under Node class 524, we define three subclasses, TcpNode class 554, IpNode class 556, and EtherNode class 558, as shown in Figure 28. In addition, TcpLink class 560, IpLink class 562, EtherLink class 564 and MacBridgeLink class 566 are defined as subclasses of Link class 526. In addition, it is necessary to define attributes specific to each class. For example, the IP (Internet Protocol) address attribute is defined in the IpNode class. However, since the definition of attributes is not relevant to the present invention, detailed description of attributes will not be given here.

【0018】

The name of the relationship set between these classes changes depending on which of the two classes connected by the relationship is viewed. For example, the relationship 608 between Node class 524 and Link class 526 is Connected-via when viewed from one side and Connected-to when viewed from the other side. Also, although not shown in FIG. 28, there may be a relationship defined between objects in the same class.

【0019】

Using the class shown in FIG. 28, the network example shown in FIG. 27 can be represented as a relationship diagram between instances. Such diagrams are called "instance diagrams" in object-oriented technology.

【0020】

A symptom event propagation rule is prepared in advance for the managed object modeled in this way. This propagation rule rules the relationship that the problem event that is the root cause of a failure propagates to the symptomatology event of the failure and that symptomatology event propagates to another symptomatology event. This set of propagation rules is called a propagation model.

【0021】

Some events are problematic and symptomatic events, while others are neither. In such a propagation model (rule), event propagation is modeled in which each event propagates between instances according to the relationship defined between the classes of managed objects.

【0022】

When the event propagation model is assumed in this way, how the event propagates in the network shown in FIG. 27 is shown below. Here, we consider P1, P3, P4, and P5 as the root cause of the failure. In this case, as a result of these problems, the relationship between the symptomatological events expected to be observed according to the event propagation model and these problems is shown in FIG. 29, for example.

【0023】

In this table, symptomatological events are listed in each column of the leftmost column, and problem events are listed in each column of the first row. In the column where the column of a certain problem event and the row of a certain symptom event intersect, a value indicating whether or not the symptom event occurs when the problem event (cause) occurs is entered. In this case, enter "1" when a symptom event occurs. For example, when problem P1 occurs, symptom S1 occurs, but symptom S4 does not occur. If you look at the corresponding column vertically for each case, you will get a series of "1" and "blank (0)". This is referred to as the code of the symptom event group for the problem event. For example, in Case 1 of Fig. 29, the code of the symptomatology event group for problem P1 is "11100". The blank (blank) part is set to 0. The code of the symptomatology event group for problem P2 is "01100".

【0024】

As can be seen from FIG. 29, different problem events have different codes for the observed symptomatological events. Therefore, by comparing the symptomatological event group actually observed and collected by the network management system (NMS) with the symptomatological event group shown in FIG. 29, it is possible to identify the problem of the root cause of the failure. A table that shows the correlation between each problem and a symptomatological event in this way is called an event correlation table. In practice, this comparison is made by calculating the "distance" defined between the resulting symptomatological event group and the symptomatological event group in the event correlation table and identifying the problem with the shortest distance.

【0025】

[Problems to be Solved by the Invention]

If the symptom events that occur for a certain problem event are patterned in advance, the problem of the root cause of the failure can be achieved by a relatively simple task of comparing the symptom pattern when the failure actually occurs with this pattern. Can be identified. Therefore, it seems that this conventional technique makes it very easy to identify the problem that is the root cause of the failure. However, this conventional technique has the following problems.

【0026】

For example, in the event correlation table 620 shown in FIG. 29, symptom S5 occurs only when problem P5 occurs, and does not occur when problem P1, P3, and P4 occur. There are two interpretations of this. The first is the interpretation that symptom S5 does not occur when problems P1, P3, and P4 occur. The second is the interpretation that problems P1, P3, P4 and symptomatology S5 are unrelated. According to this second interpretation, it would be wrong to correlate symptomatology S5 with problems P1, P3, P4.

【0027】

However, if a correlation table is prepared as in the event correlation table 620 of FIG. 29, this correlation table will always be used according to the first interpretation described above. Therefore, if the relationship between problems P1, P3, P4 and symptomatology S5 should follow the second interpretation described above, the event correlation will be erroneous. In other words, in FIG. 29, the part surrounded by the dotted rectangles 622 and 624 is given an inappropriate code.

【0028】

In the above-mentioned conventional technique, a robust algorithm that can accurately identify the cause to some extent even in such a case has been proposed. However, when the network becomes large-scale and complicated, if the event correlation table is inappropriate, there is a great possibility that appropriate cause identification processing cannot be performed.

【0029】

Therefore, an object of the invention according to claim 1 is to provide a method for creating an event correlation table of a network, which makes it easy to reflect changes in the network configuration in the event correlation table.

【0030】

The object of the invention according to claim 2 is an event correlation table in which changes in the network configuration can be easily reflected in the event correlation table and the correlation between the failure and the cause can be performed more reliably. Is to provide a way to create.

【0031】

The object of the invention according to claim 3 is that it is easy to reflect the change in the network configuration in the event correlation table in a timely manner, and the correlation between the failure and the cause in which the request occurs is performed more reliably. It is to provide a way to create an event correlation table that can be.

【0032】

[Means for solving problems]

The method according to the invention according to claim 1 is a network event correlation table creation method for creating an event correlation table for correlating events occurring on a network with each other using a computer. This method is based on the steps of preparing the configuration information of a managed object on the network in the storage means of a computer, the configuration information of the managed object, and the event propagation rule between predetermined objects. Includes a step of creating and storing in a computer storage means and a step of creating a correlation table creation step of creating a machine-readable event correlation table based on an event node network and storing it in a computer storage means.

【0033】

According to this method, the network is once stored in the storage means of the computer in an intermediate format called an event node network. An event correlation table is created from this event node network. When the network configuration is changed, it is easy to reflect the difference indicating the configuration change in this event node network. Therefore, when the network configuration is changed, the event correlation table finally required can be easily changed. In addition, since the event node network clearly shows the event propagation relationship, it is possible to easily separate the event node networks having independent names from each other.

【0034】

In the method according to the invention of claim 2, in addition to the configuration of the invention of claim 1, the correlation table creation step is based on the event node network, and the event is performed for each group constituting the event node network independent of each other. Machine readable for each event node group based on the classified event nodes and the event node network in response to the steps to classify the nodes and the fulfillment of the given event correlation table creation conditions. Includes steps to create a formal event correlation table and store it in a computer's storage means.

【0035】

According to the method according to the invention of claim 2, the event nodes constituting the event node network are classified into groups constituting an event node network independent of each other, and an event correlation table is created for each group. Therefore, it is not treated as if there is some kind of relationship between the symptom and the cause, which are originally unrelated event nodes. When the cause is inferred from the failure, it is possible to prevent inappropriate correlation between the failure and the cause, as in the case of using a correlation table that is not an independent event correlation table as in the past. As a result, it is possible to create an event correlation table that can more reliably correlate the failure and the cause.

【0036】

The method according to the invention according to claim 3 is the method according to claim 1 or 2, wherein the event node network is reconfigured in response to the establishment of a predetermined reconstruction condition. It further includes a step of re-running the correlation table creation step based on the reconfigured event node network.

【0037】

When a predetermined reconfiguration condition is satisfied, such as when the network configuration changes and a request is received to reflect the change in the event correlation table, or a request is received to divide or integrate the event correlation table. In addition, when the event node network is reconfigured, the reconfigured event node network reflects the changes in the network configuration. Since an event correlation table is created from there, changes in the network configuration are also reflected in the event correlation table. This process is performed each time a request is made, and can be performed more easily than when the event node network is not used.

【0038】

BEST MODE FOR CARRYING OUT THE INVENTION

[Overall configuration] The problems described in the conventional technology occur because the problems and symptoms that should not be related to each other are always treated as if they were related to each other. Therefore, in the present invention, a method for separating problems and symptoms unrelated to each other is used.

【0039】

Figure 1 shows the network management system (NMS) 20 using the event correlation table created by the method according to the present invention in a block diagram format. With reference to FIG. 1, the network management system 20 is connected to the managed network 22, and uses a network management protocol such as SNMP (Simple Network Management Protocol) to collect data such as the MIB (Management Information Base) of the managed device. A managed object model ("MO") that receives data on network configuration information from the network interface section 24 for acquisition and polling, and the network interface section 24, and is improved as described later. May be omitted. ) And the event propagation model related to this, and was constructed by the configuration management unit 30 and the configuration management unit 30 for constructing the managed object configuration information based on these models and the network configuration information. Managed object The managed object repository 32 for holding the configuration information, the event repository 28 for holding the configuration information data and the failure information data as an event, and the configuration information data and the failure information data for the event from the network interface section 24. Receives and holds the event correlation table from the event database section 26 and the configuration management section 30 for holding it in the event database 28, receives a set of failure symptom events from the event database section 26, and receives the symptom of the event correlation table. The failure management unit 34 for comparing the event pattern with the actually observed symptom event pattern and calculating the distance to infer the problem of the root cause of the failure, and the problem of the root cause of the failure from the failure management unit 34. It includes a user interface unit 36 for receiving information indicating the inference result of the above and presenting it to the user.

【0040】

In the present embodiment, the method of creating the event correlation table has been improved, and these will be described later with reference to FIGS. 4 and later.

【0041】

The network management system shown in Figure 1 is actually implemented by software running on a computer, such as a personal computer or workstation. Figure 2 shows the appearance of a computer that implements a network management system. With reference to Figure 2, this computer has a computer body 40 with a CD-ROM (Compact Disc Read-Only Memory) drive 50 and a FD (Flexible Disk) drive 52, a display 42, a printer 44, and a keyboard 46. , Includes mouse 48 and.

【0042】

Figure 3 shows the configuration of this computer in block diagram format. As shown in FIG. 3, the main body 40 of the computer constituting this system 20 includes a CPU (Central Processing Unit) 56 connected to the bus 66 and a ROM (Central Processing Unit) 56, respectively, in addition to the CD-ROM drive 50 and the FD drive 52. It contains a Read Only Memory) 58, a RAM (Random Access Memory) 60, and a hard disk 54. The CD-ROM 62 is installed in the CD-ROM drive 50. The FD drive 52 is equipped with the FD64.

【0043】

As already mentioned, this network management system is made possible by computer hardware and software running on CPU 56. Generally, such software is stored in a storage medium such as a CD-ROM 62 or FD64 and distributed, and is read from the storage medium by a CD-ROM drive 50 or an FD drive 52 and temporarily stored in a hard disk 54. Furthermore, it is read from the hard disk 54 to RAM 60 and executed by the CPU 56. The computer hardware itself shown in Figures 2 and 3 is common. Therefore, the most essential part of the present invention is software stored in a storage medium such as a CD-ROM62, FD64, or hard disk 54.

【0044】

Since the operation of the computer itself shown in FIGS. 2 and 3 is well known, the detailed description thereof will not be repeated here.

【0045】

Hereinafter, the operation of the network management system 20 using the event correlation table created by the method according to the embodiment of the present invention shown in FIGS. 1 to 3 will be described. The network interface unit 24 acquires and polls data such as the MIB of the managed device by using a network management protocol such as SNMP. The network interface unit 24 also receives a trap event from the managed device. The network interface unit 24 further converts the data related to the configuration information among the data acquired from the managed device to the configuration management unit 30 and sends the data related to the failure information to the event database unit 26 in appropriate formats.

【0046】

The configuration management unit 30 holds the improved managed object model and the event propagation model related thereto. The configuration management unit 30 holds the managed object model and the event propagation model. These models can be read from a file (not shown) in the hard disk 54 shown in FIG. 3, or can be input by the user via the user interface unit 36.

【0047】

The configuration management unit 30 further receives configuration information data such as the network example shown in FIG. 27 from the network interface unit 24, and constructs the management target object configuration information based on the management target object model. This managed object configuration information is stored in the managed object repository 32.

【0048】

The event database unit 26 receives notifications about configuration information data and symptom events that occur during a predetermined time window from the network interface unit 24, and holds them in the symptomatology event repository 28. Among these events, the event database unit 26 notifies the failure management unit 34 of data related to the failure information, particularly the failure symptom event. Each time the configuration management unit 30 ends the predetermined time window, the configuration management unit 30 uses the managed object model and the event propagation model at that time, and the managed object configuration information stored in the managed object repository 32 to perform an event correlation table. To create. The configuration management unit 30 notifies the failure management unit 34 of the event correlation table.

【0049】

The fault management unit 34 receives and holds the event correlation table notified from the configuration management unit 30. The fault management unit 34 also receives from the event database unit 26 a set of symptomatological events of failures that occurred during a predetermined time window. This set of symptomatological events is a symptomatological event pattern that is actually observed. The failure management unit 34 compares the symptom event pattern of the event correlation table received from the configuration management unit 30 with the actually observed symptom event pattern received from the event database unit 26 each time the predetermined time window ends. Then identify the problem that is the root cause of the failure. The identified problem is notified to the user interface unit 36. The user interface unit 36 presents to the user information that identifies the problem that is the root cause of this failure, such as by the display 42 shown in FIGS. 2 and 3.

[Outline of processing] Fig. 4 and below show a flowchart of the processing executed by the program group for realizing the above processing. With reference to Figure 4, first create an instance of a class called the EventNodeNetwork class that manages the network consisting of EventNode, which will be described later (70). Each instance is created in computer memory. EventNode is a class that represents Problem and Symptom. Each EventNode manages information on all Propagating EventNodes and their propagation rates. The details of the EventNode Network creation process will be described later with reference to FIG.

【0050】

Then calculate the propagation rate of events between instances (72). Propagation rate refers to the probability that an event will propagate between EventNodes. By introducing the propagation rate in this way, it is possible to deal with a problem peculiar to a specific network. For example, only one device is more prone to problems than other devices of the same type, or the placement of cables connecting one device to another is more prone to certain problems. Sometimes. In this case, considering that the problem propagation rate is always constant for a certain combination of classes of objects that make up the network, it is insufficient as a model of an actual network problem. It is useful to set the propagation rate at the instance level in order to properly correlate the failure with the problem specific to a particular network. In step 72, this propagation rate is calculated.

【0051】

Topologies often change in networks. Therefore, when creating the event correlation table, it is necessary to recalculate the propagation rate based on the latest topology (network configuration information data). The calculation method of the propagation rate will be described later with reference to FIG. 10 and below.

【0052】

Then, create the next TimeWindow instance to prepare for the next event correlation process, and delete the TimeWindow from the TimeWindow list each time the Problem held by a TimeWindow is cleared (74). Note that TimeWindow is a class that represents the time frame that accepts failure events, and is for managing the Problem that is the result of correlation and the Symptom that affects the inference of that Problem. At the end of the time frame (time window) defined by this TimeWindow, the correlation table is created, the distance calculation (comparison) is performed, the next TimeWindow is created, and the Problem is notified to the client as described later. Is done.

【0053】

Next, it processes the subscribe / unsubscribe request from the client (76). A subscribe is a request notification from a client to a network management device that requests notification about a problem or Symptom. If there is a subscribe request, the network management device adds the client that issued the request to the subscribe list of the corresponding EventNode. Then, for the Problem or Symptom, a subscribe request is made to an instance of a class called EcReporter on the network to notify the network management device of an event occurring on the network. When a subscribe request is made for a problem, the subscription request is also made for all Symptoms propagated from the problem.

【0054】

For an unsubscribe request, the client that issued the request is deleted from the subscribe list of the corresponding EventNode. When the subscribe list is empty, make an unsubscribe request to EcReporter for Symptoms that are only related to the Problem, if it is related to the Problem. In the case of Symptom, make an unsubscribe request to EcReporter except for Symptom related to the subscribed Problem.

【0055】

Next, calculate the number of failures (Symptom) occurrences for each TimeWindow (78). In this case, the number of occurrences of a failure for each TimeWindow is retained as an occurrence status list.

【0056】

Next, create an event correlation table based on the EventNodeNetwork and the propagation rate (80). The process of creating the correlation table will be described later.

【0057】

Furthermore, the distance is calculated from the event correlation table created in this way and the failure information acquired in step 78 to correlate the failure (Symptom) with the cause of the problem (Problem) (82). .. The Problem thus identified is notified to the client who made the subscribe request (84).

【0058】

Hereinafter, the main processes among the processes shown in FIG. 4 will be described with reference to the drawings.

[Creation of EventNodeNetwork] In the process of creating EventNodeNetwork, first, when the network management device (server) is started, all the class names of MO Objects to be acquired are acquired from the managed object repository 32 (90).

【0059】

Obtain MO Object information from the Managed Object Repository 32 based on the class name obtained in step 90 (92).

【0060】

From the MO Object information obtained in step 92, create an instance of EventNode and register it in the management list of EventNodeNetwork for each event type (Problem, Symptom) (94). EventNode is an event node name, event type, export identifier, subscribe list, propagation destination list, propagation source list, propagation rate list, calculation value list of propagation rate for all Problem / Symptom to propagate, propagation rate identifier, correlation table. Has an identifier for the split state of.

【0061】

In addition, a propagation association is made for all EventNodes created in step 94 (96). Find the EventNode to which each EventNode is propagated from the management list of EventNodeNetwork and add it to the propagation destination list. At this time, the propagation rate to the child EventNode is also registered in the propagation rate list. The propagation destination list and the propagation rate list are managed in the same order. At the same time, the parent EventNode is registered in the propagation source list of the child EventNode.

【0062】

When the network topology information changes, the information is queued. Then, when the update request is received from the client, the EventNodeNetwork is reconfigured according to the changed topology information.

【0063】

The method of creating the EventNodeNetwork in step 90 and step 102 will be described with reference to FIGS. 6 to 9. For example, refer to Figure 6 and assume that the EventNodeNetwork for Problem P1-P3 and Symptom S1-S3 has already been created. In FIG. 6, each circle represents these EventNodes, and the lower right of each circle shows the propagation source list of the EventNode in the upper row, and the propagation destination list in the lower row.

【0064】

When an additional notification of MO Object (Problem P4) is received here, a new EventNode instance P4 is created. The resulting EventNode Network is shown in Figure 7. Comparing Fig. 6 and Fig. 7, the propagation source list of EventNode P3 has been changed from "P1" to "P1, P4" due to the addition of EventNode P4.

【0065】

It is assumed that the propagation from P1 to P3 has been deleted in the EventNodeNetwork shown in Fig. 7. The resulting EventNodeNetwork is shown in Figure 8. Comparing Fig. 7 and Fig. 8, it can be seen that the propagation destination list of P1 and the propagation source list of P3 have been changed.

【0066】

Further, it is assumed that EventNode P2 is deleted in the EventNodeNetwork shown in FIG. The resulting EventNodeNetwork is as shown in Figure 9. Comparing Fig. 7 and Fig. 9, in addition to the deletion of EventNode P2, the propagation destination list of P1 and the propagation source list of S1 and S2 have changed. Conversely, the list of each EventNode shown in FIGS. 6 to 9 is maintained, and the propagation source list and the propagation destination list as described in the lower right neighborhood of each EventNode of FIGS. 6 to 9 are maintained. EventNodeNetwork is expressed by maintaining in EventNode. Therefore, changes in the EventNodeNetwork are expressed as changes in the elements of the EventNode list and changes in the source and destination lists for each EventNode.

【0067】

The calculation of the propagation rate shown in FIG. 4 will be described with reference to FIGS. 10 and below. In this process, the event correlation table is also divided at the same time. The propagation rate is calculated in advance before the event correlation table is created and stored in each EventNode. This calculation is performed when the EventNodeNetwork is created and when an update request is received due to a network topology change.

【0068】

First, we request the calculation of the propagation rate for all problems in the Problem list of EventNodeNetwork (190). In response to this request, each Problem recursively calculates the propagation rate. In this case, "recursive" means to calculate and use the propagation rate of its own adjacent Problem in the EventNodeNetwork in order to calculate its own propagation rate, and further to calculate the propagation rate of the adjacent Problem. Furthermore, the propagation rate of the Problem adjacent to the adjacent Problem is calculated and used, and the same calculation is performed for different Problems one after another. In particular, the present embodiment is characterized in that the propagation rate of each Problem is calculated from the side closer to the Symptom at the end of the EventNodeNetwork in order to improve the calculation efficiency at this time. The calculation method will be described later. Each Problem keeps its own calculated propagation rate. This value is this Problem in the EventNodeNetwork It is used to calculate the propagation rate of the Problem after the Problem (farther from the Symptom) adjacent to. Therefore, it can be said that the propagation rate of each Problem is an intermediate result for the subsequent calculation of the propagation rate of the Problem.

【0069】

After this, processing for event correlation table partitioning is performed (196).

[Calculation method of propagation rate] The calculation method of propagation rate will be described with reference to FIGS. 11 to 12. In the following explanation, two Problem Pr and Ps are assumed, and the propagation from Pr to Ps is considered. Figure 11 shows an example of an event node network focusing on Pr and Ps. In the following explanation, Problem is also considered to include Symptom. Actually, this event node network is stored in a memory in the computer or an external storage device as list format data as described later. In the present embodiment, the event node network refers to data in which the event nodes corresponding to the managed objects constituting the network and the propagation relationship between the event nodes are described in a predetermined data format. This format is not limited to the list format. The event node network can be represented by a network diagram as shown in FIG.

【0070】

In FIG. 11, fd (Pa, Pb) refers to the total propagation rate from Problem Pa to Problem Pb. If there is no relation between the two, fd (Pa, Pb) = 0. d (Pa, Pb) is a predefined value for the propagation rate from Problem Pa to Problem Pb. This value is uniquely set for each network and for each combination of two problems in order to deal with certain network-specific characteristics as described above. In FIG. 11, the arrow indicating the direct association indicates the value of d (Pa, Pb), and the arrow indicating the indirect association indicates the value of fd (Pa, Pb). Here, "indirect association" means that another Problem may be included between two Problems.

【0071】

In the present embodiment, the calculation of the propagation rate between the two Problem Prs and Ps is based on the following formula.

【0072】

[Number 1]

fd (Pr, Ps) = max (d (Pr, Pk) * fd (Pk, Ps)) ... (1) However, it is assumed that k = 1 to n, and P1 to Pn are problems that propagate directly from Pr. Here, fd (Pa, Pa) = 1 is set in order to correctly calculate the propagation rate when propagating directly from Pr to Ps. Also, max (fk) indicates the maximum value of fk, that is, f1 to fn when k = 1 is changed to n.

【0073】

Equation (1) uses the maximum propagation rate that indicates that when there are multiple propagation paths from one problem to another, the maximum propagation rate calculated for each route is the propagation rate between the problems. By doing so, even if there is a cycle (including a loop) in the EventNodeNetwork, the propagation rate can be calculated easily. The detection of the loop structure will be described later.

【0074】

To create the event correlation table, the above calculation will be performed for all problems. However, if the above recursive calculation is repeated for all problems, the same calculation will be repeated many times, which is useless. Therefore, in the present embodiment, the information on the propagation rate of the Problem once calculated is retained in each Problem as an intermediate result, and when it becomes necessary to perform the same calculation later, the amount of calculation is reduced by using this intermediate result. To do.

【0075】

Each Problem can have multiple destinations. Suppose there are m problems and symptoms propagating from Pr, including direct and indirect. Then, the propagation rate from Pr to each Problem or Symptom can be expressed by a list of Problem and propagation rate pairs. Assuming that P1 ~ Pm also includes Symptom, this list of P1 ~ Pm is as follows.

【0076】

[Number 2]

P1: fd (Pr, P1) P2: fd (Pr, P2) ... Pm: fd (Pr, Pm) This list of propagation rates from Pr to each Problem is expressed as ppl (Pr). ppl is an abbreviation for "Problem and Probability List". Using this list, let us express the propagation rate from Pr to Px as ppl (Pr) (Px). In other words, fd (Pr, Px) can be written as follows.

【0077】

[Number 3]

fd (Pr, Px) = ppl (Pr) (Px) ... (2) As already mentioned, for convenience of calculation, the following equation shall hold.

【0078】

[Number 4]

fd (Pr, Pr) = ppl (Pr) (Px) = 1 Substituting this equation (2) into equation (1) gives the following equation (3).

【0079】

[Number 5]

fd (Pr, Ps) = max (d (Pr, Pk) * ppl (Pk) (Ps)) ... (3) However, it is assumed that k = 1 ~ n, and P1 to Pn are problems that propagate directly from Pr.

【0080】

By keeping this ppl in each Problem as the intermediate calculation result of each Problem, it is possible to avoid performing the same calculation multiple times for the same Problem. The calculation procedure is shown for the event node network shown in Fig. 12. The general calculation procedure will also be clear from this example.

【0081】

In the example shown in FIG. 12, d (P0, P1) = a, d (P0, P2) = b, d (P1, P3) = c, d (P2, P3) = d, d (P3, S1) = Let e.

【0082】

(1) P0 gets ppl (P1) and ppl (P2) for P1 and P2, and gets the Problem and Symptom list. In the example shown in FIG. 12, three problems (P1, P2, P3) and one Symptom (S1) are acquired.

【0083】

(2) P0 calculates the propagation rate for each Problem (P1, P2, P3) and Symptom (S1) and registers it in ppl (P0). Equation (3) is used for the calculation at this time. It should be noted that in this equation, the propagation rates of P3 and S1 are used in the calculation of ppl (P1) and ppl (P2).

【0084】

(3) The Problem (P1, P2) propagating from P0 performs the above-mentioned processes (1) and (2) by replacing "P0" with "P1" or "P2", respectively. Since it is necessary to use the propagation rates of P3 and S1 for P1 and P2, the above calculation is recursively performed up to S1.

【0085】

(4) Finally, when the propagation rate for S1 is determined, the propagation rate from P3, P2, P1, P0 to S1 is determined using that value.

【0086】

The calculation results of the propagation rate in the example shown in FIG. 12 are as follows. About ppl (P0): S1: max (d (P0, P1) * ppl (P1) (S1), d (P0, P2) 7PP0 (P2) (S1)) = max (a * ppl (P1) (S1), c * ppl (P2) (S1)) = a * b * e P3: max (d (P0, P1) * ppl (P1) (P3), d (P0, P2) * ppl (P2) (P3)) = max (a * ppl (P1) (P3), c * ppl (P2) (P3)) = a * b P1: d (P0, P1) * ppl (P1) (P1) = a P2: d (P0, P2) * ppl (P2) (P2) = c P0: 1 About ppl (P1): S1: d (P1, P3) * ppl (P3) (S1) = b * ppl (P3) (S1) P3: d (P1, P3) * ppl (P3) (P3) = b P1: 1 About ppl (P2): s1: d (P2, P3) * ppl (P3) (S1) = d * ppl (P3) (S1) P3: d (P2, P3) * ppl (P3) (P3) = d P2: 1 About ppl (P3): s1: d (P3, S1) * ppl (S1) (S1) = e P3: 1 About ppl (S1): s1: 1 After all, the procedure for calculating the propagation rate can be summarized as shown in steps 190, 192, and 194 in Fig. 10.

[Detection of loop structure] When EventNodeNetwork contains a loop structure, the process does not end when EventNode is propagated by the normal propagation method. Therefore, the loop structure is detected by the following procedure, and the process is terminated even if there is a loop structure.

【0087】

(1) Set an identifier indicating the calculation state of the propagation rate in each EventNode. Three types of identifiers are set: "uncalculated", "calculating", and "calculated completed". The default value is "Uncalculated".

【0088】

(2) Change the identifier of EventNode, which is the start point of propagation, to "Calculating" and transfer the processing to the child (propagation destination) EventNode. Change the propagated child EventNode to "calculating".

【0089】

(3) If the child EventNode of the propagation destination does not have a propagation destination, or if the EventNode of the propagation destination has an identifier of "calculating", the identifier of the child EventNode of the propagation destination being processed is changed to "calculation completed". Change and transfer the processing from the child EventNode of the propagation destination being processed to the EventNode of the propagation source.

【0090】

(4) Repeat steps (2) and (3) until the identifier of EventNode, which is the start point of propagation, becomes "calculation completed".

【0091】

By performing this procedure, the propagation calculation is surely completed even if the EventNodeNetwork contains a loop structure.

[Splitting the event correlation table] The splitting process of the event correlation table shown in step 196 of Fig. 10 is performed when the EventNodeNetwork is created and when the EventNodeNetwork is reconfigured by changing the network topology. The process is performed as follows. As is clear from the following explanation, in this embodiment, the event correlation table can be divided by holding the event node network in a list format and holding the propagation relationship between the event node networks. Become. In addition, since the event node network is retained as an intermediate format for creating the correlation table, when there is a change in the network configuration, it is easy to reflect the difference in the change to this event node network. it can. As a result, changes in the network configuration can be easily reflected in the finally created correlation table.

【0092】

The outline of the procedure is as follows. (1) Create a CodebookGroup instance in EventNodeNetwork and add it to the CodebookGroup list. There are three types of division status identifiers for all EventNodes: "undivided", "divided", and "divided completed", but they should be initialized with "undivided". The CodebookGroup class is a class that represents the group name for partitioning the event correlation table, and manages all exported Problems and Symptoms managed by EventNodeNetwork. There is also a Codebook class that represents an event correlation table. The Codebook class represents a matrix that expresses the relationship between Problem and Symptom by propagation rate, that is, an event correlation table. When creating the event correlation table, multiple instances of the Codebook class are created.

【0093】

(2) Register the problems in the Problem list of EventNodeNetwork in the Problem list of the instance of CodebookGroup in order. Here, problems that have not been exported are excluded from registration.

【0094】

(3) Register the Problem / Symptom propagated from the source Problem in step (2) in the same CodebookGroup as the source. Problems that have not been exported are excluded from registration. If the propagation destination is Symptom, register it in the Symptom list of CodebookGroup. Set the "dividing" identifier to the Problem / Symptom registered in the CodebookGroup.

【0095】

(4) In step (3), if there is no propagation destination or there is a propagation destination and the EventNode is "dividing", the EventNode being processed is changed to "division completed" and the processing is propagated. Migrate to the original EventNode. If the Problem is not exported, change it to "Undivided". If the propagation destination EventNode is "division completed", perform step (5). In this way, step (3) is repeated until the problem of the registration source becomes "division completed".

【0096】

(5) If the propagation destination Problem / Symptom is "split completed", "merge" the event correlation table. The merge of the event correlation table will be described later.

【0097】

(6) After completing step (4), create a new CodebookGroup instance and repeat step (2) and below. Ignore if the propagation source Problem has a "split complete" identifier.

【0098】

FIG. 13 shows an example of a flowchart of software processing for realizing this procedure. With reference to Figure 13, we first initialize the variables i and j to 0 (110). It then determines if there is a Problem Pi, and if not, ends the process (112). If you have a Problem Pi, create CodebookGroup _j as an instance of the CodebookGroup class and add it to the CodebookGroup list (114).

【0099】

Then, it is determined whether the division state identifier of the Problem Pi is "division completed", and if it is "division completed", this Problem is ignored and i is incremented to return the process to step 112. After that, the process of step 112 and the following is repeated for the new Problem Pi. If the determination in step 116 shows that the split state identifier of the Problem Pi is not "split complete", control proceeds to step 118.

【0100】

In step 118, add the Problem Pi to the Problem list in CodebookGroup _j. That is, if the Problem Pi is the propagation destination Problem, the Pi is registered in the same CodebookGroup in which the propagation source Problem was registered. If the propagation destination is Symptom, it will be registered in the Symptom list. Problems that have not been exported are not subject to registration. Set the split state identifier of Problem / Symptom registered in Codebookgroup _j to "splitting" (120).

【0101】

Next, it is determined whether or not the propagation destination remains from the Problem / Symptom Pi (122). If there are no remaining, set Pi to "split complete" and increment j (126) and then increment i (128) to return control to step 112. If the propagation destination remains from the Problem / Symptom Pi, control proceeds to step 124. In step 124, the Problem / Symptom registration process is performed.

【0102】

With reference to FIG. 14, first, in step 140, it is determined whether or not the registration source is division completed. If "division completed" is displayed, this process is terminated, and the process returns to step 122 in FIG. If it is not "split complete", select the next propagation destination (142) and determine whether the propagation destination is "split complete" (144). If "split completed", merge processing is performed (154) and control proceeds to step 148. If step 144 determines that the destination is not "split complete," step 146 registers this destination EventNode in the Problem / Symptom list of CodebookGroup _j and advances control to step 148.

【0103】

In step 148, it is determined whether or not there is a further propagation destination, and if not, this EventNode is regarded as "division completed" (156) and the processing is returned to the propagation destination node (158) Step 140 and the following are executed. If it is determined in step 148 that there are more propagation destinations, it is determined whether the propagation destination is "splitting" (150). If it is "splitting", the node is set to "splitting completed" (156) and the control proceeds from step 158 to 140.

【0104】

If it is determined in step 150 that the propagation destination is not "splitting", the node is changed to "splitting" and control is returned to step 142.

【0105】

With reference to FIG. 15, the merge process is performed as follows. First, copy the Problem / Symptom list of the destination CodebookGroup instance to the Problem / Symptom list of the current CodebookGroup instance (170). Then delete the Problem / Symptom list of the destination CodebookGroup instance. At this time, the CodebookGroup instance will be deleted, so decrement the CodebookGroup instance number if necessary.

【0106】

The above calculation procedure will be specifically described with reference to FIG. 16 and below for the EventNodeNetwork shown in FIG. In FIGS. 16 to 23, the white circle is the "undivided" EventNode, the shaded circle is the "divided" EventNode, and the diagonally shaded circle is "thick line". EventNode of "split completion" is shown respectively. Further, in FIGS. 16 to 23, the CodebookGroup, the Problem list (upper row), and the Symptom list (lower row) of each CodebookGroup are shown on the right side of the event node network.

【0107】

(1) First, create CodebookGroup 0, which is a CodebookGroup instance, and register it in the CodebookGroup list of EventNodeNetwork.

【0108】

(2) Register Problem P0 in the Problem list of CodebookGroup 0, and change P0 to "Splitting" (Fig. 17).

【0109】

(3) Register all Problem / Symptom (EventNode) propagated from Problem P0 directly or indirectly in the Problem list / Symptom list of CodebookGroup 0, and change each to "Dividing" (Fig. 18). Change EventNodes that do not have a propagation destination and EventNodes that are "splitting" even if there is a propagation destination to "split complete".

【0110】

(4) After step (3) for EventNode propagating from P0 is completed, create a new CodebookGroup instance, CodebookGroup 1, and start the following process for Problem P1 (Fig. 19). However, in this case, P1 is "division completed", so ignore it.

【0111】

(5) Next, register Problem P2 in Codebook Group 1. Change P2 to "Splitting" (Figure 20).

【0112】

(6) Register all Problems / Symptoms propagated from Problem P2 in the Problem list of CodebookGroup 1. However, since "split completion" has already been set for Problem P0 here, the "merge" process is performed. Specifically, copy the entire Problem / Symptom list of CodebookGroup 0 to which P0 belongs to the Problem / Symptom list of CodebookGroup 1. After copying, remove CodebookGroup 0 from the CodebookGroup list. The state at this time is shown in FIG. After that, since CodebookGroup 0 was deleted, the index "1" of CodebookGroup 1 was decremented to "0" and changed to CodebookGroup 0 (upper part on the right side of Fig. 22).

【0113】

(7) Create a new instance of CodebookGroup, CodebookGroup 1, and register Problem P3 in CodebookGroup 1 (Fig. 22).

【0114】

(8) Register all Problem / Symptoms propagated from Problem P3 in the Problem list / Symptom list of CodebookGroup 1 (Fig. 23). In this case, it is the two Symptom S1 and S2 that propagate from P3, and there is no propagation destination before these. And all of these are "undivided". Therefore, as a result, S1 and S2 are registered in the Symptom list of Codebook group 1.

【0115】

Since "split completion" has been set for all EventNodes of the EventNodeNetwork by the above processing up to (8), the division processing of the Codebook is terminated. As shown in Figure 23, we got two CodebookGroup instances as CodebookGroup 0, 1 and a list of Problems / Symptoms that belong to each event correlation table. These lists are lists of Problems / Symptoms that belong to event node networks that are independent of each other. Therefore, it is possible to create separate event correlation tables from Codebook Groups 0 and 1.

【0116】

Subsequently, the correlation table creation process shown in FIG. 4 will be described with reference to FIGS. 24 to 26. The event correlation table is created each time the time window is closed. The event correlation table created in this way is used for Problem / Symptom correlation in the time window that was closed immediately before. It is assumed that the target of processing is the event node network shown in Fig. 25, and that the shaded EventNodes P1, P3, P4, and P5 are subscribed problems.

【0117】

Refer to Figure 24 to first determine if Codebook creation is required (210). For example, if the topology information update, subscribe / unsubscribe request, and Codebook split execution / split suppression request do not occur in the previous time window, there is no need to reconfigure the Codebook, and the event correlation table created in the previous time window can be used. You can reuse it. Therefore, if it is determined that the event correlation table creation is unnecessary, the process ends without doing anything.

【0118】

If you need to create an event correlation table, first create an item list for the event correlation table (212). This creation uses all subscribed Problems and all Symptoms propagating from that Problem. These Problems and Symptom determine the row and column items of the event correlation matrix that make up the event correlation table.

【0119】

Next, it is determined whether the split execution of the event correlation table is set or whether the split execution is suppressed (214). This setting shall be set in advance by the system operator. If it is determined that the change is necessary, the system operator will instruct the change.

【0120】

If the split is suppressed, control proceeds to step 216, and the propagation rate for all combinations of Problem and Symptom created in step 212 is the calculated value list of the propagation rate of EventNode (in step 72 of Figure 4). Obtained from (calculated) and arranged in a matrix to create an event correlation table. In this case, for example, for the event node network as shown in FIG. 25, the event correlation table 228 as shown in FIG. 29 is created.

【0121】

If split execution is set, control proceeds to step 218, and each instance of CodebookGroup created by the correlation table partitioning process described with reference to FIGS. 13 to 23 is registered in the Problem list of that CodebookGroup. Create an event correlation table by using the Problem and the Symptom registered in the Symptom list. The event correlation tables obtained in this case are the event correlation tables 230 and 232, which are separate for each Codebook Group, as shown in Fig. 26. In FIG. 26, the propagation rates between event nodes are all shown as "1" for convenience. In practice, these values are the propagation rates calculated for the combination of Problem and Symptom. By adopting the propagation coefficient in the event correlation table in this way, it is possible to infer the cause of the failure in consideration of the conditions peculiar to a certain network, which cannot be dealt with by modeling by the object model.

【0122】

The event correlation table created in this way is stored in the memory of the computer that constitutes the network management device, and is used to calculate the distance from the symptom event pattern, making it possible to infer the cause of the failure with high reliability. To.

【0123】

By holding the network configuration information in a machine-readable format in the form of EventNodeNetwork and maintaining the propagation source list and propagation destination list for each EventNode of EventNodeNetwork, it became possible to divide the event correlation table. .. Therefore, according to the present invention, the originally unrelated Problem and Symptom can be literally separated, and the Problem can be properly inferred from the Symptom. In addition, when calculating the propagation rate between EventNodes, the method shown in equations (1) to (3) is used for the calculation of the propagation rate at each EventNode, and the calculation result of the propagation rate at each EventNode is retained. They were used to calculate the propagation rate in other EventNodes. This made it possible to efficiently calculate the propagation rate, increase the size of the network, and flexibly correlate the Problem and Symptom even if the topology changes drastically.

[Simple explanation of drawings]

[Figure 1]

It is a block diagram of the network management system which concerns on one Embodiment of this invention.

[Figure 2]

It is external drawing of the computer for realizing the network management system which concerns on this invention.

[Fig. 3]

It is a block diagram of the computer shown in FIG.

[Fig. 4]

It is a flowchart of software processing for realizing the event correlation processing of one Embodiment of this invention.

[Fig. 5]

It is a flowchart of the event node network creation process.

[Fig. 6]

It is a figure which shows typically the method of adding a node to an event node network.

[Fig. 7]

It is a figure which shows typically the result of adding a node to an event node network.

[Fig. 8]

It is a figure which shows typically the method of removing the propagation relation between nodes from an event node network.

[Fig. 9]

It is a figure which shows typically the result of removal of the propagation relation between nodes from an event node network.

[Fig. 10]

It is a flowchart of the propagation rate calculation process.

[Fig. 11]

It is a schematic diagram of an event node network for showing an example of propagation rate calculation.

[Fig. 12]

It is a schematic diagram of an event node network for showing an example of propagation rate calculation.

[Fig. 13]

It is a flowchart of 1 realization example of the division processing of a correlation table.

[Fig. 14]

It is a flowchart of 1 implementation example of Problem / Symptom registration process.

[Fig. 15]

It is a flowchart of 1 implementation example of the merge process.

[Fig. 16]

It is a figure which shows typically the event node network and CodebookGroup instance for demonstrating the partitioning process of a correlation table.

[Fig. 17]

It is a figure which shows typically the event node network and CodebookGroup instance for demonstrating the partitioning process of a correlation table.

[Fig. 18]

It is a figure which shows typically the event node network and CodebookGroup instance for demonstrating the partitioning process of a correlation table.

[Fig. 19]

It is a figure which shows typically the event node network and CodebookGroup instance for demonstrating the partitioning process of a correlation table.

[Fig. 20]

It is a figure which shows typically the event node network and CodebookGroup instance for demonstrating the partitioning process of a correlation table.

[Fig. 21]

It is a figure which shows typically the event node network and CodebookGroup instance for demonstrating the partitioning process of a correlation table.

[Fig. 22]

It is a figure which shows typically the event node network and CodebookGroup instance for demonstrating the partitioning process of a correlation table.

[Fig. 23]

It is a figure which shows typically the event node network and CodebookGroup instance for demonstrating the partitioning process of a correlation table.

[Fig. 24]

It is a flowchart of the correlation table creation process.

[Fig. 25]

It is a schematic diagram of the event node network for explaining the correlation table creation process.

[Fig. 26]

It is a figure which shows typically the example of the correlation table group created when the division execution is set.

[Fig. 27]

It is a figure which shows typically the simple network.

[Fig. 28]

It is a class diagram of the managed object model of the network shown in FIG. 27.

[Fig. 29]

It is a figure which shows typically the example of the event correlation table created when the correlation table is not divided.

[Explanation of symbols]

20 Network management system 22 Managed network 24 Network interface section 26 Event database section 28 Event repository 30 Configuration Management Department 32 Managed Object Repository 34 Fault Management Department 36 User interface section 40 Computer body 42 display 44 printer 46 keyboard 48 mouse 50 CD-ROM drive 52 FD drive 54 hard disk 56 CPU 58 ROM 60 RAM 62 CD-ROM 64 Flexible disc Pi problem Si Symptom