WO2013103008A1 - 事象の原因を特定する情報システム、コンピュータ及び方法 - Google Patents

事象の原因を特定する情報システム、コンピュータ及び方法 Download PDF

Info

Publication number
WO2013103008A1
WO2013103008A1 PCT/JP2012/050114 JP2012050114W WO2013103008A1 WO 2013103008 A1 WO2013103008 A1 WO 2013103008A1 JP 2012050114 W JP2012050114 W JP 2012050114W WO 2013103008 A1 WO2013103008 A1 WO 2013103008A1
Authority
WO
WIPO (PCT)
Prior art keywords
condition
internal
rule
generated
memory data
Prior art date
Application number
PCT/JP2012/050114
Other languages
English (en)
French (fr)
Inventor
有作 中村
黒田　沢希
岩村　卓成
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to PCT/JP2012/050114 priority Critical patent/WO2013103008A1/ja
Priority to US13/580,753 priority patent/US20130179563A1/en
Publication of WO2013103008A1 publication Critical patent/WO2013103008A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3034—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system component is a storage system, e.g. DASD based or network based
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3065—Monitoring arrangements determined by the means or processing involved in reporting the monitored data
    • G06F11/3072—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting
    • G06F11/3082—Monitoring arrangements determined by the means or processing involved in reporting the monitored data where the reporting involves data filtering, e.g. pattern matching, time or event triggered, adaptive or policy-based reporting the data filtering being achieved by aggregating or compressing the monitored data

Definitions

  • the present invention relates to a technique for identifying the cause of an event that has occurred in a network to which a plurality of node devices belong.
  • event a technique for identifying the root cause of an event related to a failure (hereinafter referred to as “event”) is known.
  • Patent Document 1 discloses the following technique. That is, first, rule memory data used for root cause analysis is stored in the rule memory. Each time the root cause analysis engine receives a notification of an event, the root cause analysis engine adds data related to the event to the rule memory and calculates a matching rate of rules related to the received event among the rules included in the rule memory data. Matching rate is an indicator (probability or calculated ratio) that indicates which rule conclusion is likely to be the root cause, and the analysis engine should identify the root cause based on the calculated matching rate Can do. Each event has a valid period, and when the duration expires, the data related to the event is deleted from the rule memory. The analysis engine recalculates the matching rate only for rules that are affected in relation to the deleted event.
  • the rule memory data used for the root cause analysis is data including a plurality of rules, event occurrence information related to the rules, and information such as an event matching rate related to the rules.
  • the rule memory data is expressed by, for example, an object model structured by a plurality of objects and their association.
  • This object model includes, for example, a condition object corresponding to the rule condition, a conclusion object corresponding to the rule conclusion, a calculation object for performing input / output operations between the objects, and all these objects are stored as data.
  • the connection between objects is stored in the memory as pointer data of the connection destination object, for example.
  • Root root cause analysis technology is generally introduced in medium to large-scale information processing systems. This is because in a small-scale system, there are few devices to be monitored, and the cause can often be identified manually, and it is not necessary to introduce a root cause analysis technique. On the other hand, in a large-scale system with many devices to be monitored, it is difficult to manually identify the cause, and the introduction value of the root cause analysis technique is high.
  • the number of rules to be determined increases according to the number of devices to be monitored. If the number of rules to be determined increases, the number of objects in the object model and the number of connections increase, resulting in an increase in rule memory data.
  • the information system includes a plurality of network devices constituting a plurality of sub-networks, a plurality of node devices belonging to the plurality of sub-networks, and a computer that identifies the cause of the event that has occurred.
  • the computer has a storage resource and a control device connected to the storage resource.
  • the storage resource stores one or more rules and subnetwork information indicating to which subnetwork the network device and the node device belong.
  • Each rule indicates topology information about a topology including a node device at one end, a node device at the other end, and a network device that relays them, a condition indicating an event in the topology, and an event that causes the condition to be satisfied And conclusions.
  • the control device performs the following (a1) to (a13) in a predetermined order to generate rule memory data and store it in the storage resource.
  • the predetermined order may be an order according to the description order of (a1) to (a13), and the same rule memory as the rule memory data generated by executing according to the description order. Any other order may be used as long as data can be generated.
  • the control device identifies one or more network devices in a certain first sub-network based on the sub-network information, and manages one or more event occurrence information as a rule condition by the network device
  • the first condition object is generated when it does not exist in the rule memory data, and the generated one or more first condition objects are included in the rule memory data.
  • the control device generates a first internal condition object for aggregating occurrence information of all events of one or more first condition objects when the rule memory data does not exist, and generates the generated first Are included in the rule memory data.
  • the control device associates the first internal condition object with the first condition object.
  • the control device identifies one or more network devices in a certain second sub-network based on the sub-network information, and manages one or more event occurrence information that is a rule condition by the network device
  • the second condition object is generated when it does not exist in the rule memory data, and the generated one or more second condition objects are included in the rule memory data.
  • the control device generates a second internal condition object that aggregates event occurrence information from all of the one or more second condition objects when the rule memory data does not exist. Include condition objects in rule memory data.
  • the control device associates the second internal condition object with the second condition object.
  • the control device generates an aggregate internal condition object for managing aggregate information in which event occurrence information of the first internal condition object and the second internal condition object is aggregated when the rule memory data does not exist, The generated aggregate internal condition object is included in the rule memory data.
  • the control device associates the aggregate internal condition object with the first and second internal condition objects.
  • the control device identifies a plurality of node devices in the first sub-network based on the sub-network information, and manages a plurality of third conditions for managing event occurrence information that is a rule condition by the node device An object is generated when it does not exist in the rule memory data, and the plurality of generated third condition objects are included in the rule memory data.
  • the control device stores an aggregate internal conclusion object that manages determination information for determining a condition, based on the aggregate information of the aggregate internal condition object and the occurrence information of the event of the third condition object, in the rule memory Generated when the data does not exist, and includes the generated aggregate internal conclusion object in the rule memory data.
  • the control device associates the aggregate internal conclusion object with the aggregate internal condition object and the third condition object.
  • the control device has a plurality of conclusion objects for managing an index indicating a possibility that a conclusion indicating an event occurring in each of the network device in the first subnetwork and the network device in the second subnetwork may be caused Is generated when the rule memory data does not exist, and the generated plurality of conclusion objects are included in the rule memory data.
  • the control device associates a plurality of conclusion objects with the aggregate internal conclusion object.
  • the control device receives event occurrence information in a plurality of network devices or node devices, identifies a condition object that manages the received occurrence information based on the rule memory data, and manages an event managed by the identified condition object Update the occurrence object information, update the information managed by each object affected by the update of the occurrence information by following the association with the condition object, update the conclusion object index, and update the updated conclusion object The cause of the event is identified and output based on the indicators.
  • FIG. 1 is a configuration diagram of an information processing system according to the embodiment.
  • FIG. 2 is a diagram illustrating a network configuration example 1 of the information processing system.
  • FIG. 3 is a diagram illustrating an example of the subnet management table in the configuration example 1.
  • FIG. 4 is a diagram illustrating a configuration example 2 of the network of the information processing system.
  • FIG. 5 is a diagram illustrating an example of the subnet management table in the configuration example 2.
  • FIG. 6 is a diagram illustrating an example of the router management table.
  • FIG. 7 is a diagram illustrating an example of an iSCSI target management table.
  • FIG. 8 is a diagram illustrating an example of a general rule.
  • FIG. 9 is a diagram illustrating an example of an expansion rule.
  • FIG. 1 is a configuration diagram of an information processing system according to the embodiment.
  • FIG. 2 is a diagram illustrating a network configuration example 1 of the information processing system.
  • FIG. 3 is a diagram illustrating an example of the subnet management
  • FIG. 10 is a diagram illustrating an example of a disassembly rule when subnets are adjacent to each other.
  • FIG. 11 is a diagram illustrating an image of disassembly when subnets are adjacent to each other.
  • FIG. 12 is a diagram illustrating an example of a disassembly rule when straddling subnets.
  • FIG. 13 is a diagram illustrating an image of disassembly when straddling subnets.
  • FIG. 14 is a diagram illustrating an example of an event message.
  • FIG. 15 is a diagram illustrating an example of an event queue table.
  • FIG. 16 is a diagram illustrating an example of rule memory data in the configuration example 1.
  • FIG. 17 is a diagram illustrating an example of the rule memory data in the configuration example 2.
  • FIG. 16 is a diagram illustrating an example of rule memory data in the configuration example 1.
  • FIG. 18 is a flowchart of the rule process.
  • FIG. 19 is a flowchart of the disassembly rule generation process.
  • FIG. 20 is a flowchart of the same subnet rule memory data generation processing.
  • FIG. 21 is a flowchart of event reception processing.
  • FIG. 22 is a flowchart of the event writing process.
  • program and “object” may be used as the subject.
  • the program and object are subject to processing determined by being executed by the processor of the control device in the memory and communication port ( Since it is performed using the network I / F), the description may be made with the processor as the subject.
  • the processing disclosed with a program or object as the subject may be processing performed by a computer such as a monitoring computer or an information processing apparatus. Further, part or all of the program may be realized by dedicated hardware.
  • Various programs may be installed in each computer by a program distribution server or a computer-readable storage medium.
  • a CPU Central Processing Unit
  • the control device includes dedicated hardware that performs predetermined processing (for example, compression and decompression). May include.
  • the action of “displaying” by the CPU is performed by the CPU on the display device of the first computer having the CPU. And the like, and an act of transmitting display information such as an object displayed on the display device to a second computer having the display device.
  • the second computer receives the display information, the second computer can display the object or the like represented by the display information on the display device.
  • FIG. 1 is a configuration diagram of an information processing system according to an embodiment.
  • the information processing system 100 includes a monitoring computer 101 as an example of a cause analysis device, one or more servers 102, one or more network devices 103, and a communication network 105 (105a, 105b) such as a LAN (Local Area Network). Etc.) and one or more storages 104.
  • the network device 103 is an IP switch, a router, or the like.
  • the monitoring computer 101, the server 102, and the storage 104 are connected to each other via a communication network 105 and a network device 103.
  • the devices (the server 102, the storage device 104, the network device 103, etc.) constituting the information processing system 100 are referred to as “node devices”.
  • the information processing system 100 may include, for example, a host computer, NAS (Network Attached Storage), file server, printer, and the like as node devices. Since the node device is also a monitoring target of the monitoring computer 101, the node device may be referred to as a “monitoring target device”.
  • a logical or physical component such as a device included in the node apparatus is referred to as a “component”. Examples of components include a port, a processor, a storage resource, a storage device, a program, a virtual machine, a logical volume defined within the storage apparatus, and a RAID group. Note that when the monitoring target device and the component are handled without being distinguished, they are called “monitoring target”.
  • the server 102 is a computer that executes applications and the like.
  • the server 102 includes a CPU (Central Processing Unit) 146, a memory 147, a network interface (I / F) 142, and an iSCSI (Internet Small Computer System Interface) initiator 143.
  • the server 102 generates a monitoring agent 141 that is a logical component by executing a predetermined application by the CPU 146. When any event occurs in the monitoring target, the monitoring agent 141 transmits an event message indicating the occurrence of the event to the monitoring computer 101.
  • an iSCSI disk 151 that is a virtual volume to which the storage area of the storage 104 is allocated is formed in the server 102.
  • the server 102 can use the iSCSI disk 151 like a local hard disk through the iSCSI initiator 143.
  • the storage 104 is a device that provides a storage area to the server 102 or the like.
  • the storage 104 includes a storage controller 161, a network I / F 163, and a storage medium 162.
  • the storage medium 162 is a hard disk drive (HDD), but may be another type of storage medium such as a solid storage medium or an optical storage medium instead.
  • the storage 104 provides a storage area for forming the iSCSI disk 151 to the server 102, for example.
  • the storage 104 generates a monitoring agent 166 that is a logical component by executing a predetermined application by a CPU (not shown). When any event occurs in the storage 104, the monitoring agent 166 transmits an event message indicating the occurrence of the event to the monitoring computer 101.
  • the monitoring agent 141 of the server 102 may be configured to be able to monitor an event that has occurred in the storage 104, and an event message of the event that has occurred in the storage 104 may be transmitted to the monitoring computer 101.
  • the monitoring computer 101 is a computer that manages the monitoring target device.
  • the monitoring computer 101 is a general-purpose computer, for example, and includes a CPU 111, a storage resource 112, an input / output device 114, a system bus 116, and a network I / F 115.
  • the storage resource 112 may be a memory, a secondary storage device such as a hard disk drive (HDD), or a combination of a memory and a secondary storage device.
  • the CPU 111, the storage resource 112, the input / output device 114, and the network I / F 115 are connected to each other via the system bus 116.
  • the storage resource 112 includes, for example, a rule memory 121, a rule loader program 122, an event reception program 123, an event writing program 124, a matching rate evaluation program 125, a general rule repository 131, an expansion rule repository 132, A decomposition rule repository 133, an event queue table (TBL) 134, and configuration information 135 are stored.
  • the rule loader program 122, the event reception program 123, the event writing program 124, and the matching rate evaluation program 125 are executed by the CPU 111.
  • the rule memory 121 stores rule memory data used when analyzing the root cause.
  • the general rule repository 131 stores one or more general rules.
  • the expansion rule repository 132 stores one or more expansion rules.
  • the decomposition rule repository 133 stores one or more decomposition rules. General rules, expansion rules, and disassembly rules will be described later with reference to the drawings.
  • the network I / F 115 is an interface device for connecting to the communication network 105.
  • the input / output device 114 is an interface device for connecting to an input / output device.
  • the display 117 is connected to the input / output device 114.
  • the monitoring computer 101 can display the result of the root cause analysis and other information on the display 117, thereby presenting the result of the root cause analysis to the administrator. Note that the monitoring computer 101 may have a display 117 inside.
  • the monitoring computer 101 receives various information such as an event message indicating that an event has occurred in the monitoring target, configuration information of the monitoring target device or the information processing system 100 as a whole, from the monitoring target device.
  • the monitoring computer 101 performs various processes such as a process of analyzing the cause of an event based on various information received from the monitoring target apparatus, and outputs the processing result.
  • some of the monitoring target devices are devices that provide network services such as an iSCSI volume providing service, a file sharing service, and a Web service (hereinafter “service providing devices”).
  • Some monitored devices are devices that use network services provided by service providing devices (hereinafter referred to as “service using devices”).
  • service providing devices since the server 102 uses the iSCSI volume providing service provided by the storage 104, it corresponds to a service using device.
  • the storage 104 corresponds to a service providing apparatus in order to provide an iSCSI volume providing service to the server 102 or the like. Since the service providing apparatus and the service using apparatus have a relationship of providing and using a network service with each other, an event that occurs on the one hand can propagate to the other. For example, when a certain event occurs in the storage 104 corresponding to the service providing apparatus, a similar event may occur in the server 102 (that is, the service using apparatus) that uses the network service provided by the storage 104.
  • the configuration information 135 is information indicating the configuration of the information processing system 100.
  • the node information is configured by the node device, and the configuration of each node device (for example, And what kind of component the node device has), how the connection relationship between the node devices or between the components is, and what is the inclusion relationship between the node device and the component.
  • the configuration information 135 may include information related to the provision or use of the network service (for example, identification information of the service using device, information input to the service providing device when using the network service, etc.).
  • Information input to the service providing device includes, for example, an iSCSI target name and LUN (logical unit number) input when using the iSCSI volume providing service, and a Web server name input when using the Web service. URL etc.
  • FIG. 2 is a diagram illustrating a configuration example 1 of the network of the information processing system.
  • “sv”, “st”, “sw”, “rt”, and “Net” are server 102, storage 104, IP switch, router, and subnetwork (subnet), respectively. Means.
  • the servers (sv1, sv2) corresponding to the service using devices belong to the subnet 1
  • the storage (st1) corresponding to the service providing device is in the subnet 0 different from the subnet 1. belong to.
  • Subnet 1 and subnet 0 are connected to each other via a router (rt1) which is a network device.
  • the subnet to which the server belongs ie, subnet 1
  • the subnet to which the storage (st1) belongs ie, subnet 0
  • FIG. 3 is a diagram illustrating an example of the subnet management table in the configuration example 1.
  • the subnet management table 301 is a table for managing information indicating to which subnet the monitored device belongs.
  • the subnet management table 301 corresponds to a part of the configuration information 135.
  • the subnet management table 301 includes, for each node device, a node ID 311 of the node device, a node type 312 of the node device, a node name 313 of the node device, an IP address 314 assigned to the node device,
  • the subnet ID 315 to which the node device belongs is stored in association with each other.
  • the node ID 311 is an identifier for uniquely identifying the node device.
  • the node type 312 is information indicating the type of the node device. In this embodiment, the node type “SERVER” indicates the server 102, the node type “STORE” indicates the storage 104, the node type “IPSWITCH” indicates the IP switch, and the node type “ROUTER” indicates the router.
  • the subnet ID 315 is an identifier for uniquely specifying a subnet. In the present embodiment, the subnet ID “0” indicates the subnet 0, and the subnet ID “1” indicates the subnet 1.
  • the server 1 and the server 2 belong to the subnet 1 and the storage 1 belongs to the subnet 0.
  • FIG. 4 is a diagram showing a configuration example 2 of the information processing system network.
  • the servers (sv1, sv2) corresponding to the service using devices belong to the subnet 1
  • the storage (st1) corresponding to the service providing device belongs to the subnet 2 different from the subnet 1.
  • Subnet 1 and subnet 2 are connected via another subnet 0 (for example, a backbone LAN).
  • the subnet to which the server belongs ie, subnet 1
  • the subnet to which the storage (st1) belongs ie, subnet 2
  • FIG. 5 is a diagram illustrating an example of the subnet management table in the configuration example 2.
  • the subnet management table 301 has the same configuration as the subnet management table 301 shown in FIG.
  • the monitoring computer 101 can know that the server 1 and the server 2 belong to the subnet 1 and the storage 2 belongs to the subnet 2 by referring to the subnet management table 301 in FIG.
  • FIG. 6 shows an example of the router management table.
  • the router management table 601 is a table for managing information indicating which subnet is connected to which subnet by the router.
  • the router management table 601 corresponds to a part of the configuration information 135.
  • a node ID 611 of the router, a node type 612 of the router, and two subnet IDs 613 and 614 (subnet ID1, subnet ID2) to which the router is connected correspond.
  • the router management table 601 in the figure it can be known that the router 1 connects the subnet 0 and the subnet 1 and the router 2 connects the subnet 0 and the subnet 2.
  • FIG. 7 is a diagram showing an example of the iSCSI target management table.
  • the iSCSI target management table 701 is a table for managing information indicating to which iSCSI initiator the iSCSI target permits connection.
  • the iSCSI target management table 701 corresponds to a part of the configuration information 135.
  • a target ID 711, an iSCSI target name 712, and a connection permission iSCSI initiator name 713 are recorded in association with each other.
  • the target ID 711 is an identifier assigned to each combination of the iSCSI target and the connection permission iSCSI initiator (hereinafter referred to as “iSCSI connection permission set”).
  • the iSCSI target name 712 is the name of the iSCSI target.
  • the connection permitted iSCSI initiator name 713 is the name of the iSCSI initiator that is permitted to connect. For example, it can be seen from the information of the target ID “TG1” that the storage 1 that is the iSCSI target permits the connection to the server 1 that is the iSCSI initiator.
  • FIG. 8 is a diagram illustrating an example of a general rule.
  • the general rule is information describing a condition indicating an event and a conclusion indicating an event identified as a cause when the condition is satisfied in a format independent of the actual configuration of the information processing system 100.
  • a general rule may include multiple conditions or multiple conclusions.
  • the general rule when the general rule includes a condition indicating an event related to the network device 103 (hereinafter, “network event”), the general rule further includes the network device 103 related to the network event and the network device 103.
  • Topology information about service providing apparatuses and service using apparatuses connected to each other via the network is included.
  • a service providing apparatus and a service using apparatus connected to each other via the network apparatus 103 related to a network event are referred to as “service providing apparatus related to a network event” and “service use related to a network event”, respectively.
  • device Sometimes referred to as “device”.
  • the general rules 801 and 802 include IF sections 811, 813 and THEN sections 812, 814. Conditions are described in IF sections 811, 813, and conclusions are described in THEN sections 812, 814. The condition and the conclusion each include the node type of the node device that has generated the event and the event type of the event.
  • the IF section 811 describes two conditions 821 and 822.
  • the THEN section 812 describes one conclusion 823 (“IPSWITCH Port_LinkDown”). This general rule 801 represents that the event indicated by the conclusion 812 is identified as the cause when two conditions 821 and 822 are satisfied.
  • the condition 821 describes “SERVER DiskDrive_Err”, indicates that the node type is “SERVER”, and the event type is “DiskDrive_Err”.
  • a condition 821 indicates an event of a disk failure that occurs in the server 102.
  • the condition 822 describes “IPSWITCH Port_LinkDown”, indicating that the node type is “IPSWITCH” and the event type is “Port_LinkDown”.
  • a condition 822 indicates an event of a link failure of a port occurring in the IP switch. Note that the event indicated by the condition 822 corresponds to a “network event” because it is an event related to the network device 103 called the IP switch.
  • the general rule 801 since the general rule 801 includes a condition indicating a network event, the general rule 801 further includes topology information 831.
  • the topology information 831 includes a node type “IPSWITCH” indicating the network device 103, and “SERVER” and “STORAGE” indicating either the service providing device or the service using device. .
  • This topology information 831 indicates that the server 102 and the storage 104 are connected via an IP switch.
  • the general rule 802 (GenRule 2) includes two conditions 824 and 825 and one conclusion 826. None of the events indicated by the conditions 824 and 825 are network events. Therefore, the general rule 802 does not include topology information.
  • FIG. 9 is a diagram illustrating an example of an expansion rule.
  • the expansion rule is information obtained by expanding the general rule into a format that depends on the actual configuration of the information processing system 100.
  • the information processing system 100 includes one server 102 (server 1), one storage 104 (storage 1), and one IP switch (IP switch 1)
  • the rule 801 is expanded to an expansion rule 901 (ExpRule 1) shown in FIG.
  • the expansion rule 901 includes a condition and a conclusion indicating an event related to a monitoring target that is an actual configuration of the information processing system 100 such as the server 1, the storage 1, and the IP switch 1.
  • the expansion rule 901 includes a condition indicating an event of a disk failure occurring in the server 1 and a condition and a conclusion indicating an event of a port link failure occurring in the IP switch 1.
  • FIG. 10 is a diagram illustrating an example of a disassembly rule when subnets are adjacent to each other.
  • FIG. 11 is a diagram illustrating an image of disassembly when subnets are adjacent to each other.
  • Decomposition rules are information generated based on general rules including conditions indicating network events.
  • the decomposition rule is generated by decomposing a condition indicating a network event included in the general rule into a plurality of conditions for a plurality of groups (for example, subnets). Note that not only conditions indicating network events but also conclusions indicating network events may be decomposed into a plurality of conclusions for a plurality of groups (for example, subnets). In the present embodiment, both the condition and the conclusion indicating the network event are decomposed into a plurality of conditions and conclusions for a plurality of groups.
  • the subnet (hereinafter referred to as the “first subnet”) to which the service using device related to the network event (servers 1 and 2 in the configuration example 1) belongs and the network event
  • the subnet to which the service providing apparatus related to (storage 1 in the configuration example 1) belongs (hereinafter referred to as “second subnet”) is adjacent, the conditions and conclusions indicating the network event are respectively in the first subnet.
  • a network device 103 that connects the first subnet and the second subnet, the condition and the conclusion indicating the event in which the network events are aggregated, the condition and the conclusion in which the event is aggregated in the second subnet, and the first subnet and the second subnet.
  • the conditions and conclusions indicating the network event of the router 1) are divided. It is.
  • an event in which network events are aggregated is referred to as an “internal event”, and a condition and a conclusion indicating the internal event may be referred to as an “internal condition” and an “internal conclusion”, respectively.
  • An event in which a plurality of internal events are aggregated is referred to as an “aggregated internal event”, and a condition and a conclusion indicating the aggregated internal event may be referred to as an “aggregated internal condition” and an “aggregated internal conclusion”, respectively.
  • an event that aggregates network events in a certain subnet A is referred to as “internal event related to subnet A”, and a condition and a conclusion indicating an internal event related to a certain subnet A are referred to as “internal condition related to subnet A” and There may be a case of “internal conclusion relating to subnet A”.
  • the network event of the network device 103 that connects a certain subnet A and another subnet B is referred to as “internal event related to connection of subnet A-B” (or “internal event related to connection of subnet A-subnet B”).
  • the conditions and conclusion indicating the internal event related to the connection of the subnet AB are referred to as “internal condition related to the connection of the subnet AB” and “internal conclusion related to the connection of the subnet AB” (or “subnet A -Internal conditions relating to the connection of the subnet B "and” Internal conclusion relating to the connection of the subnet A-subnet B ").
  • a relationship 1111 indicates a relationship between events indicating conditions and conclusions regarding the general rule 801.
  • the relationship 1111 indicates that the event 1101 is identified as a conclusion, that is, a cause when the events 1102 and 1103 occur.
  • Relationship 1112 indicates a relationship between events indicating conditions and conclusions regarding the disassembly rule generated based on the general rule 801.
  • the event 1106 is an event corresponding to the network event 1103 of the general rule 801, and represents that the network event 1103 of the general rule 801 is decomposed into a plurality of events 1121, 1122, and 1123.
  • the network event 1103 includes an internal event 1121 related to the subnet X (corresponding to the first subnet in this example) and a subnet Y (corresponding to the second subnet in this example).
  • the condition indicating the network event 1103 includes the internal condition related to the subnet X, the internal condition related to the subnet Y, and the internal event 1123 related to the connection of the subnet XY). And the internal conditions related to the connection of the subnet XY).
  • the conclusion is also decomposed in the same manner as described above. Accordingly, the conclusion indicated by the network event 1101 is broken down into an internal conclusion relating to the subnet X, an internal conclusion relating to the subnet Y, and an internal conclusion relating to the connection of the subnet XY.
  • the condition indicating the network event 1103 includes the internal condition relating to the subnet X, the internal condition relating to the subnet Y, and the internal condition relating to the connection of the subnet XY, as shown in the network event 1106.
  • the general rule 801 includes a decomposition rule 1011 including the internal condition 1021 related to the subnet X, a decomposition rule 1012 including the internal condition 1022 related to the subnet Y, and a decomposition rule including the internal condition 1023 related to the connection of the subnet XY. 1013.
  • the condition 1031 indicates an aggregated internal condition in which the internal conditions 1021, 1022, and 1023 are aggregated.
  • a decomposition rule 1001 including the aggregate internal condition 1031 is also generated.
  • the disassembly rules 1011, 1022, and 1013 define the aggregate internal condition 1031 of the disassembly rule 1001 in their THEN part. This means that the event indicated by the conclusion of the decomposition rules 1011, 1022, and 1013 is the same as the event indicated by the aggregate internal condition 1031 (that is, the aggregate internal event).
  • FIG. 12 is a diagram showing an example of disassembly rules when straddling subnets.
  • FIG. 13 is a diagram illustrating an image of disassembly when straddling subnets.
  • the condition and the conclusion indicating the network event are the first and the second, respectively.
  • Internal conditions and conclusions related to the second subnet, internal conditions and conclusions related to the second subnet, and a subnet interposed between the first subnet and the second subnet (hereinafter referred to as “third subnet”) Is divided into the internal conditions and conclusions regarding the connection between the first subnet and the third subnet, and the internal conditions and conclusions regarding the connection between the second subnet and the third subnet.
  • the event relationship 1111 of the general rule 801 is the same as in FIG.
  • the event 1302 includes an internal event 1321 related to the subnet X (corresponding to the first subnet in this example) and an internal event related to the subnet Y (corresponding to the second subnet in this example). 1322, an internal event 1323 related to a subnet (not shown, but assumed to be subnet Z) between subnet X and subnet Y, an internal event 1324 related to connection of subnet XZ, and subnet YZ It shows that it is decomposed into an internal event 1325 related to connection.
  • condition indicating the network event 1103 of the general rule 801 includes an internal condition relating to the subnet X, an internal condition relating to the subnet Y, an internal condition relating to the subnet Z, and an internal condition relating to the connection of the subnet XZ, It is decomposed into internal conditions related to the connection of the subnet YZ. The conclusion is also decomposed in the same manner as the condition indicating the network event.
  • the condition indicating the network event 1103 includes the internal condition relating to the subnet X, the internal condition relating to the subnet Y, the internal condition relating to the subnet Z, and the subnet XZ as shown in the network event 1302.
  • the condition indicating the network event 1103 includes the internal condition relating to the subnet X, the internal condition relating to the subnet Y, the internal condition relating to the subnet Z, and the subnet XZ as shown in the network event 1302.
  • the general rule 801 includes a decomposition rule 1211 including the internal condition 1221 related to the subnet X, a decomposition rule 1212 including the internal condition 1222 related to the subnet Y, a decomposition rule 1213 including the internal condition 1223 related to the subnet Z,
  • the decomposition rule 1214 including the internal condition 1224 relating to the XZ connection and the decomposition rule 1215 including the internal condition 1225 relating to the connection of the subnet YX are decomposed.
  • a disassembly rule 1001 including an aggregate internal condition 1231 in which internal conditions 1221, 1222, 1223, 1224, and 1225 are aggregated is also generated.
  • the decomposition rules 1211, 1222, 1213, 1214, and 1215 describe the aggregate internal condition 1231 of the decomposition rule 1201 in their THEN part. Therefore, the event indicated by the conclusion of the decomposition rules 1211, 1222, 1213, 1214, and 1215 is the same as the event indicated by the aggregate internal condition 1231 (that is, the aggregate internal event).
  • FIG. 14 is a diagram illustrating an example of an event message.
  • the event message 1401 is a message for notifying the occurrence of an event in the monitoring target, and is transmitted to the monitoring computer 101 by the monitoring agents 141 and 166.
  • the event message 1401 includes, for example, a monitoring target name 1411 of a monitoring target that is an event generation source, and an event type 1412 of the event that has occurred.
  • the monitoring target name 1411 is the name of the monitoring target. When the monitoring target is a node device, the monitoring target name 1411 is a node name.
  • FIG. 15 is a diagram illustrating an example of the event queue table.
  • the event queue table 134 is a table for managing event information 1511 related to an event that has occurred.
  • the event reception program 123 receives the event message 1401
  • the event reception program 123 enters the event information 1511 of the event notified by the received event message 1401 in this table.
  • the event queue table 134 functions as a buffer for the event writing program 124.
  • the event writing program 124 acquires the event information 1511 from the event queue table 134 and updates the contents of the rule memory data based on the event information 1511.
  • the event queue table 134 may manage event information 1511 related to internal events and aggregated internal events, in addition to event information related to normal events that occur in the monitoring target.
  • Each event information 1511 includes, for example, a monitoring target monitoring target type 1501 that is a generation source of the generated event, a monitoring target monitoring target name 1502 that is a generation source of the generated event, and an event type 1503 of the generated event. And the reception date and time 1504 regarding the event that occurred.
  • the monitoring target type 1501 is information indicating the type of the monitoring target. When the monitoring target is a node device, the monitoring target type 1501 is a node type (“SERVER”, “STORAGE”, “IPSWITCH”, “ROUTER”, etc.).
  • the monitoring target name 1502 is the name of the monitoring target. When the monitoring target is a node device, the monitoring target name 1502 is a node name.
  • the reception date and time 1504 is the date and time when the event reception program 123 receives the event message 1401.
  • FIG. 16 is a diagram illustrating an example of rule memory data in the configuration example 1.
  • FIG. 17 is a diagram illustrating an example of the rule memory data in the configuration example 2.
  • the rule memory data includes at least a plurality of rules used for root cause analysis, occurrence information of events related to the rules, and information indicating a possibility that an event related to the rules may be a cause. It is data expressed by their association.
  • the rule memory data is generated based on, for example, a decomposition rule and used when analyzing the root cause.
  • the rule memory data includes, for example, a condition object 1611, internal condition objects 1622 (1622a, 1622b, etc.), 1722 (1722, a 1722b, 1722c, etc.), aggregated internal condition objects 1621, 1721, a conclusion object 1612, Conclusion objects 1642 and 1742, aggregated internal conclusion objects 1641 and 1741, an operator object 1631, and connection information thereof are included.
  • Each object is data (object data) that is implemented as a structure or a class in a computer language and is stored in the storage resource 112 during a program operation.
  • Connection information is, for example, information that holds identifiers of objects to be connected in pairs.
  • the connection information has direction information, and the direction information indicates a relationship in which an output of a certain object is an input of another object, in other words, an upstream / downstream relationship between the objects.
  • the connection information has thickness information.
  • the thickness information corresponds to the number of inputs to the operator object 1631 and is an important element in the BLEND operator object 1631c described later.
  • the thickness information may be a value indicating the thickness. In FIG. 16 and FIG. 17, the connection thickness value is indicated by “ ⁇ number”.
  • the connection from the condition object 1611 generally has a thickness of 1, but the thickness does not necessarily have to be 1.
  • condition object 1611 is output to the target object connected to the condition object 1611.
  • the conclusion object 1612 receives an output from the source object connected to the conclusion object 1612 as an input.
  • the operator object 1631 receives an output of one or more source objects connected to the operator object 1631 as an input, and outputs it to a target object connected to the operator object 1631.
  • Internal condition objects 1622, 1722, aggregated internal condition objects 1621, 1721, internal conclusion objects 1642, 1742, and aggregated internal conclusion objects 1641, 1741 receive as inputs the output of one or more source objects connected to these objects, Output to the target objects connected to these objects.
  • the condition object 1611 is an object that manages an event related to a specific monitoring target and occurrence information of the event.
  • the condition object 1611 corresponds to the conditions of the expansion rule and the decomposition rule.
  • the condition object 1611 manages an event of a disk failure of the server 1 and occurrence information of the event.
  • event information 1511 of the event that has occurred is added to the event queue table 134 by the event reception program 123.
  • the event writing program 124 acquires the event information 1511 added to the event queue table 134 and sets the output value of the condition object 1611 that manages the disk failure of the server 1 to true (that is, 1).
  • the condition object 1611 outputs the output value (true) to the target object connected thereto.
  • the operator object 1631 includes an OR operator object 1631b, an AND operator object 1631a, and a BLEND operator object 1631c.
  • the OR operator object 1631b is an object that outputs true (1) to the target object when any of the outputs of one or more source objects is true (1). In the matching rate calculation process described later, the OR operator object 1631b outputs the maximum output value of one or more source objects to the target object. In the case of the OR operator object 1631b, the connection thickness with the target object is the same as the connection thickness with the source object.
  • the AND operator object 1631a is an object that outputs true (1) to the target object when all the outputs of one or more source objects are true (1). In the matching rate calculation process described later, the AND operator object 1631a outputs an AND output value of Expression 2 below to the target object.
  • the connection thickness on the output side of the AND operator object 1631a is X calculated by the following equation (1).
  • X indicates the sum of the thicknesses of all inputs of the target object of the AND operator object 1631a. Other similar descriptions have the same meaning.
  • Inputs to the BLEND operator object 1631c are classified into two types: inputs that are basic inputs (in principle, one) and inputs that are delta inputs. 16 and 17, the delta input is represented by a connection via a circle. In the matching rate calculation process described later, the BLEND operator object 1631c outputs the BLEND output value of Expression 3 below to the target object (typically, the conclusion object 1612).
  • the internal condition objects 1622, 1722 are objects that aggregate all events managed by the condition object 1611 located on the upstream side.
  • the internal condition objects 1622 and 1722 manage aggregate information obtained by aggregating event occurrence information from all condition objects located on the upstream side.
  • the internal condition objects 1622, 1722 correspond to the internal conditions of the decomposition rules (internal conditions 1021 to 1023 in FIG. 10, internal conditions 1221 to 1225 in FIG. 12).
  • the internal condition object 1622a (EaDiv1-1 (Net1)) corresponds to the internal condition 1021 related to the subnet X of the decomposition rule 1011 (subnet X is specified as subnet 1), and subnet 1 Of network events (in this example, one network event of switch 1) is collected.
  • the internal condition object 1622b (EaDiv1-5 (Net0)) corresponds to the internal condition 1022 related to the subnet Y of the decomposition rule 1012 (subnet Y is specified as the subnet 0), and a network event in the subnet 0 (this example Then, the occurrence information of one network event of the switch 2 is collected.
  • the internal condition object 1722b (EaDiv1-3 (Net0)) corresponds to the internal condition 1223 related to the subnet Z of the decomposition rule 1213 (the subnet Z is between subnet 1 and subnet 2).
  • the occurrence information of network events in the subnet 0 (specified in the intervening subnet 0) (in this example, two network events of the switch 2 and the switch 3) are aggregated.
  • the connection thickness of the internal condition objects 1622, 1722 to the target object is the same as the connection thickness from the source object.
  • the aggregate internal condition objects 1621 and 1721 are objects that aggregate all the events managed by the internal condition objects 1622 and 1722 located on the upstream side.
  • the aggregated internal condition objects 1621 and 1721 manage aggregated information obtained by aggregating event occurrence information from all of the internal condition objects 1622 and 1722 located on the upstream side.
  • the aggregate internal condition objects 1621 and 1721 correspond to the aggregate internal conditions (aggregate internal condition 1031 in FIG. 10 and aggregate internal condition 1231 in FIG. 12) of the decomposition rule.
  • the aggregated internal condition object 1621 (Ea (Net1-Net0)) corresponds to the aggregated internal condition 1031 of the disassembly rule 1001, and the internal condition objects 1622a and 1622b and the occurrence information of the network event of the router 1
  • the event occurrence information from all of the condition objects 1611 managing the event information is aggregated. That is, the aggregate internal condition object 1621 (Ea (Net1-Net0)) aggregates the occurrence information of the network events of all the network devices 103 (switch 1, switch 2, and router 1) in the subnet 1 and subnet 0.
  • the aggregated internal condition object 1721 (Ea (Net1-Net2)) corresponds to the aggregated internal condition 1231 of the disassembly rule 1201, and the occurrence of network events of the internal condition objects 1722a, 1722b, 1722c, and router 1
  • the event occurrence information from all of the condition object 1611 for managing information and the condition object 1611 for managing the occurrence information of the network event of the router 2 are collected. That is, the aggregated internal condition object 1721 (Ea (Net1-Net2)) is the network of the subnet 1, subnet 2, and all the network devices 103 (switches 1 to 4 and routers 1 and 2) between the subnet 1 and subnet 2. Collect event occurrence information.
  • the conclusion object 1612 manages an event related to a specific monitoring target (in the example shown in FIGS. 16 and 17, a network event) and an index (for example, a matching rate) indicating a possibility that a conclusion indicating the event is a cause.
  • the conclusion object 1612 corresponds to a conclusion such as an expansion rule.
  • the conclusion object 1612 manages an event of a network failure of the switch 1 and an index indicating a possibility that the event is a cause.
  • the internal conclusion objects 1642 (1642a, 1642b, etc.) and 1742 (1742a, 1742b, 1742c, etc.) are objects that aggregate all the events managed by the conclusion object 1612 located downstream thereof.
  • the internal conclusion objects 1642 and 1742 correspond to the internal conclusion of the decomposition rule.
  • the internal conclusion object 1642a (EaDiv1-1 (Net1)) corresponds to the internal conclusion of the decomposition rule 1011 and is a network event in the subnet 1 (in this example, one network event of the switch 1). Aggregate.
  • the internal conclusion object 1642b (EaDiv1-5 (Net0)) corresponds to the internal conclusion of the decomposition rule 1012 and aggregates network events in the subnet 0 (in this example, one network event of the switch 2).
  • the internal conclusion object 1742b (EaDiv1-3 (Net0)) corresponds to the internal conclusion of the decomposition rule 1213, and the network event in the subnet 0 (in this example, 2 of the switch 2 and the switch 3). Network events).
  • the aggregated internal conclusion objects 1641 and 1741 are objects that aggregate all the events that are aggregated in each of the internal conclusion objects 1622 and 1742 located on the downstream side thereof.
  • the aggregate internal conclusion objects 1641 and 1741 correspond to the aggregate internal conclusion of the decomposition rule.
  • the aggregated internal conclusion object 1641 (Ea (Net1-Net0)) corresponds to the aggregated internal conclusion of the decomposition rule 1001
  • the aggregate internal conclusion object 1641 (Ea (Net 1 -Net 0)) aggregates network events of all the network devices 103 (switch 1, switch 2, and router 1) in the subnet 1 and subnet 0.
  • the aggregated internal conclusion object 1741 (Ea (Net1-Net2)) corresponds to the aggregated internal conclusion of the disassembly rule 1201, and the internal conclusion objects 1742a, 1742b, 1742c, and the network events of the router 1 All of the events aggregated by the condition object 1611 for managing the occurrence information and the condition object 1611 for managing the occurrence information of the network event of the router 2 are aggregated.
  • the aggregated internal conclusion object 1741 (Ea (Net1-Net2)) is the network of the subnet 1, subnet 2, and all the network devices 103 (switches 1 to 4 and routers 1 and 2) between the subnet 1 and subnet 2. Collect event occurrence information.
  • the object is an internal condition object 1622, 1722, an aggregated internal condition object 1621, 1721, an internal conclusion object 1642, 1742, or an aggregated internal conclusion object 1641, 1741
  • at least a corresponding event is detected as a data structure (that is, The event writing program 124 may have a flag indicating whether the event information 1511 has been acquired).
  • FIG. 18 is a flowchart of rule processing.
  • the rule processing (steps 1801 to 1808) is repeated for the number of general rules existing in the general rule repository 131.
  • Step 1801 The rule loader program 122 selects one general rule i, and determines whether or not two or more node types are included in the IF part of the selected general rule i.
  • Step 1802 When the IF part of the general rule i includes two or more node types (step 1801: YES), the rule loader program 122 determines that the condition indicating the network event is in the IF part of the general rule i. It is determined whether or not it is included.
  • Step 1803 When a condition indicating a network event is included in the IF part of the general rule i (Step 1802: YES), the rule loader program 122 uses the service providing apparatus related to the network event and the service usage related to the network event. It is determined whether or not the connection with the device is an iSCSI connection.
  • the rule loader program 122 is equal to the number of iSCSI connection permission sets existing in the iSCSI target management table 701. Steps 1804 to 1807 are repeated.
  • Step 1804 The rule loader program 122 selects one iSCSI connection permission set j from the subnet management table 301, and the subnet to which the iSCSI target included in the iSCSI connection permission set j belongs (in FIGS. 18 and 19). Subnet X) and the subnet to which the iSCSI initiator included in the iSCSI connection permission set j belongs (subnet Y in FIGS. 18 and 19) is acquired.
  • Step 1805 the rule loader program 122 determines whether the subnet X and the subnet Y are different.
  • Step 1806 When the subnet X and the subnet Y are different (step 1805: YES), the rule loader program 122 performs a decomposition rule generation process (see FIG. 19). After the disassembly rule generation processing is completed, the rule loader program 122 newly selects one iSCSI connection permission set, and performs the processing from step 1804 to step 1807 again on the selected iSCSI connection permission set.
  • Step 1807 If the subnet X and the subnet Y are the same (step 1805: NO), the rule loader program 122 performs rule memory data generation processing for the same subnet (see FIG. 20). After the rule memory data generation process for the same subnet is completed, the rule loader program 122 newly selects one iSCSI connection permission set, and performs the processing of Steps 1804 to 1807 again for the selected iSCSI connection permission set. I do.
  • Step 1808 When two or more node types are not included in the IF part of the general rule i in Step 1801 (Step 1801: NO), a condition indicating a network event in the IF part of the general rule i in Step 1802 Is not included (step 1802: NO), or when the connection between the service providing apparatus and the service using apparatus related to the network event is not an iSCSI connection in step 1803 (step 1803: NO), the rule loader The program 122 performs rule memory data generation processing for the same subnet. After the same subnet rule memory data generation processing is completed, the rule loader program 122 newly selects one general rule, and performs the processing of steps 1801 to 1808 again for the selected general rule.
  • the rule loader program 122 ends the rule processing.
  • the decomposition rule is generated based on the general rule.
  • the rule memory data is generated based on the general rule or the expanded rule obtained by expanding the general rule without generating the decomposition rule. That is, since the decomposition rule can be generated based on the common general rule, or the rule memory data can be generated directly, the labor of the rule creator does not increase.
  • FIG. 19 is a flowchart of the disassembly rule generation process.
  • FIG. 19 shows processing when subnet X and subnet Y straddle other subnets (subnet Z in accordance with the examples shown in FIGS. 12 and 13). If subnet X and subnet Y are adjacent, step 1903 and any one of steps 1904 or 1905 can be omitted.
  • the condition and the conclusion indicating the network event 1103 of the general rule 801 are the internal condition 1221 and the internal conclusion for the subnet X, the internal condition 1222 and the internal conclusion for the subnet Y, and the internal condition 1223 and the subnet Z, respectively.
  • a decomposition rule 1001 including an aggregate internal condition 1231 that aggregates all of the above is generated.
  • the rule loader program 122 generates a decomposition rule 1211 including an internal condition 1221 related to the subnet X.
  • Step 1902 The rule loader program 122 generates a decomposition rule 1212 including the internal condition 1222 relating to the subnet Y.
  • Step 1903 The rule loader program 122 generates a decomposition rule 1213 including an internal condition 1223 related to the subnet Z.
  • Step 1904 The rule loader program 122 generates a decomposition rule 1214 including an internal condition 1224 related to the connection of the subnet XZ.
  • Step 1905 The rule loader program 122 generates a decomposition rule 1215 including an internal condition 1225 related to the connection of the subnet YZ.
  • Step 1906 The rule loader program 122 generates a decomposition rule 1001 including an aggregated internal condition 1231 (that is, AggregateEvent) in which all of the internal conditions 1221 to 1225 are aggregated, and ends the process.
  • an aggregated internal condition 1231 that is, AggregateEvent
  • the disassembly rules 1211 to 1215 including the internal conditions 1221 to 1225 include, for example, a condition indicating a network event, topology information about the network device and a node device connected via the network device, and a network It is generated to include information indicating to which subnet a device and a node device connected via the network device belong.
  • the THEN part includes an aggregate internal conclusion called AggregateEvent.
  • the AggregateEvent is generated for each event of the subnet X, the subnet Y, and the network device 103 (the event type described in the original general rule). For example, a disassembly rule for a general rule that includes link down as a condition is different from a disassembly rule for a general rule that includes a processor failure of the switch itself as a condition section.
  • AggregateEvent has a condition or conclusion that an event included in the general rule condition has occurred in any of the network devices 103 on the communication path from the node device in the subnet X to the node device in the subnet Y. means.
  • the decomposition into the decomposition rules 1211 to 1215 has a form that does not depend on the event type of the server 102 or the storage 104 of the general rule that is the source of the decomposition. Therefore, the same disassembly rule can be shared between an iSCSI error of the server 102 and a DNS error (assuming that the DNS server is in the subnet Y).
  • the IP switch indicated by the disassembly rules 1211 and 1212 may be a switch that is shared by any device for communication to the subnet Y (or subnet X) in the subnet X (or subnet Y). Is not limited. For example, if all tablet computers in the subnet X pass through the switch A (wireless LAN access point) and the server computer does not pass through the switch A, if the general rule that applies only to the tablet computer is an object, the switch A It becomes a target of the decomposition rule 1211.
  • FIG. 20 is a flowchart of rule memory data generation processing for the same subnet.
  • the rule loader program 122 generates an expansion rule from the general rule based on the system topology of the information processing system 100, and stores the generated expansion rule in the expansion rule repository 132.
  • Step 2002 The rule loader program 122 acquires the expansion rule from the expansion rule repository 132, and parses the acquired expansion rule.
  • Step 2003 The rule loader program 122 acquires a condition from the IF part of the expansion rule acquired in Step 2002.
  • Step 2004 The rule loader program 122 checks whether or not a condition object corresponding to the condition acquired in Step 2003 exists in the rule memory data.
  • Step 2005 When the corresponding condition object is not found (Step 2005: NO), the rule loader program 122 advances the process to Step 2006. On the other hand, when the condition object is found (step 2005: YES), the rule loader program 122 advances the process to step 2007.
  • Step 2006 The rule loader program 122 generates a condition object and an operator object for the condition acquired in Step 2003 in the rule memory data.
  • the rule loader program 122 connects the newly generated condition object and operator object to each other.
  • Step 2007 The rule loader program 122 checks whether or not processing has been completed for all conditions in the IF section. If all processing has been completed (step 2007: YES), the rule loader program 122 advances the processing to step 2008. On the other hand, if there are still unprocessed conditions (step 2007: NO), the rule loader program 122 advances the process to step 2003.
  • Step 2008 The rule loader program 122 acquires a conclusion from the THEN part of the expansion rule acquired in Step 2002.
  • Step 2009 The rule loader program 122 generates a conclusion object corresponding to the conclusion obtained in Step 2008 in the rule memory data. Further, the rule loader program 122 connects all the operator objects related to the generated conclusion object. Further, when two or more conclusions are acquired in step 2008, the rule loader program 122 generates a corresponding conclusion object in the rule memory data for each of the acquired conclusions, and generates the generated conclusion object. Connects all operator objects associated with.
  • Step 2010 The rule loader program 122 checks whether or not the processing has been completed for all the expansion rules in the expansion rule repository 132. If all processing has been completed (step 2010: YES), the same subnet rule memory data generation processing is terminated. On the other hand, if there are unexpanded unrolled rules (step 2010: NO), the rule loader program 122 advances the process to step 2002.
  • rule memory data generation processing when a plurality of subnets according to the present embodiment are included will be described.
  • This rule memory generation process is executed after the decomposition rule generation process is executed.
  • Step 3001 The rule loader program 122 examines the contents of all decomposition rules, and extracts all of the aggregate internal conditions, internal conditions, aggregate internal conclusions and internal conclusions included in the decomposition rules. The rule loader program 122 advances the process to step 3002.
  • Step 3002 The rule loader program 122 starts a loop (loop 1) that repeats the processing from Step 3003 below for each of the aggregate internal condition, internal condition, aggregate internal conclusion, and internal conclusion extracted in Step 3001.
  • loop 1 a loop that repeats the processing from Step 3003 below for each of the aggregate internal condition, internal condition, aggregate internal conclusion, and internal conclusion extracted in Step 3001.
  • Step 3003 The rule loader program 122 sends an aggregate internal condition object (Ea (NetX ⁇ ) corresponding to the aggregate internal condition 1231 (Ea (NetX ⁇ NetY)) extracted from the decomposition rule 1201 to the IF part 1601 of the rule memory data. NetY)) is generated, and the process proceeds to step 3004. If an aggregate internal condition object (Ea (NetX-NetY)) corresponding to the aggregate internal condition 1231 (Ea (NetX-NetY)) exists in the rule memory data, the aggregate internal condition object should be used. Does not create a corresponding object. In this way, since the existing aggregate internal condition object can be used, the data amount of the rule memory data can be reduced.
  • this aggregated internal condition object uses a service providing device (for example, storage) belonging to subnet Y and a plurality of service using devices (for example, servers) belonging to subnet X. Can be shared in cause analysis for each.
  • a service providing device for example, storage
  • devices for example, servers
  • subnets X and Y mean subnets to which node devices (that is, a service providing device and a service using device) that provide and use network services with each other belong.
  • the subnet X is the subnet to which the server 102 that is the service using device belongs
  • the subnet Y is the subnet to which the storage 104 that is the service providing device belongs (see the disassembly rule 1201).
  • Ea Net1-Net2
  • the rule loader program 122 generates an OR operator object 1631b on the upstream side of the generated aggregate internal condition object in the IF section. Then, the rule loader program 122 generates a connection for the aggregate internal condition object generated from the generated OR operator object 1631b. That is, the rule loader program 122 generates a connection so that the output value of the OR operator object 1631b becomes the input value of the aggregate internal condition object 1721.
  • Step 3004 The rule loader program 122 belongs to the subnet X based on the contents of the internal condition 1221 extracted from the disassembly rule 1211, and is used for communication between the subnet X and the subnet Y ( In the disassembly rule of FIG. 12, the IP switch) is searched.
  • the rule loader program 122 advances the process to step 3005.
  • the rule loader program 122 generates an internal condition object (EaDiv1-1 (NetX)) corresponding to the internal condition 1221 extracted from the decomposition rule 1211 in the IF section. If the internal condition object (EaDiv1-1 (NetX)) corresponding to the internal condition 1221 exists in the rule memory data, the corresponding object is not generated. As described above, since the existing internal condition object can be used, the data amount of the rule memory data can be reduced.
  • the subnet X is a subnet to which the server 102 that is a service using apparatus belongs. When the information processing system 100 is the configuration example 2, the server 1 belongs to the subnet 1. Therefore, an internal condition object (EaDiv1-1 (Net1)) is generated (internal condition object 1722a in FIG.
  • the rule loader program 122 generates an OR operator object 1631b on the upstream side of the internal condition object generated by the IF unit (not shown in FIG. 17). Then, the rule loader program 122 generates a connection for the internal condition object generated from the generated OR operator object 1631b. Thereafter, the rule loader program 122 proceeds with the process to step 3006.
  • Step 3006 The rule loader program 122 generates a condition object corresponding to a condition related to each of the network devices 103 in the subnet X (IP switch in the disassembly rule of FIG. 12). If a condition object corresponding to the condition exists in the rule memory data, the corresponding object is not generated. In this way, since the existing condition object can be used, the data amount of the rule memory data can be reduced.
  • the subnet X is the subnet 1
  • the switch 1 belongs to the subnet 1. Accordingly, a condition object corresponding to the condition related to the switch 1 is generated.
  • the rule loader program 122 generates a connection from each of the generated condition objects to the OR operator object 1631b generated in step 3005. Thereafter, the rule loader program 122 proceeds with the process to step 3007.
  • Step 3007 The rule loader program 122 belongs to the subnet Y based on the contents of the internal condition 1222 extracted from the disassembly rule 1212, and is used for communication between the subnet X and the subnet Y ( In the disassembly rule of FIG. 12, the IP switch) is searched. Thereafter, the rule loader program 122 advances the process to step 3008.
  • the rule loader program 122 generates an internal condition object (EaDiv1-5 (NetY)) corresponding to the internal condition 1222 extracted from the decomposition rule 1212 in the IF section.
  • an internal condition object (EaDiv1-5 (NetY)) corresponding to the internal condition 1222 exists in the rule memory data, the corresponding object is not generated.
  • the subnet Y is a subnet to which the storage 104 that is a service providing apparatus belongs. When the information processing system 100 is the configuration example 2, the storage 2 belongs to the subnet 2. Therefore, an internal condition object (EaDiv1-5 (Net2)) is generated (internal condition object 1722c in FIG.
  • the rule loader program 122 generates an OR operator object 1631b on the upstream side of the internal condition object generated by the IF unit (not shown in FIG. 17). Then, the rule loader program 122 generates a connection for the internal condition object generated from the generated OR operator object 1631b. Thereafter, the rule loader program 122 advances the process to step 3009.
  • Step 3009 The rule loader program 122 generates a condition object corresponding to a condition related to each of the network devices 103 in the subnet Y (IP switch in the disassembly rule of FIG. 12). If a condition object corresponding to the condition exists in the rule memory data, the corresponding object is not generated. In this way, since the existing condition object can be used, the data amount of the rule memory data can be reduced.
  • the subnet Y is the subnet 2
  • the switch 4 belongs to the subnet 2. Accordingly, a condition object corresponding to the condition related to the switch 4 is generated.
  • the rule loader program 122 generates a connection from each of the generated condition objects to the OR operator object 1631b generated in step 3008. Thereafter, the rule loader program 122 proceeds with the process to step 3010.
  • Step 3010 The rule loader program 122 searches for a router used for communication between the subnet X and the subnet Y, which is a boundary router of the subnet X (router connecting subnets). Then, the rule loader program 122 generates a condition object corresponding to the condition related to the searched router. If a condition object corresponding to a condition related to the corresponding router exists in the rule memory data, the corresponding object is not generated. In this way, since the existing condition object can be used, the data amount of the rule memory data can be reduced. Furthermore, the rule loader program 122 creates a connection from the generated condition object to the OR operator object 1631b generated in step 3003. Thereafter, the rule loader program 122 proceeds with the process to step 3011.
  • Step 3011 The rule loader program 122 searches for a router that is a boundary router of the subnet Y and is used for communication between the subnet X and the subnet Y. Then, the rule loader program 122 generates a condition object corresponding to the condition related to the searched router. If a condition object corresponding to a condition related to the corresponding router exists in the rule memory data, the corresponding object is not generated. In this way, since the existing condition object can be used, the data amount of the rule memory data can be reduced. Furthermore, the rule loader program 122 creates a connection from the generated condition object to the OR operator object 1631b generated in step 3003. Thereafter, the rule loader program 122 advances the process to step 3012.
  • Step 3012 The rule loader program 122 is located between the subnet X and the subnet Y based on the contents of the internal condition 1223 extracted from the decomposition rule 1213, and is used for communication between the subnet X and the subnet Y.
  • Network device 103 IP switch in the disassembly rule of FIG. 12
  • the routers boundary routers
  • these border routers may not be searched in steps 3010 and 3011, but may be searched in step 3012 instead.
  • the rule loader program 122 proceeds with the process to step 3013.
  • the rule loader program 122 generates an internal condition object (EaDiv1-3 (NetZ)) corresponding to the internal condition 1223 extracted from the decomposition rule 1213 in the IF section. Note that if the internal condition object (EaDiv1-3 (NetZ)) corresponding to the internal condition 1223 exists in the rule memory data, the corresponding object is not generated. As described above, since the existing internal condition object can be used, the data amount of the rule memory data can be reduced. For example, the internal condition object (EaDiv1-3 (NetZ)) can be shared in cause analysis regarding the service providing apparatus and the service using apparatus between two subnets connected across the subnet Z.
  • the subnet 0 is interposed between the subnet 1 and the subnet 2. Therefore, an internal condition object (EaDiv1-3 (Net0)) is generated (internal condition object 1722b in FIG. 17). Further, the rule loader program 122 generates an OR operator object 1631b on the upstream side of the internal condition object generated by the IF unit. Then, the rule loader program 122 generates a connection for the internal condition object generated from the generated OR operator object 1631b. Thereafter, the rule loader program 122 advances the process to step 3014.
  • an internal condition object EaDiv1-3 (Net0)
  • the rule loader program 122 generates an OR operator object 1631b on the upstream side of the internal condition object generated by the IF unit. Then, the rule loader program 122 generates a connection for the internal condition object generated from the generated OR operator object 1631b. Thereafter, the rule loader program 122 advances the process to step 3014.
  • Step 3014 The rule loader program 122 generates a condition object corresponding to a condition related to each of the network devices 103 (IP switches in the disassembly rule of FIG. 12) between the subnet X and the subnet Y. If a condition object corresponding to the condition exists in the rule memory data, the corresponding object is not generated. In this way, since the existing condition object can be used, the data amount of the rule memory data can be reduced.
  • the subnet 0 is interposed between the subnet 1 and the subnet 2, and the switch 2 and the switch 3 belong to the subnet 0. Therefore, a condition object corresponding to the condition related to each of the switch 2 and the switch 3 is generated.
  • the rule loader program 122 generates a connection from each of the generated condition objects to the OR operator object 1631b generated in step 3008. Thereafter, the rule loader program 122 proceeds with the process to step 3015.
  • the rule loader program 122 refers to the disassembly rule 1201, and identifies a service providing device or service using device related to the disassembly rule 1201 for which an event is specified in the disassembly rule 1201.
  • the service providing apparatus or the service using apparatus related to the disassembly rule 1201 corresponds to the server 1, the server 2, and the storage 2. It has not been. Therefore, when the information processing system 100 is the configuration example 2, the server 1 and the server 2 are specified.
  • Step 3016 The rule loader program 122 generates a condition object corresponding to a condition related to each of the service providing device and the service using device specified in Step 3015. If a condition object corresponding to the condition exists in the rule memory data, the corresponding object is not generated. In this way, since the existing condition object can be used, the data amount of the rule memory data can be reduced.
  • the information processing system 100 is the configuration example 2
  • a condition object corresponding to a condition related to each of the server 1 and the server 2 is generated.
  • the rule loader program 122 generates an AND operator object 1631a on the downstream side of the condition object generated by the IF unit. Then, the rule loader program 122 generates a connection from the generated AND operator object 1631a to the generated condition object. Thereafter, the rule loader program 122 proceeds with the process to step 3015.
  • Step 3017 The rule loader program 122 generates a connection from the aggregate internal condition object (Ea (NetX-NetY)) generated in Step 3003 to the AND operator object 1631b generated in Step 3016. Thereafter, the rule loader program 122 proceeds with the process to step 3015.
  • Ea NetX-NetY
  • Step 3018 The rule loader program 122 generates an OR operator object in the THEN part, and generates a connection for each OR operator generated from each of the AND operator objects 1631b generated in Step 3016. Note that the thickness of this connection is the number of inputs of the connected AND operator object 1631b. Thereafter, the rule loader program 122 proceeds with the process to step 3019.
  • Step 3019 The rule loader program 122 generates an aggregated internal conclusion object (Ea (NetX-NetY)) in the THEN part.
  • Ea NetX-NetY
  • the aggregate internal conclusion object (Ea (NetX-NetY)) exists in the rule memory data
  • the corresponding aggregate internal conclusion object is not generated. In this way, since the existing aggregate internal conclusion object can be used, the data amount of the rule memory data can be reduced.
  • an aggregated internal conclusion object (Ea (Net1-Net2)) is generated (aggregated internal conclusion object 1741 in FIG. 17).
  • the rule loader program 122 generates a connection toward the aggregate internal conclusion object generated from the OR operator object 1631b generated in step 3018. Note that the thickness of this connection is the same as the input thickness of the connected OR operator object 1631b. Thereafter, the rule loader program 122 advances the process to step 3020.
  • Step 3020 The rule loader program 122 generates an internal conclusion object (EaDiv1-1 (NetX)) in the THEN part.
  • the internal conclusion object (EaDiv1-1 (NetX)) exists in the rule memory data, the corresponding object is not generated. In this way, since the existing internal conclusion object can be used, the data amount of the rule memory data can be reduced.
  • an internal conclusion object (EaDiv1-1 (Net1)) is generated (internal conclusion object 1742a in FIG. 17). Further, the rule loader program 122 generates a connection from the aggregated internal conclusion object (Ea (NetX-NetY)) generated in Step 3019 to the generated internal conclusion object.
  • this connection is the same as the input thickness of the connected aggregate internal conclusion object. Further, this connection may be made via the OR operator object 1631b or the AND operator object 1631a. Thereafter, the rule loader program 122 advances the process to Step 3021.
  • Step 3021 The rule loader program 122 repeats the following processing of Step 3021-1 to Step 3021-4 for each of the network devices 103 in the subnet X searched in Step 3004. In addition, after finishing the processing for each, the rule loader program 122 advances the processing to Step 3022. First, the rule loader program 122 selects one of the network devices 103 in the subnet X searched in Step 3004 (hereinafter referred to as “target device” in Steps 3021-1 to 3021-4).
  • Step 3021-1 The rule loader program 122 generates a conclusion object 1612 and a BLEND operator object 1631c corresponding to the conclusion related to the target device.
  • a conclusion object corresponding to a conclusion related to the target device exists in the rule memory data, the corresponding object is not generated. In this way, since the existing conclusion object can be used, the data amount of the rule memory data can be reduced. Thereafter, the rule loader program 122 advances the processing to Step 3021-2.
  • Step 3021-2 The rule loader program 122 generates a connection from the BLEND operator object 1631c generated at Step 3021-1 to each of the conclusion objects generated at Step 3021-1. Thereafter, the rule loader program 122 advances the process to Step 3021-3.
  • Step 3021-3 The rule loader program 122 generates a connection from the internal conclusion object (EaDiv1-1 (NetX)) generated at Step 3020 to the basic input of the BLEND operator object 1631c generated at Step 3021-1. To do. Note that the connection thickness is the same as the input thickness of the connected internal conclusion object (EaDiv1-1 (NetX)). Thereafter, the rule loader program 122 advances the processing to Step 3021-4.
  • Step 3021-4 The rule loader program 122 generates a connection from the condition object corresponding to the condition related to the target device to the delta input of the BLEND operator object 1631c generated in Step 3021-1.
  • Step 3022 The rule loader program 122 generates an internal conclusion object (EaDiv1-5 (NetY)) in the THEN part.
  • the internal conclusion object (EaDiv1-5 (NetX)) exists in the rule memory data, the corresponding object is not generated. In this way, since the existing internal conclusion object can be used, the data amount of the rule memory data can be reduced.
  • an internal conclusion object (EaDiv1-5 (Net2)) is generated (internal conclusion object 1742c in FIG. 17). Further, the rule loader program 122 generates a connection from the aggregated internal conclusion object (Ea (NetX-NetY)) generated in Step 3019 to the internal conclusion object.
  • this connection is the same as the input thickness of the connected aggregate internal conclusion object. Further, this connection may be made via the OR operator object 1631b or the AND operator object 1631a. Thereafter, the rule loader program 122 proceeds with the process to step 3023.
  • Step 3023 The rule loader program 122 repeats the following processing of Step 3023-1 to Step 3023-4 for each of the network devices 103 in the subnet Y searched in Step 3007. In addition, after finishing the processing for each, the rule loader program 122 advances the processing to Step 3024. First, the rule loader program 122 selects one of the network devices 103 in the subnet Y searched in Step 3007 (hereinafter referred to as “target device” in Step 3023-1 to Step 3023-4).
  • Step 3023-1 The rule loader program 122 generates a conclusion object and a BLEND operator object 1631c corresponding to the conclusion related to the target device. Thereafter, the rule loader program 122 advances the process to Step 3023-2.
  • Step 3023-2 The rule loader program 122 generates a connection from the BLEND operator object 1631c generated in Step 3023-1 to each of the conclusion objects generated in the same Step 3023-1. Thereafter, the rule loader program 122 advances the process to Step 3023-3.
  • Step 3023-3 The rule loader program 122 generates a connection from the internal conclusion object (EaDiv1-5 (NetY)) generated at Step 3022 to the basic input of the BLEND operator object 1631c generated at Step 3023-1. To do. The thickness of this connection is the same as the input thickness of the connected internal conclusion object (EaDiv1-5 (NetY)). Thereafter, the rule loader program 122 proceeds with the process to step 3023-4.
  • Step 3023-4 The rule loader program 122 generates a connection from the condition object corresponding to the condition related to the target device to the delta input of the BLEND operator object 1631c generated in Step 3023-1.
  • Step 3024 The rule loader program 122 repeats the following processing of Step 3024-1 to Step 3024-4 for each of the border routers searched in Step 3010. In addition, after finishing the processing for each, the rule loader program 122 advances the processing to Step 3025. First, the rule loader program 122 selects one of the border routers searched in Step 3010 (hereinafter referred to as “target device” in Steps 3024-1 to 3024-4).
  • Step 3024-1 The rule loader program 122 generates a conclusion object and a BLEND operator object 1631c corresponding to a conclusion related to the target device. Thereafter, the rule loader program 122 proceeds with the process to step 3024-1.
  • Step 3024-2 The rule loader program 122 generates a connection from the BLEND operator object 1631c generated in Step 3024-1 to each of the conclusion objects generated in Step 3024-1. Thereafter, the rule loader program 122 proceeds with the process to step 3024-3.
  • Step 3024-3 The rule loader program 122 establishes connection from the aggregate internal conclusion object (Ea (NetX-NetY)) generated at Step 3019 to the basic input of the BLEND operator object 1631c generated at Step 3024-1. Generate. The thickness of this connection is the same as the input thickness of the connected aggregate internal conclusion object (Ea (NetX-NetY)). Thereafter, the rule loader program 122 proceeds with the process to step 3024-4.
  • Step 3024-4 The rule loader program 122 generates a connection from the condition object corresponding to the condition related to the target device to the delta input of the BLEND operator object 1631c generated in Step 3024-1.
  • Step 3025 The rule loader program 122 repeats the processing of the following steps 3025-1 to 3025-4 for each of the border routers searched in step 3011. In addition, after finishing the processing for each, the rule loader program 122 advances the processing to Step 3026. First, the rule loader program 122 selects one of the border routers searched in step 3011 (hereinafter referred to as “target device” in steps 3025-1 to 3025-4).
  • Step 3025-1 The rule loader program 122 generates a conclusion object and a BLEND operator object 1631c corresponding to the conclusion related to the target device. Thereafter, the rule loader program 122 proceeds with the process to step 3025-2.
  • Step 3025-2 The rule loader program 122 generates a connection from the BLEND operator object 1631c generated in Step 3025-1 to each conclusion object generated in Step 3025-1. Thereafter, the rule loader program 122 proceeds with the process to step 3025-3.
  • Step 3025-3 The rule loader program 122 establishes a connection from the aggregate internal conclusion object (Ea (NetX-NetY)) generated at Step 3019 to the basic input of the BLEND operator object 1631c generated at Step 3025-1. Generate. The thickness of this connection is the same as the input thickness of the connected aggregate internal conclusion object (Ea (NetX-NetY)). Thereafter, the rule loader program 122 proceeds with the process to step 3025-4.
  • Step 3025-4 The rule loader program 122 generates a connection from the condition object corresponding to the condition related to the target device to the delta input of the BLEND operator object 1631c generated in Step 3025-1.
  • Step 3026 The rule loader program 122 generates an internal conclusion object (EaDiv1-3 (NetZ)) in the THEN part.
  • the internal conclusion object (EaDiv1-3 (NetZ)) exists in the rule memory data, the corresponding object is not generated. In this way, since the existing internal conclusion object can be used, the data amount of the rule memory data can be reduced.
  • an internal conclusion object (EaDiv1-3 (Net0)) is generated (internal conclusion object 1742b in FIG. 17). Further, the rule loader program 122 generates a connection from the aggregated internal conclusion object (Ea (NetX-NetY)) generated in Step 3019 to the internal conclusion object.
  • this connection is the same as the input thickness of the connected aggregate internal conclusion object. Further, this connection may be made via the OR operator object 1631b or the AND operator object 1631a. Thereafter, the rule loader program 122 proceeds with the process to step 3027.
  • Step 3027 The rule loader program 122 repeats the processing of the following steps 3027-1 to 3027-4 for each of the network devices 103 between the subnet X and the subnet Y searched in step 3012. Note that, after finishing the processing for each, the rule loader program 122 advances the processing to Step 3028. First, the rule loader program 122 reads one of the network devices 103 between the subnet X and the subnet Y searched in step 3012 (hereinafter referred to as “target device” in steps 3027-1 to 3027-4). Select.
  • Step 3027-1 The rule loader program 122 generates a conclusion object and a BLEND operator object 1631c corresponding to a conclusion related to the target device. Thereafter, the rule loader program 122 proceeds with the process to step 3027-2.
  • Step 3027-2 The rule loader program 122 generates a connection from the BLEND operator object 1631c generated in Step 3027-1 to each of the conclusion objects generated in Step 3027-1. Thereafter, the rule loader program 122 proceeds with the process to step 3027-3.
  • Step 3027-3 The rule loader program 122 generates a connection from the internal conclusion object (EaDiv1-3 (NetZ)) generated in Step 3026 to the basic input of the BLEND operator object 1631c generated in Step 3027-1. To do. Note that the thickness of this connection is the same as the input thickness of the connected internal conclusion object (EaDiv1-3 (NetZ)). Thereafter, the rule loader program 122 proceeds with the process to step 3027-4.
  • Step 3027-4 The rule loader program 122 generates a connection from the condition object corresponding to the condition related to the target device to the delta input of the BLEND operator object 1631c generated in Step 3027-1.
  • Step 3028 The rule loader program 122 ends the loop 1.
  • the matching rate calculation process is performed by the matching rate evaluation program 125.
  • each object included in the rule memory data outputs a value corresponding to the output from the source object.
  • the output of the conditional object follows the connection relationship of the objects and flows downstream.
  • the output finally reaches the conclusion object the output of the conclusion object becomes the matching rate.
  • the matching rate evaluation program 125 performs the following recursive process.
  • Step 4001 The matching rate evaluation program 125 specifies a target object (an object connected to the downstream side, hereinafter referred to as “object A”) of the condition object whose output value has changed. Thereafter, the matching rate evaluation program 125 advances the process to Step 4002.
  • object A an object connected to the downstream side
  • Step 4002 The matching rate evaluation program 125 performs a process according to the type of object for each object A, and generates a new output value. Thereafter, the matching rate evaluation program 125 advances the process to Step 4003.
  • the matching rate evaluation program 125 identifies the target object (hereinafter “object B”) of the object A that has generated a new output value. If the object B is a conclusion object, the matching rate evaluation program 125 stores the new output value as a matching rate. If the object B is an object other than the conclusion object, the matching rate evaluation program 125 performs the processing of step 4002 with the object B as “each of object A”.
  • the calculation of the matching rate is started from the condition object related to the event that becomes true (1) by the event detection. Even when the output of a certain conditional event is changed from true (1) to 0, which means non-detection, after a predetermined time has elapsed, the matching rate can be recalculated by performing the same processing as described above. However, the execution of each object may be controlled by other methods regardless of the above.
  • the matching rate evaluation program 125 detects, for example, a conclusion object 1612 whose matching rate exceeds a predetermined value from the rule memory data, and the conclusion object 1612 manages it.
  • the conclusion event is identified as the root cause, and information indicating the root cause is displayed on the display 117 via the input / output device 114, for example.
  • Information indicating the root cause event may be output (transmitted) to another device and displayed on the other device.
  • the general rule means that when an event included in the conclusion occurs, an event included in the condition always occurs.
  • event detection cannot always be performed from such affected node devices.
  • the affected node device is obtained by the monitoring computer using the rule memory data of the present embodiment, it is difficult to trace the affected range by the Aggregate event (Ea (NetX-NetY)). Therefore, the CPU 111 identifies the corresponding condition event (that is, the affected node device) by searching the corresponding general rule using the specified node device and event type as a key, and temporarily stores it in the storage resource 112. For example, it may be displayed on the display device 117.
  • FIG. 21 is a flowchart of the event reception process.
  • the event reception program 123 receives the event message 1401 from the monitoring target device (specifically, the monitoring agents 141 and 166 in the monitoring target device).
  • Step 2102 The event reception program 123 acquires the monitoring target name 1411 and the event type 1412 from the event message 1401 received in Step 2101, adds the monitoring target type and the reception date and time to the acquired information 1411 and 1412, and acquires event information 1511. Create Then, the event reception program 123 adds the created event information 1511 to the event queue table 134 and ends the process.
  • FIG. 22 is a flowchart of the event writing process.
  • Step 2201 The event writing program 124 acquires one event information 1511 from the event queue table 134.
  • Step 2202 The event writing program 124 acquires the monitoring target type 1501, the monitoring target name 1502, and the event type 1503 from the event information 1511 acquired in Step 2201.
  • Step 2203 the event writing program 124 searches the rule memory data using the monitoring target name 1502 and the event type 1503 acquired in Step 2202 as keys, and the condition object whose monitoring target name 1502 and event type 1503 match. Is identified. Then, the event writing program 124 sets the output value of the identified condition object to true (that is, 1) and ends the process. When the output value of the object is changed in this way, the above-described matching rate calculation process is executed.
  • the monitoring computer 101 may be configured by a network device, for example, a switch.
  • 101 monitoring computer
  • 102 server
  • 103 network device
  • 104 storage.

Abstract

　情報システムは、複数のネットワーク装置と、複数のノード装置と、発生した事象の原因を分析するコンピュータとを有する。コンピュータの記憶資源は、ネットワーク装置及びノード装置で発生する事象を示す条件と、結論とを含むルールを記憶する。コンピュータは、複数のネットワーク装置の条件に対応する複数の条件オブジェクトの事象の発生情報を集約するための集約内部条件オブジェクトを生成し、集約内部条件オブジェクトを、ネットワーク装置の条件に対応する条件オブジェクト、ノード装置の条件に対応する条件オブジェクト、及び、結論に対応する結論オブジェクトに関連付ける。

Description

事象の原因を特定する情報システム、コンピュータ及び方法
　本発明は、複数のノード装置が属するネットワークにおいて発生した事象の原因を特定する技術に関する。
　サーバ、ストレージ、ネットワーク装置等の複数の装置を有する情報処理システムにおける、例えば、障害等に関わる事象（以下「イベント」という）の根本原因を特定する技術が知られている。
　例えば、特許文献１は、以下の技術を開示している。すなわち、まず、根本原因の分析に用いられるルールメモリデータが、ルールメモリに格納される。根本原因分析エンジンは、イベントの通知を受信する都度、そのイベントに関するデータをルールメモリに追加するとともに、ルールメモリデータに含まれるルールのうち受信したイベントに関連するルールのマッチング率を計算する。マッチング率は、どのルールの結論が根本原因である可能性が高いかを示す指標（確率又は計算された比率）であり、分析エンジンは、計算されたマッチング率に基づいて根本原因を特定することができる。また、各イベントは有効期間を有しており、持続期間が満了した場合、当該イベントに関するデータが、ルールメモリから削除される。分析エンジンは、削除されたイベントに関係して影響を受けたルールに関してのみマッチング率の再計算を行う。
　特許文献１に開示された技術によれば、分析エンジンが増加分または減少分のイベントについてのみ処理を行うため、計算コストを減らすことができる。また、分析エンジンがマッチング率に基づいて根本原因を特定するため、たとえ１つ以上の条件要素が真でない場合でも最も可能性の高い結論を判定することができ、分析精度を向上させることができる。
米国特許出願公開第２００９／３１３１９８号明細書
　ところで、根本原因の分析に用いられるルールメモリデータは、複数のルールやそのルールに関わるイベントの発生情報やそのルールに関わるイベントのマッチング率等の情報を含むデータである。ルールメモリデータは、例えば、複数のオブジェクトとそれらの関連付けにより構造化されたオブジェクトモデルによって表現される。このオブジェクトモデルには、例えば、ルールの条件に対応する条件オブジェクト、ルールの結論に対応する結論オブジェクト、オブジェクト間の入出力の演算を行う演算オブジェクト等が含まれ、これらのオブジェクトは全てデータとしてメモリに格納される。また、オブジェクト間の接続は、例えば、接続先のオブジェクトのポインタデータとしてメモリに格納される。
　根本原因の分析技術は、一般には、中規模から大規模の情報処理システムに導入される。小規模システムでは、監視すべき装置が少なく、人手により原因を特定できる場合が多く、根本原因の分析技術を導入する必要性に乏しいからである。一方で、監視すべき装置が多い大規模システムでは、人手により原因を特定することは困難であり、根本原因の分析技術の導入価値は高い。
　しかしながら、監視すべき装置が多い大規模システムでは、監視すべき装置の数に応じて、判定すべきルールの数が多くなる。判定すべきルールの数が多くなれば、オブジェクトモデルのオブジェクトの数や接続の数が増え、結果的にルールメモリデータの増大を招くことになる。
　情報システムは、複数のサブネットワークを構成する複数のネットワーク装置と、複数のサブネットワークに属する複数のノード装置と、発生した事象の原因を特定するコンピュータとを有する。コンピュータは、記憶資源と、記憶資源に接続された制御デバイスと、を有する。記憶資源は、１以上のルールと、ネットワーク装置及びノード装置がどのサブネットワークに所属するかを表したサブネットワーク情報とを記憶する。各ルールは、一端のノード装置と他端のノード装置とそれらを中継するネットワーク装置とを含んだトポロジに関するトポロジ情報と、そのトポロジにおける事象を示す条件と、その条件を満たす原因となる事象を示す結論と、を含む。
　制御デバイスは、以下の（ａ１）～（ａ１３）を所定の順番に行うことにより、ルールメモリデータを生成して記憶資源に格納する。ここで、所定の順番とは、（ａ１）～（ａ１３）の記載順番に従った順番であってもよく、また、この記載順番に従って実行することにより生成されるルールメモリデータと同一のルールメモリデータを生成することができれば、任意の別の順番であってもよい。
（ａ１）制御デバイスは、サブネットワーク情報に基づいて、或る第１のサブネットワークにおける１以上のネットワーク装置を特定し、当該ネットワーク装置によるルールの条件となる事象の発生情報を管理する１以上の第１の条件オブジェクトを、ルールメモリデータに存在しない場合に生成し、生成した１以上の第１の条件オブジェクトをルールメモリデータに含める。
（ａ２）制御デバイスは、１以上の第１の条件オブジェクトの全ての事象の発生情報を集約するための第１の内部条件オブジェクトを、ルールメモリデータに存在しない場合に生成し、生成した第１の内部条件オブジェクトをルールメモリデータに含める。
（ａ３）制御デバイスは、第１の内部条件オブジェクトを第１の条件オブジェクトに関連付ける。
（ａ４）制御デバイスは、サブネットワーク情報に基づいて、或る第２のサブネットワークにおける１以上のネットワーク装置を特定し、当該ネットワーク装置によるルールの条件となる事象の発生情報を管理する１以上の第２の条件オブジェクトを、ルールメモリデータに存在しない場合に生成し、生成した１以上の第２の条件オブジェクトをルールメモリデータに含める。
（ａ５）制御デバイスは、１以上の第２の条件オブジェクトの全てからの事象の発生情報を集約する第２の内部条件オブジェクトを、ルールメモリデータに存在しない場合に生成し、生成した２の内部条件オブジェクトをルールメモリデータに含める。
（ａ６）制御デバイスは、第２の内部条件オブジェクトを第２の条件オブジェクトに関連付ける。
（ａ７）制御デバイスは、第１の内部条件オブジェクト、第２の内部条件オブジェクトの事象の発生情報を集約した集約情報を管理する集約内部条件オブジェクトを、ルールメモリデータに存在しない場合に生成し、生成した集約内部条件オブジェクトをルールメモリデータに含める。
（ａ８）制御デバイスは、集約内部条件オブジェクトを、第１及び第２の内部条件オブジェクトに関連付ける。
（ａ９）制御デバイスは、サブネットワーク情報に基づいて、第１のサブネットワークにおける複数のノード装置を特定し、当該ノード装置によるルールの条件となる事象の発生情報を管理する複数の第３の条件オブジェクトを、ルールメモリデータに存在しない場合に生成し、生成した複数の第３の条件オブジェクトを、ルールメモリデータに含める。
（ａ１０）制御デバイスは、集約内部条件オブジェクトの集約情報と、第３の条件オブジェクトの事象の発生情報とに基づいた、条件を判定するための判定情報を管理する集約内部結論オブジェクトを、ルールメモリデータに存在しない場合に生成し、生成した集約内部結論オブジェクトをルールメモリデータに含める。
（ａ１１）制御デバイスは、集約内部結論オブジェクトを、集約内部条件オブジェクト及び第３の条件オブジェクトに関連付ける。
（ａ１２）制御デバイスは、第１のサブネットワークにおけるネットワーク装置、及び第２のサブネットワークのネットワーク装置のそれぞれで発生する事象を示す結論が原因である可能性を示す指標を管理する複数の結論オブジェクトを、ルールメモリデータに存在しない場合に生成し、生成した複数の結論オブジェクトをルールメモリデータに含める。
（ａ１３）制御デバイスは、複数の結論オブジェクトを集約内部結論オブジェクトに関連付ける。
　制御デバイスは、複数のネットワーク装置又は複数のノード装置における事象の発生情報を受信し、ルールメモリデータに基づいて、受信した発生情報を管理する条件オブジェクトを特定し、特定した条件オブジェクトの管理する事象の発生情報を更新するとともに、条件オブジェクトに対する関連付けを辿って、発生情報の更新の影響が及ぶ各オブジェクトの管理する情報を更新していくことにより、結論オブジェクトの指標を更新し、更新した結論オブジェクトの指標に基づいて、事象の原因を特定し出力する。
図１は、実施形態に係る情報処理システムの構成図である。 図２は、情報処理システムのネットワークの構成例１を示す図である。 図３は、構成例１におけるサブネット管理テーブルの一例を示す図である。 図４は、情報処理システムのネットワークの構成例２を示す図である。 図５は、構成例２におけるサブネット管理テーブルの一例を示す図である。 図６は、ルータ管理テーブルの一例を示す図である。 図７は、ｉＳＣＳＩターゲット管理テーブルの一例を示す図である。 図８は、一般ルールの一例を示す図である。 図９は、展開ルールの一例を示す図である。 図１０は、サブネットが隣り合う場合の分解ルールの一例を示す図である。 図１１は、サブネットが隣り合う場合の分解のイメージを表す図である。 図１２は、サブネットを跨ぐ場合の分解ルールの一例を示す図である。 図１３は、サブネットを跨ぐ場合の分解のイメージを表す図である。 図１４は、イベントメッセージの一例を示す図である。 図１５は、イベントキューテーブルの一例を示す図である。 図１６は、構成例１におけるルールメモリデータの一例を示す図である。 図１７は、構成例２におけるルールメモリデータの一例を示す図である。 図１８は、ルール処理のフローチャートである。 図１９は、分解ルール生成処理のフローチャートである。 図２０は、同一サブネット用ルールメモリデータ生成処理のフローチャートである。 図２１は、イベント受信処理のフローチャートである。 図２２は、イベント書込処理のフローチャートである。
　実施形態について、図面を参照して説明する。なお、以下に説明する実施形態は特許請求の範囲にかかる発明を限定するものではなく、また実施形態の中で説明されている諸要素及びその組み合わせの全てが発明の解決手段に必須であるとは限らない。これらの図面において、複数の図を通じて同一の符号は同一の構成要素を示している。
　なお、以後の説明では「ａａａテーブル」、「ａａａリスト」、「ａａａＤＢ」、「ａａａキュー」等の表現にて本発明の情報を説明するが、これら情報は必ずしもテーブル、リスト、ＤＢ、キュー、等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「ａａａテーブル」、「ａａａリスト」、「ａａａＤＢ」、「ａａａキュー」等について「ａａａ情報」と呼ぶことがある。
　また、以後の説明では、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」という表現を用いるが、これらについてはお互いに置換が可能である。
　さらに、以後の説明では「プログラム」、「オブジェクト」を主語として説明を行う場合があるが、プログラム、オブジェクトは、制御デバイスが有するプロセッサによって実行されることで定められた処理をメモリ及び通信ポート（ネットワークＩ／Ｆ）を用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラム、オブジェクトを主語として開示された処理は監視コンピュータ等の計算機、情報処理装置が行う処理としてもよい。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。また、各種プログラムはプログラム配布サーバや、計算機が読み取り可能な記憶メディアによって各計算機にインストールされてもよい。
　また、以後の説明では、制御デバイスとしてＣＰＵ（Central Processing Unit）が採用されるが、制御デバイスは、ＣＰＵのようなプロセッサに加えて、所定の処理（例えば圧縮、伸長）を行う専用ハードウェアを含んで良い。
　また、以後の説明では、ＣＰＵ（及び或いはそのＣＰＵを有する監視コンピュータのような第１の計算機）の「表示する」という行為は、ＣＰＵが、そのＣＰＵを有する第１の計算機の表示デバイスにオブジェクト等を表示する行為と、表示デバイスを有する第２の計算機に、その表示デバイスに表示されるオブジェクト等の表示用情報を送信する行為のいずれであっても良い。第２の計算機は、表示用情報を受信した場合、その表示用情報が表すオブジェクト等を表示デバイスに表示することができる。
　図１は、一実施形態に係る情報処理システムの構成図である。
　情報処理システム１００は、原因分析装置の一例としての監視コンピュータ１０１と、１つ以上のサーバ１０２と、１つ以上のネットワーク装置１０３と、ＬＡＮ（Local Area Network）等の通信ネットワーク１０５（１０５ａ、１０５ｂ等）と、１つ以上のストレージ１０４とを有する。ネットワーク装置１０３は、ＩＰスイッチやルータ等である。監視コンピュータ１０１、サーバ１０２及びストレージ１０４は、通信ネットワーク１０５及びネットワーク装置１０３を介して相互に接続される。以下、情報処理システム１００を構成する装置（サーバ１０２、ストレージ装置１０４、ネットワーク装置１０３等）を「ノード装置」と呼ぶ。情報処理システム１００は、例えば、ホストコンピュータ、ＮＡＳ（Network Attached Storage）、ファイルサーバ、プリンタ等をノード装置として有していてもよい。ノード装置は、監視コンピュータ１０１の監視の対象でもあるため、ノード装置を「監視対象装置」と呼ぶこともある。また、ノード装置が有するデバイス等の論理的又は物理的な構成物を「コンポーネント」と呼ぶ。コンポーネントの例としては、ポート、プロセッサ、記憶資源、記憶デバイス、プログラム、仮想マシン、ストレージ装置内部で定義される論理ボリューム、ＲＡＩＤグループ等がある。なお、監視対象装置とコンポーネントとを区別せずに扱う場合は「監視対象」と呼ぶ。
　サーバ１０２は、アプリケーション等を実行する計算機である。サーバ１０２は、ＣＰＵ（Central　Processing　Unit）１４６と、メモリ１４７と、ネットワークインターフェース（Ｉ／Ｆ）１４２と、ｉＳＣＳＩ（Internet　Small　Computer　System　Interface）イニシエータ１４３とを有する。サーバ１０２は、所定のアプリケーションをＣＰＵ１４６により実行することにより、論理的なコンポーネントである監視エージェント１４１を生成する。監視エージェント１４１は、監視対象において何らかのイベントが発生した場合に、そのイベントの発生を示すイベントメッセージを監視コンピュータ１０１に送信する。また、サーバ１０２には、ストレージ１０４の記憶領域が割り当てられた仮想的なボリュームであるｉＳＣＳＩディスク１５１が形成される。サーバ１０２は、ｉＳＣＳＩイニシエータ１４３を介すことで、ｉＳＣＳＩディスク１５１をローカルハードディスクのように利用できる。
　ストレージ１０４は、サーバ１０２等に記憶領域を提供する装置である。ストレージ１０４は、ストレージコントローラ１６１と、ネットワークＩ／Ｆ１６３と、記憶媒体１６２とを有する。本実施形態において、記憶媒体１６２は、ハードディスクドライブ（ＨＤＤ）であるが、これに代えて、固体記憶媒体、光記憶媒体等、他の種類の記憶媒体であってもよい。ストレージ１０４は、例えば、サーバ１０２に対して、ｉＳＣＳＩディスク１５１を形成するための記憶領域を提供する。ストレージ１０４は、所定のアプリケーションを図示しないＣＰＵにより実行することにより、論理的なコンポーネントである監視エージェント１６６を生成する。監視エージェント１６６は、ストレージ１０４において何らかのイベントが発生した場合に、そのイベントの発生を示すイベントメッセージを監視コンピュータ１０１に送信する。なお、サーバ１０２の監視エージェント１４１が、ストレージ１０４で発生したイベントを監視できるように構成し、ストレージ１０４で発生したイベントのイベントメッセージを監視コンピュータ１０１に送信するようにしてもよい。
　監視コンピュータ１０１は、監視対象装置を管理する計算機である。監視コンピュータ１０１は、例えば、汎用的な計算機であり、ＣＰＵ１１１と、記憶資源１１２と、入出力デバイス１１４と、システムバス１１６と、ネットワークＩ／Ｆ１１５とを有する。記憶資源１１２は、メモリであってもよいし、ハードディスクドライブ（ＨＤＤ）等の二次記憶装置であってもよいし、メモリ及び二次記憶装置を組み合わせたものであってもよい。ＣＰＵ１１１、記憶資源１１２、入出力デバイス１１４、及び、ネットワークＩ／Ｆ１１５は、システムバス１１６を介して相互に接続される。
　記憶資源１１２は、例えば、ルールメモリ１２１と、ルールローダープログラム１２２と、イベント受信プログラム１２３と、イベント書込プログラム１２４と、マッチング率評価プログラム１２５と、一般ルールリポジトリ１３１と、展開ルールリポジトリ１３２と、分解ルールリポジトリ１３３と、イベントキューテーブル（ＴＢＬ）１３４と構成情報１３５とを記憶する。ルールローダープログラム１２２、イベント受信プログラム１２３、イベント書込プログラム１２４、マッチング率評価プログラム１２５は、ＣＰＵ１１１により実行される。ルールメモリ１２１には、根本原因を分析する際に利用されるルールメモリデータが格納される。一般ルールリポジトリ１３１には、一以上の一般ルールが格納される。展開ルールリポジトリ１３２には、一以上の展開ルールが格納される。分解ルールリポジトリ１３３には、一以上の分解ルールが格納される。一般ルール、展開ルール及び分解ルールについては、後に図面を参照して説明する。
　ネットワークＩ／Ｆ１１５は、通信ネットワーク１０５に接続するためのインターフェース装置である。入出力デバイス１１４は、入出力装置に接続するためのインターフェース装置である。例えば、入出力デバイス１１４には、ディスプレイ１１７が接続される。監視コンピュータ１０１は、根本原因分析の結果や他の情報をディスプレイ１１７に表示することで、根本原因分析の結果等を管理者に提示することができる。なお、監視コンピュータ１０１が、内部にディスプレイ１１７を有するようにしてもよい。
　監視コンピュータ１０１は、監視対象装置から例えば、監視対象でイベントが発生したことを示すイベントメッセージ、監視対象装置或いは情報処理システム１００全体の構成情報等の種々の情報を受信する。監視コンピュータ１０１は、監視対象装置から受信した種々の情報に基づいて、例えば、イベントの原因を解析する処理等の種々の処理を行い、その処理結果を出力する。
　本実施形態において、幾つかの監視対象装置は例えば、ｉＳＣＳＩボリュームの提供サービスやファイル共有サービスやＷｅｂサービス等のネットワークサービスを提供する装置（以下「サービス提供装置」）である。また、幾つかの監視対象装置は、サービス提供装置が提供するネットワークサービスを利用する装置（以下「サービス利用装置」）である。例えば、サーバ１０２は、ストレージ１０４が提供するｉＳＣＳＩボリュームの提供サービスを利用するため、サービス利用装置に相当する。一方、ストレージ１０４は、サーバ１０２等にｉＳＣＳＩボリュームの提供サービスを提供するため、サービス提供装置に相当する。サービス提供装置及びサービス利用装置は、相互にネットワークサービスを提供して利用する関係を有しているため、その一方で発生したイベントが他方へ伝搬し得る。例えば、サービス提供装置に相当するストレージ１０４で或るイベントが発生した場合、そのストレージ１０４が提供するネットワークサービスを利用しているサーバ１０２（すなわちサービス利用装置）においても同様のイベントが発生し得る。
　ここで、監視コンピュータ１０１の記憶資源１１２に記憶される構成情報１３５について説明する。構成情報１３５は、情報処理システム１００の構成を示す情報であり、具体的には、情報処理システム１００がどんなノード装置によって構成されているか、各ノード装置の構成がどのようになっているか（例えば、ノード装置がどんなコンポーネントを有しているか）、ノード装置間或いはコンポーネント間の接続関係がどうなっているか、ノード装置とコンポーネントとの間の包含関係がどうなっているか等を示す情報である。また、構成情報１３５には、ネットワークサービスの提供又は利用に関係する情報（例えば、サービス利用装置の識別情報、ネットワークサービスを利用する際にサービス提供装置に入力する情報等）が含まれる場合がある。サービス提供装置に入力する情報として、例えば、ｉＳＣＳＩボリュームの提供サービスを利用する際に入力するｉＳＣＳＩターゲット名及びＬＵＮ（論理ユニット番号）や、Ｗｅｂサービスを利用する際に入力するＷｅｂサーバの名前を含むＵＲＬ等がある。
　図２は、情報処理システムのネットワークの構成例１を示す図である。ここで、図２及び他の図面において、「ｓｖ」、「ｓｔ」、「ｓｗ」、「ｒｔ」及び「Ｎｅｔ」は、それぞれ、サーバ１０２、ストレージ１０４、ＩＰスイッチ、ルータ及びサブネットワーク（サブネット）を意味している。
　構成例１では、ｉＳＣＳＩボリュームの提供サービスに関して、サービス利用装置に相当するサーバ（ｓｖ１、ｓｖ２）が、サブネット１に属し、サービス提供装置に相当するストレージ（ｓｔ１）が、サブネット１と異なるサブネット０に属している。サブネット１と、サブネット０とは、ネットワーク装置であるルータ（ｒｔ１）を介して互いに接続されている。構成例１では、サーバの属するサブネット（すなわち、サブネット１）と、ストレージ（ｓｔ１）の属するサブネット（すなわち、サブネット０）とは、隣り合っている。
　図３は、構成例１における、サブネット管理テーブルの一例を示す図である。
　サブネット管理テーブル３０１は、監視対象装置がどのサブネットに所属するかを表した情報を管理するためのテーブルである。なお、サブネット管理テーブル３０１は、構成情報１３５の一部に相当する。サブネット管理テーブル３０１には、ノード装置ごとに、当該ノード装置のノードＩＤ３１１と、当該ノード装置のノードタイプ３１２と、当該ノード装置のノード名３１３と、当該ノード装置に割り当てられたＩＰアドレス３１４と、当該ノード装置が所属するサブネットＩＤ３１５とが、対応付けて格納される。
　ノードＩＤ３１１は、ノード装置を一意に特定するための識別子である。ノードタイプ３１２は、ノード装置の種別を示す情報である。本実施形態では、ノードタイプ「ＳＥＲＶＥＲ」はサーバ１０２を、ノードタイプ「ＳＴＯＲＡＧＥ」はストレージ１０４を、ノードタイプ「ＩＰＳＷＩＴＣＨ」はＩＰスイッチを、ノードタイプ「ＲＯＵＴＥＲ」はルータをそれぞれ示している。サブネットＩＤ３１５は、サブネットを一意に特定するための識別子である。本実施形態では、サブネットＩＤ「０」はサブネット０を、サブネットＩＤ「１」はサブネット１をそれぞれ示している。
　同図のサブネット管理テーブル３０１によると、サーバ１及びサーバ２がサブネット１に所属し、ストレージ１がサブネット０に所属していることを知ることができる。
　図４は、情報処理システムのネットワークの構成例２を示す図である。
　構成例２では、ｉＳＣＳＩボリュームの提供サービスに関して、サービス利用装置に相当するサーバ（ｓｖ１、ｓｖ２）がサブネット１に属し、サービス提供装置に相当するストレージ（ｓｔ１）が、サブネット１と異なるサブネット２に属している。サブネット１と、サブネット２とは、他のサブネット０（例えば、基幹ＬＡＮ）を介して接続されている。構成例２では、サーバの属するサブネット（すなわち、サブネット１）と、ストレージ（ｓｔ１）の属するサブネット（すなわち、サブネット２）とは、他のサブネット０を跨って接続されている。
　図５は、構成例２におけるサブネット管理テーブルの一例を示す図である。
　サブネット管理テーブル３０１は、図３で示したサブネット管理テーブル３０１と同じ構成となっている。監視コンピュータ１０１は、図５のサブネット管理テーブル３０１を参照することにより、サーバ１及びサーバ２がサブネット１に所属し、ストレージ２がサブネット２に所属していることを知ることができる。
　図６は、ルータ管理テーブルの一例を示す図である。
　ルータ管理テーブル６０１は、ルータがどのサブネットとどのサブネットとを接続しているかを表す情報を管理するためのテーブルである。なお、ルータ管理テーブル６０１は、構成情報１３５の一部に相当する。ルータ管理テーブル６０１には、ルータごとに、例えば、当該ルータのノードＩＤ６１１と、当該ルータのノードタイプ６１２と、当該ルータが接続する二つのサブネットＩＤ６１３、６１４（サブネットＩＤ１、サブネットＩＤ２）とが、対応付けて記録される。
同図のルータ管理テーブル６０１によると、ルータ１がサブネット０とサブネット１とを接続しており、ルータ２がサブネット０とサブネット２とを接続していることを知ることができる。
　図７は、ｉＳＣＳＩターゲット管理テーブルの一例を示す図である。
　ｉＳＣＳＩターゲット管理テーブル７０１は、ｉＳＣＳＩターゲットがどのｉＳＣＳＩイニシエータに対して接続を許可しているかを表す情報を管理するためのテーブルである。なお、ｉＳＣＳＩターゲット管理テーブル７０１は、構成情報１３５の一部に相当する。ｉＳＣＳＩターゲット管理テーブル７０１には、例えば、ターゲットＩＤ７１１と、ｉＳＣＳＩターゲット名７１２と、接続許可ｉＳＣＳＩイニシエータ名７１３とが、対応付けて記録される。
　ターゲットＩＤ７１１は、ｉＳＣＳＩターゲットと接続許可ｉＳＣＳＩイニシエータとの組み合わせ（以下「ｉＳＣＳＩ接続許可セット」）ごとに付与された識別子である。ｉＳＣＳＩターゲット名７１２は、ｉＳＣＳＩターゲットの名称である。接続許可ｉＳＣＳＩイニシエータ名７１３は、接続が許可されているｉＳＣＳＩイニシエータの名称である。例えば、ターゲットＩＤ「ＴＧ１」の情報から、ｉＳＣＳＩターゲットであるストレージ１は、ｉＳＣＳＩイニシエータであるサーバ１に対して接続を許可していることがわかる。
　図８は、一般ルールの一例を示す図である。
　一般ルールは、イベントを示す条件と、当該条件を満たす場合に原因と特定されるイベントを示す結論と、を情報処理システム１００の実構成に依存しない形式で記述した情報である。一般ルールは、複数の条件又は複数の結論を含んでいてもよい。また、一般ルールがネットワーク装置１０３に関係するイベント（以下「ネットワークイベント」）を示す条件を含む場合には、一般ルールには、さらに、そのネットワークイベントに関係するネットワーク装置１０３及び当該ネットワーク装置１０３を介して相互に接続されるサービス提供装置及びサービス利用装置に関するトポロジ情報が含まれる。なお、以下の説明において、ネットワークイベントに関係するネットワーク装置１０３を介して相互に接続されるサービス提供装置及びサービス利用装置を、それぞれ「ネットワークイベントに係るサービス提供装置」及び「ネットワークイベントに係るサービス利用装置」という場合がある。
　同図に示すように、一般ルール８０１、８０２には、ＩＦ部８１１、８１３とＴＨＥＮ部８１２、８１４とがある。ＩＦ部８１１、８１３には条件が記述され、ＴＨＥＮ部８１２、８１４には結論が記述される。条件及び結論は、それぞれイベントの発生元のノード装置のノードタイプとイベントのイベントタイプとを含む。
　一般ルール８０１（ＧｅｎＲｕｌｅ１）においては、ＩＦ部８１１には、二つの条件８２１、８２２が記述されている。また、ＴＨＥＮ部８１２には、一つの結論８２３（「ＩＰＳＷＩＴＣＨ　Ｐｏｒｔ＿ＬｉｎｋＤｏｗｎ」）が記述されている。この一般ルール８０１は、二つの条件８２１、８２２が満たされた場合に、結論８１２によって示されるイベントが原因であると特定されることを表している。
　条件８２１には、「ＳＥＲＶＥＲ　ＤｉｓｋＤｒｉｖｅ＿Ｅｒｒ」が記述されており、ノードタイプが「ＳＥＲＶＥＲ」であり、イベントタイプが「ＤｉｓｋＤｒｉｖｅ＿Ｅｒｒ」であることを示している。条件８２１は、サーバ１０２で発生するディスク障害というイベントを示している。条件８２２には、「ＩＰＳＷＩＴＣＨ　Ｐｏｒｔ＿ＬｉｎｋＤｏｗｎ」が記述されており、ノードタイプが「ＩＰＳＷＩＴＣＨ」であり、イベントタイプが「Ｐｏｒｔ＿ＬｉｎｋＤｏｗｎ」であることを示している。条件８２２は、ＩＰスイッチで発生するポートのリンク障害というイベントを示している。なお、条件８２２が示すイベントは、ＩＰスイッチというネットワーク装置１０３に関係するイベントであるため「ネットワークイベント」に相当する。このように一般ルール８０１がネットワークイベントを示す条件を含んでいるため、一般ルール８０１には、さらに、トポロジ情報８３１が含まれる。同図で示す例では、トポロジ情報８３１には、ネットワーク装置１０３を示すノードタイプ「ＩＰＳＷＩＴＣＨ」と、サービス提供装置及びサービス利用装置のいずれかを示す「ＳＥＲＶＥＲ」及び「ＳＴＯＲＡＧＥ」とが含まれている。このトポロジ情報８３１は、サーバ１０２とストレージ１０４とがＩＰスイッチを介して接続されることを示している。
　一方、一般ルール８０２（ＧｅｎＲｕｌｅ２）においては、二つの条件８２４、８２５と一つの結論８２６が含まれる。条件８２４、８２５が示すイベントは、いずれもネットワークイベントではない。従って、一般ルール８０２には、トポロジ情報は含まれていない。
　図９は、展開ルールの一例を示す図である。
　展開ルールは、一般ルールを情報処理システム１００の実構成に依存する形式に展開した情報である。例えば、情報処理システム１００に一つのサーバ１０２（サーバ１）と一つのストレージ１０４（ストレージ１）と一つのＩＰスイッチ（ＩＰスイッチ１）とが含まれていると想定した場合、図８に示す一般ルール８０１は、図９に示す展開ルール９０１（ＥｘｐＲｕｌｅ１）に展開される。展開ルール９０１には、サーバ１、ストレージ１、及びＩＰスイッチ１という情報処理システム１００の実構成である監視対象に関係するイベントを示す条件及び結論が含まれる。具体的には、展開ルール９０１には、サーバ１で発生するディスク障害というイベントを示す条件と、ＩＰスイッチ１で発生するポートのリンク障害というイベントを示す条件及び結論とが含まれる。
　図１０は、サブネットが隣り合う場合の分解ルールの一例を示す図である。図１１は、サブネットが隣り合う場合の分解のイメージを表す図である。
　分解ルールは、ネットワークイベントを示す条件を含む一般ルールに基づいて生成される情報である。分解ルールは、一般ルールに含まれるネットワークイベントを示す条件を複数のグループ（例えば、サブネット）ごとの複数の条件に分解することにより生成される。なお、ネットワークイベントを示す条件だけでなく、ネットワークイベントを示す結論についても、複数のグループ（例えば、サブネット）ごとの複数の結論に分解するようにしてもよい。本実施形態では、ネットワークイベントを示す条件及び結論のいずれについても、複数のグループごとの複数の条件及び結論に分解される。
　本実施形態では、図２に示す構成例１のように、ネットワークイベントに係るサービス利用装置（構成例１ではサーバ１、２）が所属するサブネット（以下「第一のサブネット」という）とネットワークイベントに係るサービス提供装置（構成例１ではストレージ１）が所属するサブネット（以下「第二のサブネット」という）とが隣り合う場合は、ネットワークイベントを示す条件及び結論は、それぞれ、第一のサブネット内のネットワークイベントを集約したイベントを示す条件及び結論と、第二のサブネット内のネットワークイベントを集約したイベントを示す条件及び結論と、第一のサブネットと第二のサブネットとを接続するネットワーク装置１０３（構成例１ではルータ１）のネットワークイベントを示す条件及び結論とに分解される。
　なお、以下の説明において、ネットワークイベントを集約したイベントを「内部イベント」といい、内部イベントを示す条件及び結論をそれぞれ「内部条件」及び「内部結論」という場合がある。また、複数の内部イベントを集約したイベントを「集約内部イベント」といい、集約内部イベントを示す条件及び結論をそれぞれ「集約内部条件」及び「集約内部結論」という場合がある。また、或るサブネットＡ内のネットワークイベントを集約したイベントを「サブネットＡに係る内部イベント」といい、或るサブネットＡに係る内部イベントを示す条件及び結論をそれぞれ「サブネットＡに係る内部条件」及び「サブネットＡに係る内部結論」という場合がある。さらに、或るサブネットＡと他のサブネットＢとを接続するネットワーク装置１０３のネットワークイベントを「サブネットＡ－Ｂの接続に係る内部イベント」（或いは「サブネットＡ－サブネットＢの接続に係る内部イベント」）といい、サブネットＡ－Ｂの接続に係る内部イベントを示す条件及び結論をそれぞれ「サブネットＡ－Ｂの接続に係る内部条件」及び「サブネットＡ－Ｂの接続に係る内部結論」（或いは「サブネットＡ－サブネットＢの接続に係る内部条件」及び「サブネットＡ－サブネットＢの接続に係る内部結論」）という場合がある。
　サブネットが隣り合う場合のネットワークイベントを示す条件及び結論の分解について、図１１を参照して説明する。関係１１１１は、一般ルール８０１についての条件及び結論のそれぞれを示すイベントの関係を示している。関係１１１１は、イベント１１０２、１１０３が発生した場合に、イベント１１０１が結論、すなわち、原因と特定されることを示している。
　関係１１１２は、一般ルール８０１に基づいて生成される分解ルールについての条件及び結論のそれぞれを示すイベントの関係を示している。イベント１１０６は、一般ルール８０１のネットワークイベント１１０３に対応するイベントであり、一般ルール８０１のネットワークイベント１１０３が複数のイベント１１２１、１１２２、１１２３に分解されることを表している。具体的には、図１１に示すように、ネットワークイベント１１０３は、サブネットＸ（この例では第一のサブネットに相当）に係る内部イベント１１２１と、サブネットＹ（この例では第二のサブネットに相当）に係る内部イベント１１２２と、サブネットＸ－Ｙの接続に係る内部イベント１１２３とに分解される（つまり、ネットワークイベント１１０３を示す条件は、サブネットＸに係る内部条件と、サブネットＹに係る内部条件と、サブネットＸ－Ｙの接続に係る内部条件とに分解される）。なお、結論についても、上記と同様に分解される。従って、ネットワークイベント１１０１が示す結論は、サブネットＸに係る内部結論と、サブネットＹに係る内部結論と、サブネットＸ－Ｙの接続に係る内部結論とに分解される。
　次に、図１０に示す分解ルールについて、詳細に説明する。上記説明したように、ネットワークイベント１１０３を示す条件は、ネットワークイベント１１０６に示すように、サブネットＸに係る内部条件と、サブネットＹに係る内部条件と、サブネットＸ－Ｙの接続に係る内部条件とに分解される。従って、一般ルール８０１は、サブネットＸに係る内部条件１０２１を含む分解ルール１０１１と、サブネットＹに係る内部条件１０２２を含む分解ルール１０１２と、サブネットＸ－Ｙの接続に係る内部条件１０２３を含む分解ルール１０１３とに分解される。
　条件１０３１は、内部条件１０２１、１０２２、１０２３を集約した集約内部条件を示している。このように、本実施形態では、分解ルール１０１１、１０２２、１０１３に加えて、集約内部条件１０３１を含む分解ルール１００１も生成される。また、分解ルール１０１１、１０２２、１０１３は、それらのＴＨＥＮ部において分解ルール１００１の集約内部条件１０３１を規定している。これは、分解ルール１０１１、１０２２、１０１３の結論が示すイベントが、集約内部条件１０３１が示すイベント（すなわち集約内部イベント）と同じであることを意味している。
　なお、一般ルール８０２にはネットワークイベントを示す条件が含まれないため、一般ルール８０２に基づいて分解ルールは生成されない。
　図１２は、サブネットを跨ぐ場合の分解ルールの一例を示す図である。図１３は、サブネットを跨ぐ場合の分解のイメージを表す図である。
　本実施形態では、図４で示す構成例２のように、第一のサブネットと第二のサブネットとが他のサブネットを跨いでいる場合は、ネットワークイベントを示す条件及び結論は、それぞれ、第一のサブネットに係る内部条件及び内部結論と、第二のサブネットに係る内部条件及び内部結論と、第一のサブネットと第二のサブネットとの間に介在するサブネット（以下「第三のサブネット」という）に係る内部条件及び結論と、第一のサブネット－第三のサブネットの接続に係る内部条件及び内部結論と、第二のサブネット－第三のサブネットの接続に係る内部条件及び内部結論とに分解される。
　サブネットを跨ぐ場合のネットワークイベントを示す条件及び結論の分解について、図１３を参照して説明する。一般ルール８０１のイベントの関係１１１１については、図１１と同様である。イベント１３０２は、一般ルール８０１のネットワークイベント１１０３が、サブネットＸ（この例では第一のサブネットに相当）に係る内部イベント１３２１と、サブネットＹ（この例では第二のサブネットに相当）に係る内部イベント１３２２と、サブネットＸとサブネットＹとの間に介在するサブネット（図示しないが、サブネットＺとする）に係る内部イベント１３２３と、サブネットＸ－Ｚの接続に係る内部イベント１３２４と、サブネットＹ－Ｚの接続に係る内部イベント１３２５とに分解されることを表している。つまり、一般ルール８０１のネットワークイベント１１０３を示す条件は、サブネットＸに係る内部条件と、サブネットＹに係る内部条件と、サブネットＺに係る内部条件と、サブネットＸ－Ｚの接続に係る内部条件と、サブネットＹ－Ｚの接続に係る内部条件とに分解される。結論についても、ネットワークイベントを示す条件と同様に分解される。
　次に、図１２に示す分解ルールについて、詳細に説明する。上記説明したように、ネットワークイベント１１０３を示す条件は、ネットワークイベント１３０２に示すように、サブネットＸに係る内部条件と、サブネットＹに係る内部条件と、サブネットＺに係る内部条件と、サブネットＸ－Ｚの接続に係る内部条件と、サブネットＹ－Ｚの接続に係る内部条件とに分解される。従って、一般ルール８０１は、サブネットＸに係る内部条件１２２１を含む分解ルール１２１１と、サブネットＹに係る内部条件１２２２を含む分解ルール１２１２と、サブネットＺに係る内部条件１２２３を含む分解ルール１２１３と、サブネットＸ－Ｚの接続に係る内部条件１２２４を含む分解ルール１２１４と、サブネットＹ－Ｘの接続に係る内部条件１２２５を含む分解ルール１２１５とに分解される。
　分解ルールとして、内部条件１２２１、１２２２、１２２３、１２２４、１２２５を集約した集約内部条件１２３１を含む分解ルール１００１も生成される。分解ルール１２１１、１２２２、１２１３、１２１４、１２１５は、それらのＴＨＥＮ部において分解ルール１２０１の集約内部条件１２３１を記述している。従って、分解ルール１２１１、１２２２、１２１３、１２１４、１２１５の結論が示すイベントは、集約内部条件１２３１が示すイベント（すなわち集約内部イベント）と同じである。
　図１４は、イベントメッセージの一例を示す図である。
　イベントメッセージ１４０１は、監視対象におけるイベントの発生を通知するためのメッセージであり、監視エージェント１４１、１６６により監視コンピュータ１０１へ送信される。イベントメッセージ１４０１は、例えば、イベントの発生元である監視対象の監視対象名１４１１と、発生したイベントのイベントタイプ１４１２とを含む。監視対象名１４１１は、監視対象の名称であり、監視対象がノード装置である場合はノード名となる。
　図１５は、イベントキューテーブルの一例を示す図である。
　イベントキューテーブル１３４は、発生したイベントに関するイベント情報１５１１を管理するためのテーブルである。イベント受信プログラム１２３は、イベントメッセージ１４０１を受信した場合に、受信したイベントメッセージ１４０１により通知されたイベントのイベント情報１５１１を、このテーブルに入れる。イベントキューテーブル１３４は、イベント書込プログラム１２４のバッファとして機能する。イベント書込プログラム１２４は、イベントキューテーブル１３４からイベント情報１５１１を取得し、当該イベント情報１５１１に基づいてルールメモリデータの内容を更新する。なお、イベントキューテーブル１３４は、監視対象で発生する通常のイベントに関するイベント情報の他、内部イベントや集約内部イベントに関するイベント情報１５１１を管理するようにしてもよい。
　各イベント情報１５１１には、例えば、発生したイベントの発生元である監視対象の監視対象タイプ１５０１と、発生したイベントの発生元である監視対象の監視対象名１５０２と、発生したイベントのイベントタイプ１５０３と、発生したイベントに関する受信日時１５０４とが含まれる。監視対象タイプ１５０１は、監視対象の種別を示す情報であり、監視対象がノード装置である場合はノードタイプ（「ＳＥＲＶＥＲ」、「ＳＴＯＲＡＧＥ」、「ＩＰＳＷＩＴＣＨ」、「ＲＯＵＴＥＲ」等）となる。監視対象名１５０２は、監視対象の名称であり、監視対象がノード装置である場合はノード名となる。受信日時１５０４は、イベント受信プログラム１２３がイベントメッセージ１４０１を受信した日時である。
　図１６は、構成例１における、ルールメモリデータの一例を示す図である。図１７は、構成例２におけるルールメモリデータの一例を示す図である。
　ルールメモリデータは、少なくとも、根本原因の分析に用いられる複数のルールと、そのルールに関わるイベントの発生情報と、そのルールに関わるイベントが原因となる可能性を示す情報とを、複数のオブジェクト及びそれらの関連付けにより表現したデータである。ルールメモリデータは、例えば分解ルールに基づいて生成され、根本原因を分析する際に利用される。
　ルールメモリデータには、例えば、条件オブジェクト１６１１と、内部条件オブジェクト１６２２（１６２２ａ、１６２２ｂ等）、１７２２（１７２２ａ、１７２２ｂ、１７２２ｃ等）と、集約内部条件オブジェクト１６２１、１７２１と、結論オブジェクト１６１２と、内部結論オブジェクト１６４２、１７４２と、集約内部結論オブジェクト１６４１、１７４１と、演算子オブジェクト１６３１と、それぞれの接続情報とが含まれる。なお、各オブジェクトは、コンピュータ言語では例えば構造体やクラスとして実装され、プログラム動作中は記憶資源１１２に格納されるデータ（オブジェクトデータ）である。
　接続情報は、例えば、接続するオブジェクトの識別子をペアで保持した情報である。接続情報は、方向情報を持ち、方向情報は、或るオブジェクトの出力を別のオブジェクトの入力とする関係、換言すれば、オブジェクト間の上流下流の関係を示している。また、接続情報は太さ情報を持つ。太さ情報は、演算子オブジェクト１６３１への入力数に相当し、後述するＢＬＥＮＤ演算子オブジェクト１６３１ｃで重要な要素となる。太さ情報としては、太さを示す値であってもよい。図１６及び図１７では、接続の太さの値を「×数字」で示している。なお、条件オブジェクト１６１１からの接続は、太さを１とするのが一般的であるが、必ずしも太さを１とする必要はない。
　各オブジェクトの接続に関して、次のような処理が行われる。なお、以下の説明において、或るオブジェクトに着目したときに、そのオブジェクトへ出力するオブジェクト（そのオブジェクトの上流側に接続されているオブジェクト）を「ソースオブジェクト」と呼び、そのオブジェクトからの出力を入力として受け取るオブジェクト（そのオブジェクトの下流側に接続されているオブジェクト）を「ターゲットオブジェクト」と呼ぶ。
　すなわち、条件オブジェクト１６１１は、この条件オブジェクト１６１１に接続されたターゲットオブジェクトに出力する。結論オブジェクト１６１２は、この結論オブジェクト１６１２に接続されたソースオブジェクトからの出力を入力として受ける。演算子オブジェクト１６３１は、この演算子オブジェク１６３１に接続された一つ以上のソースオブジェクトの出力を入力として受け取り、この演算子オブジェクト１６３１に接続されたターゲットオブジェクトに出力する。内部条件オブジェクト１６２２、１７２２、集約内部条件オブジェクト１６２１、１７２１、内部結論オブジェクト１６４２、１７４２及び集約内部結論オブジェクト１６４１、１７４１は、これらオブジェクトに接続された一つ以上のソースオブジェクトの出力を入力として受け取り、これらオブジェクトに接続されたターゲットオブジェクトに出力する。
　条件オブジェクト１６１１は、特定の監視対象に関係するイベント及びそのイベントの発生情報を管理するオブジェクトである。条件オブジェクト１６１１は、展開ルール、分解ルールの条件に対応する。例えば、図１６及び図１７の例では、条件オブジェクト１６１１は、サーバ１のディスク障害というイベント及びそのイベントの発生情報を管理する。例えば、サーバ１においてディスク障害が発生すると、この発生したイベントのイベント情報１５１１が、イベント受信プログラム１２３によってイベントキューテーブル１３４に追加される。そして、イベント書込プログラム１２４が、そのイベントキューテーブル１３４に追加されたイベント情報１５１１を取得し、サーバ１のディスク障害を管理する条件オブジェクト１６１１の出力値を真（すなわち１）にする。条件オブジェクト１６１１の出力値が真となることで、その条件オブジェクト１６１１は、そこに接続されたターゲットオブジェクトにその出力値（真）を出力する。
　演算子オブジェクト１６３１には、ＯＲ演算子オブジェクト１６３１ｂと、ＡＮＤ演算子オブジェクト１６３１ａと、ＢＬＥＮＤ演算子オブジェクト１６３１ｃとがある。
　ＯＲ演算子オブジェクト１６３１ｂは、一つ以上のソースオブジェクトの出力のいずれかが真（１）であった場合に真（１）をターゲットオブジェクトに出力するオブジェクトである。後述するマッチング率の計算処理においては、ＯＲ演算子オブジェクト１６３１ｂは、一つ以上ソースオブジェクトの出力の最大値をターゲットオブジェクトに出力する。なお、ＯＲ演算子オブジェクト１６３１ｂの場合、ターゲットオブジェクトとの接続の太さは、ソースオブジェクトとの接続の太さと同じになる。
　ＡＮＤ演算子オブジェクト１６３１ａは、一つ以上のソースオブジェクトの出力の全てが真（１）であった場合に真（１）をターゲットオブジェクトに出力するオブジェクトである。後述するマッチング率の計算処理においては、ＡＮＤ演算子オブジェクト１６３１ａは、以下の式２のＡＮＤ出力値をターゲットオブジェクトに出力する。なお、ＡＮＤ演算子オブジェクト１６３１ａの出力側の接続の太さは、下記式（１）により算出されるＸである。
Figure JPOXMLDOC01-appb-M000001
Figure JPOXMLDOC01-appb-M000002
 ここで、Ｘは、このＡＮＤ演算子オブジェクト１６３１ａのターゲットオブジェクトの全ての入力の太さの和を示している。なお、他の同様な記載も、同様な意味を持っている。
　ＢＬＥＮＤ演算子オブジェクト１６３１ｃへの入力は、基礎入力となる入力（原則一つ）と、デルタ入力となる入力との二種類に分けられる。図１６及び図１７では、デルタ入力を、丸印介した接続で表現している。後述するマッチング率の計算処理においては、ＢＬＥＮＤ演算子オブジェクト１６３１ｃは、以下の式３のＢＬＥＮＤ出力値をターゲットオブジェクト（典型的には結論オブジェクト１６１２）に出力する。
Figure JPOXMLDOC01-appb-M000003
　内部条件オブジェクト１６２２、１７２２は、その上流側に位置する条件オブジェクト１６１１が管理するイベントの全てを集約するオブジェクトである。内部条件オブジェクト１６２２、１７２２は、その上流側に位置する条件オブジェクトの全てからのイベントの発生情報を集約した集約情報を管理する。内部条件オブジェクト１６２２、１７２２は、分解ルールの内部条件（図１０における内部条件１０２１～１０２３、図１２における内部条件１２２１～１２２５）に対応する。
　図１６に示す例では、内部条件オブジェクト１６２２ａ（ＥａＤｉｖ１－１（Ｎｅｔ１））は、分解ルール１０１１のサブネットＸに係る内部条件１０２１に対応し（サブネットＸがサブネット１に特定されている）、サブネット１内のネットワークイベント（この例ではスイッチ１の１つネットワークイベント）の発生情報を集約する。内部条件オブジェクト１６２２ｂ（ＥａＤｉｖ１－５（Ｎｅｔ０））は、分解ルール１０１２のサブネットＹに係る内部条件１０２２に対応し（サブネットＹがサブネット０に特定されている）、サブネット０内のネットワークイベント（この例ではスイッチ２の１つネットワークイベント）の発生情報を集約する。
　また、図１７に示す例では、内部条件オブジェクト１７２２ｂ（ＥａＤｉｖ１－３（Ｎｅｔ０））は、分解ルール１２１３のサブネットＺに係る内部条件１２２３に対応し（サブネットＺがサブネット１とサブネット２との間に介在するサブネット０に特定されている）、サブネット０内のネットワークイベント（この例ではスイッチ２とスイッチ３の２つのネットワークイベント）の発生情報を集約する。なお、内部条件オブジェクト１６２２、１７２２のターゲットオブジェクトへの接続の太さは、ソースオブジェクトからの接続の太さと同じである。
　集約内部条件オブジェクト１６２１、１７２１は、その上流側に位置する内部条件オブジェクト１６２２、１７２２が管理するイベントの全てを集約するオブジェクトである。集約内部条件オブジェクト１６２１、１７２１は、その上流側に位置する内部条件オブジェクト１６２２、１７２２の全てからのイベントの発生情報を集約した集約情報を管理する。集約内部条件オブジェクト１６２１、１７２１は、分解ルールの集約内部条件（図１０の集約内部条件１０３１、図１２の集約内部条件１２３１）に対応する。
　図１６に示す例では、集約内部条件オブジェクト１６２１（Ｅａ（Ｎｅｔ１－Ｎｅｔ０））は、分解ルール１００１の集約内部条件１０３１に対応し、内部条件オブジェクト１６２２ａ、１６２２ｂ、及びルータ１のネットワークイベントの発生情報を管理する条件オブジェクト１６１１の全てからのイベントの発生情報を集約する。つまり、集約内部条件オブジェクト１６２１（Ｅａ（Ｎｅｔ１－Ｎｅｔ０））は、サブネット１及びサブネット０内の全てのネットワーク装置１０３（スイッチ１、スイッチ２及びルータ１）のネットワークイベントの発生情報を集約する。
　図１７に示す例では、集約内部条件オブジェクト１７２１（Ｅａ（Ｎｅｔ１－Ｎｅｔ２））は、分解ルール１２０１の集約内部条件１２３１に対応し、内部条件オブジェクト１７２２ａ、１７２２ｂ、１７２２ｃ、ルータ１のネットワークイベントの発生情報を管理する条件オブジェクト１６１１、及びルータ２のネットワークイベントの発生情報を管理する条件オブジェクト１６１１の全てからのイベントの発生情報を集約する。つまり、集約内部条件オブジェクト１７２１（Ｅａ（Ｎｅｔ１－Ｎｅｔ２））は、サブネット１、サブネット２及びサブネット１とサブネット２の間にある全てのネットワーク装置１０３（スイッチ１～４及びルータ１、２）のネットワークイベントの発生情報を集約する。
　結論オブジェクト１６１２は、特定の監視対象に関係するイベント（図１６及び図１７に示す例では、ネットワークイベント）及びそのイベントを示す結論が原因である可能性を示す指標（例えば、マッチング率）を管理するオブジェクトである。結論オブジェクト１６１２は、展開ルール等の結論に対応する。例えば、図１６及び図１７に示す例では、結論オブジェクト１６１２は、スイッチ１のネットワーク障害というイベント及びそのイベントが原因である可能性を示す指標を管理する。
　内部結論オブジェクト１６４２（１６４２ａ、１６４２ｂ等）、１７４２（１７４２ａ、１７４２ｂ、１７４２ｃ等）は、その下流側に位置する結論オブジェクト１６１２が管理するイベントの全てを集約するオブジェクトである。内部結論オブジェクト１６４２、１７４２は、分解ルールの内部結論に対応する。例えば、図１６の例では、内部結論オブジェクト１６４２ａ（ＥａＤｉｖ１－１（Ｎｅｔ１））は、分解ルール１０１１の内部結論に対応し、サブネット１内のネットワークイベント（この例ではスイッチ１の１つのネットワークイベント）を集約する。内部結論オブジェクト１６４２ｂ（ＥａＤｉｖ１－５（Ｎｅｔ０））は、分解ルール１０１２の内部結論に対応し、サブネット０内のネットワークイベント（この例ではスイッチ２の１つのネットワークイベント）を集約する。また、図１７に示す例では、内部結論オブジェクト１７４２ｂ（ＥａＤｉｖ１－３（Ｎｅｔ０））は、分解ルール１２１３の内部結論に対応し、サブネット０内のネットワークイベント（この例ではスイッチ２とスイッチ３の２つネットワークイベント）を集約する。
　集約内部結論オブジェクト１６４１、１７４１は、その下流側に位置する内部結論オブジェクト１６２２、１７４２のそれぞれに集約されるイベントの全てを集約するオブジェクトである。集約内部結論オブジェクト１６４１、１７４１は、分解ルールの集約内部結論に対応する。例えば、図１６に示す例では、集約内部結論オブジェクト１６４１（Ｅａ（Ｎｅｔ１－Ｎｅｔ０））は、分解ルール１００１の集約内部結論に対応し、内部結論オブジェクト１６４２ａ、１６４２ｂ、及びルータ１のネットワークイベントの条件オブジェクト１６１１のそれぞれが集約（管理）するイベントの全てを集約する。つまり、集約内部結論オブジェクト１６４１（Ｅａ（Ｎｅｔ１－Ｎｅｔ０））は、サブネット１及びサブネット０内の全てのネットワーク装置１０３（スイッチ１、スイッチ２及びルータ１）のネットワークイベントを集約する。また、図１７に示す例では、集約内部結論オブジェクト１７４１（Ｅａ（Ｎｅｔ１－Ｎｅｔ２））は、分解ルール１２０１の集約内部結論に対応し、内部結論オブジェクト１７４２ａ、１７４２ｂ、１７４２ｃ、ルータ１のネットワークイベントの発生情報を管理する条件オブジェクト１６１１、及びルータ２のネットワークイベントの発生情報を管理する条件オブジェクト１６１１のそれぞれが集約するイベントの全てを集約する。つまり、集約内部結論オブジェクト１７４１（Ｅａ（Ｎｅｔ１－Ｎｅｔ２））は、サブネット１、サブネット２及びサブネット１とサブネット２の間にある全てのネットワーク装置１０３（スイッチ１～４及びルータ１、２）のネットワークイベントの発生情報を集約する。
　なお、オブジェクトが内部条件オブジェクト１６２２、１７２２、集約内部条件オブジェクト１６２１、１７２１、内部結論オブジェクト１６４２、１７４２又は集約内部結論オブジェクト１６４１、１７４１である場合は、データ構造として、少なくとも対応するイベントを検知（つまり、イベント書込プログラム１２４がイベント情報１５１１を取得）したか否かを示すフラグを持ってもよい。また、本実施形態では、複数の出力を行うオブジェクトが存在するが、これらオブジェクトからの出力を１つにし、出力を入力として、複数の出力を行うマルチプレクサオブジェクトを備えるようにしてもよい。
　図１８は、ルール処理のフローチャートである。
　ルール処理（ステップ１８０１～ステップ１８０８の処理）は、一般ルールリポジトリ１３１に存在する一般ルールの数だけ繰り返し行われる。
　（ステップ１８０１）ルールローダープログラム１２２は、一つの一般ルールｉを選択し、選択した一般ルールｉのＩＦ部に二つ以上のノードタイプが含まれているか否かを判定する。
　（ステップ１８０２）一般ルールｉのＩＦ部に二つ以上のノードタイプが含まれている場合（ステップ１８０１：ＹＥＳ）は、ルールローダープログラム１２２は、一般ルールｉのＩＦ部にネットワークイベントを示す条件が含まれているか否かを判定する。
　（ステップ１８０３）一般ルールｉのＩＦ部にネットワークイベントを示す条件が含まれている場合（ステップ１８０２：ＹＥＳ）は、ルールローダープログラム１２２は、ネットワークイベントに係るサービス提供装置とネットワークイベントに係るサービス利用装置との間の接続がｉＳＣＳＩ接続であるか否かを判定する。
　ネットワークイベントに係るサービス提供装置及びサービス利用装置間の接続がｉＳＣＳＩ接続である場合は（ステップ１８０３：ＹＥＳ）、ルールローダープログラム１２２は、ｉＳＣＳＩターゲット管理テーブル７０１に存在するｉＳＣＳＩ接続許可セットの数だけ、ステップ１８０４～ステップ１８０７の処理を繰り返し行う。
　（ステップ１８０４）ルールローダープログラム１２２は、サブネット管理テーブル３０１から、一つのｉＳＣＳＩ接続許可セットｊを選択し、ｉＳＣＳＩ接続許可セットｊに含まれるｉＳＣＳＩターゲットが所属するサブネット（図１８及び図１９においては、サブネットＸとする）とｉＳＣＳＩ接続許可セットｊに含まれるｉＳＣＳＩイニシエータが所属するサブネット（図１８及び図１９においては、サブネットＹとする）とを取得する。
　（ステップ１８０５）、ルールローダープログラム１２２は、サブネットＸとサブネットＹとが異なるか否かを判定する。
　（ステップ１８０６）サブネットＸとサブネットＹとが異なる場合（ステップ１８０５：ＹＥＳ）は、ルールローダープログラム１２２は、分解ルール生成処理（図１９参照）を行う。分解ルール生成処理が終了した後は、ルールローダープログラム１２２は、新たに一つのｉＳＣＳＩ接続許可セットを選択して、選択したｉＳＣＳＩ接続許可セットに対して再度ステップ１８０４～ステップ１８０７の処理を行う。
　（ステップ１８０７）サブネットＸとサブネットＹとが同じ場合（ステップ１８０５：ＮＯ）は、ルールローダープログラム１２２は、同一サブネット用ルールメモリデータ生成処理（図２０参照）を行う。同一サブネット用ルールメモリデータ生成処理が終了した後は、ルールローダープログラム１２２は、新たに一つのｉＳＣＳＩ接続許可セットを選択して、選択したｉＳＣＳＩ接続許可セットに対して再度ステップ１８０４～ステップ１８０７の処理を行う。
　（ステップ１８０８）ステップ１８０１において、一般ルールｉのＩＦ部に二つ以上のノードタイプが含まれていない場合（ステップ１８０１：ＮＯ）、ステップ１８０２において、一般ルールｉのＩＦ部にネットワークイベントを示す条件が含まれていない場合（ステップ１８０２：ＮＯ）、又は、ステップ１８０３において、ネットワークイベントに係るサービス提供装置及びサービス利用装置間の接続がｉＳＣＳＩ接続でない場合は（ステップ１８０３：ＮＯ）には、ルールローダープログラム１２２は、同一サブネット用ルールメモリデータ生成処理を行う。同一サブネット用ルールメモリデータ生成処理が終了した後は、ルールローダープログラム１２２は、新たに一つの一般ルールを選択して、選択した一般ルールに対して再度ステップ１８０１～ステップ１８０８の処理を行う。
　一般ルールリポジトリ１３１に存在する全ての一般ルールについてステップ１８０１～ステップ１８０８の処理が完了した場合、ルールローダープログラム１２２は、ルール処理を終了する。
　以上説明したように、本実施形態では、ネットワークイベントに係るサービス利用装置が所属するサブネットとネットワークイベントに係るサービス提供装置が所属するサブネットとが異なる場合には、一般ルールに基づいて分解ルールが生成され、これらサブネットが同じ場合には、分解ルールは生成されずに一般ルール或いは一般ルールを展開した展開ルール）に基づいて、ルールメモリデータが生成される。つまり、共通の一般ルールに基づいて、分解ルールを生成し、或いは直接にルールメモリデータを生成することができるので、ルール作成者の手間が増えない。
　図１９は、分解ルール生成処理のフローチャートである。ここで、図１９は、サブネットＸとサブネットＹとが他のサブネット（図１２及び図１３に示す例に合わせて、サブネットＺとする）を跨いでいる場合の処理である。なお、サブネットＸとサブネットＹとが隣り合う場合は、ステップ１９０３と、ステップ１９０４又はステップ１９０５のいずれか一方の処理を省略することができる。
　サブネットを跨ぐ場合に、一般ルールの条件及び結論がどのように分解されてどのような分解ルールが生成されるかは、図１２及び図１３で説明したとおりである。すなわち、一般ルール８０１のネットワークイベント１１０３を示す条件及び結論が、それぞれ、サブネットＸに係る内部条件１２２１及び内部結論と、サブネットＹに係る内部条件１２２２及び内部結論と、サブネットＺに係る内部条件１２２３及び内部結論と、サブネットＸ－Ｚの接続に係る内部条件１２２４及び内部結論と、サブネットＹ－Ｚの接続に係る内部条件１２２５及び内部結論とに分解され、サブネットＸに係る内部条件１２２１を含む分解ルール１２１１と、サブネットＹに係る内部条件１２２２を含む分解ルール１２１２と、サブネットＺに係る内部条件１２２３を含む分解ルール１２１３と、サブネットＸ－Ｚの接続に係る内部条件１２２４を含む分解ルール１２１４と、サブネットＹ－Ｚの接続に係る内部条件１２２５を含む分解ルール１２１５とが生成される。また、サブネットＸに係る内部条件１２２１、サブネットＹに係る内部条件１２２２、サブネットＺに係る内部条件１２２３、サブネットＸ－Ｚの接続に係る内部条件１２２４、及びサブネットＹ－Ｚの接続に係る内部条件１２２５の全てを集約した集約内部条件１２３１を含む分解ルール１００１が生成される。
　（ステップ１９０１）ルールローダープログラム１２２は、サブネットＸに係る内部条件１２２１を含む分解ルール１２１１を生成する。
　（ステップ１９０２）ルールローダープログラム１２２は、サブネットＹに係る内部条件１２２２を含む分解ルール１２１２を生成する。
　（ステップ１９０３）ルールローダープログラム１２２は、サブネットＺに係る内部条件１２２３を含む分解ルール１２１３を生成する。
　（ステップ１９０４）ルールローダープログラム１２２は、サブネットＸ－Ｚの接続に係る内部条件１２２４を含む分解ルール１２１４を生成する。
　（ステップ１９０５）ルールローダープログラム１２２は、サブネットＹ－Ｚの接続に係る内部条件１２２５を含む分解ルール１２１５を生成する。
　（ステップ１９０６）ルールローダープログラム１２２は、内部条件１２２１～１２２５の全てを集約した集約内部条件１２３１（すなわち、ＡｇｇｒｅｇａｔｅＥｖｅｎｔ）を含む分解ルール１００１を生成し、処理を終了する。
　なお、内部条件１２２１～１２２５を含む分解ルール１２１１～１２１５は、例えば、そのＩＦ部に、ネットワークイベントを示す条件と、ネットワーク装置及びそのネットワーク装置を介して接続されるノード装置に関するトポロジ情報と、ネットワーク装置及びそのネットワーク装置を介して接続されるノード装置がどのサブネットに属するかを示す情報とが含まれるように生成される。また、ＴＨＥＮ部には、ＡｇｇｒｅｇａｔｅＥｖｅｎｔという集約内部結論が含められる。なお、ＡｇｇｒｅｇａｔｅＥｖｅｎｔは、サブネットＸとサブネットＹとネットワーク装置１０３のイベント（元にした一般ルールに記載のイベント種別）別に生成される。例えば、リンクダウンを条件に含む一般ルール用の分解ルールと、スイッチ自体のプロセッサ障害を条件部に含む一般ルール用の分解ルールとは別になる。
　ＡｇｇｒｅｇａｔｅＥｖｅｎｔは、サブネットＸ内のノード装置からサブネットＹ内のノード装置への通信経路上のネットワーク装置１０３の何れかで、一般ルールの条件に含まれるイベントが発生したことを条件又は結論とすることを意味する。そのため、分解ルール１２１１～１２１５への分解は、分解の元となった一般ルールのサーバ１０２やストレージ１０４のイベント種別には依存しない形になっている。そのため、サーバ１０２のｉＳＣＳＩエラーの場合と、ＤＮＳエラーの場合（ＤＮＳサーバがサブネットＹに居るとして）とで、同じ分解ルールを共用することもできる。
　分解ルール１２１１、１２１２が指し示すＩＰスイッチとは、サブネットＸ（またはサブネットＹ）内のサブネットＹ（またはサブネットＸ）行きの通信でいずれの装置が共用するスイッチであることが考えられるが、必ずしもそうとは限らない。例えば、サブネットＸ内のタブレットコンピュータが全てスイッチＡ（無線ＬＡＮアクセスポイント）を通過し、サーバコンピュータがスイッチＡを通過しない場合は、タブレットコンピュータにしか適用されない一般ルールが対象であれば、スイッチＡが分解ルール１２１１の対象となる。
　図２０は、同一サブネット用ルールメモリデータ生成処理のフローチャートである。
　（ステップ２００１）ルールローダープログラム１２２は、情報処理システム１００のシステムトポロジに基づいて、一般ルールから展開ルールを生成し、生成した展開ルールを展開ルールリポジトリ１３２に保存する。
　（ステップ２００２）ルールローダープログラム１２２は、展開ルールリポジトリ１３２から展開ルールを取得し、取得した展開ルールを構文解析する。
　（ステップ２００３）ルールローダープログラム１２２は、ステップ２００２で取得した展開ルールのＩＦ部から条件を取得する。
　（ステップ２００４）ルールローダープログラム１２２は、ステップ２００３で取得した条件に対応する条件オブジェクトがルールメモリデータ内に存在するか否かを調べる。
　（ステップ２００５）対応する条件オブジェクトが見つからなかった場合（ステップ２００５：ＮＯ）は、ルールローダープログラム１２２は、ステップ２００６に処理を進める。一方、条件オブジェクトが見つかった場合（ステップ２００５：ＹＥＳ）は、ルールローダープログラム１２２は、ステップ２００７に処理を進める。
　（ステップ２００６）ルールローダープログラム１２２は、ステップ２００３で取得した条件のための条件オブジェクト及び演算子オブジェクトをルールメモリデータ内に生成する。また、ルールローダープログラム１２２は、新たに生成された条件オブジェクトと演算子オブジェクトとを互いに接続する。
　（ステップ２００７）ルールローダープログラム１２２は、ＩＦ部内の全ての条件について処理が完了したか否かを調べる。全て処理済みであれば（ステップ２００７：ＹＥＳ）、ルールローダープログラム１２２は、ステップ２００８に処理を進める。一方、未だ処理されていない条件が残っている場合は（ステップ２００７：ＮＯ）、ルールローダープログラム１２２は、処理をステップ２００３に進める。
　（ステップ２００８）ルールローダープログラム１２２は、ステップ２００２で取得した展開ルールのＴＨＥＮ部から結論を取得する。
　（ステップ２００９）ルールローダープログラム１２２は、ステップ２００８で取得した結論に対応する結論オブジェクトをルールメモリデータ内に生成する。また、ルールローダープログラム１２２は、生成された結論オブジェクトと関連する全ての演算子オブジェクトとを接続する。さらに、２つ以上の結論がステップ２００８で取得された場合、ルールローダープログラム１２２は、それら取得された結論のそれぞれについても、対応する結論オブジェクトをルールメモリデータ内に生成し、生成された結論オブジェクトと関連する全ての演算子オブジェクトとを接続する。
　（ステップ２０１０）ルールローダープログラム１２２は、展開ルールリポジトリ１３２内の全ての展開ルールについて処理が完了したか否かを調べる。全て処理済みであれば（ステップ２０１０：ＹＥＳ）、同一サブネット用ルールメモリデータ生成処理を終了する。一方、未だ処理されていない展開ルールが残っている場合（ステップ２０１０：ＮＯ）は、ルールローダープログラム１２２は、処理をステップ２００２に進める。
　次に、本実施形態に係る複数のサブネットが含まれる場合のルールメモリデータ生成処理について説明する。
　このルールメモリ生成処理は、分解ルール生成処理が実行された後に実行される。
　（ステップ３００１）ルールローダープログラム１２２は、全ての分解ルールの内容を調べ、分解ルールに含まれる集約内部条件、内部条件、集約内部結論及び内部結論の全てを抽出する。ルールローダープログラム１２２は、処理をステップ３００２に進める。
　（ステップ３００２）ルールローダープログラム１２２は、ステップ３００１で抽出した集約内部条件、内部条件、集約内部結論及び内部結論のそれぞれについて、以下のステップ３００３からの処理を繰り返すループ（ループ１）を開始する。なお、説明を理解しやすくするため、ここではサブネットを跨ぐ場合の分解ルール（図１２の分解ルール１２０１、１２１１～１２１５）に含まれる集約内部条件、内部条件、集約内部結論及び内部結論だけが抽出されたものとして処理を説明する。
　＜１．ルールメモリデータのＩＦ部の生成＞。
　＜１．１．集約内部条件オブジェクト（Ｅａ（ＮｅｔＸ－ＮｅｔＹ））の生成＞。
　（ステップ３００３）ルールローダープログラム１２２は、ルールメモリデータのＩＦ部１６０１に、分解ルール１２０１から抽出された集約内部条件１２３１（Ｅａ（ＮｅｔＸ－ＮｅｔＹ））に対応する集約内部条件オブジェクト（Ｅａ（ＮｅｔＸ－ＮｅｔＹ））を生成し、処理をステップ３００４に進める。なお、集約内部条件１２３１（Ｅａ（ＮｅｔＸ－ＮｅｔＹ））に対応する集約内部条件オブジェクト（Ｅａ（ＮｅｔＸ－ＮｅｔＹ））が、ルールメモリデータに存在する場合には、当該集約内部条件オブジェクトを利用することができるので、対応するオブジェクトを生成しない。このように、既に存在する集約内部条件オブジェクトを利用することができるので、ルールメモリデータのデータ量を削減することができる。例えば、この集約内部条件オブジェクト（Ｅａ（ＮｅｔＸ－ＮｅｔＹ））は、サブネットＹに所属するサービス提供装置（例えば、ストレージ）を利用する、サブネットＸに所属する複数のサービス利用装置（例えば、サーバ）のそれぞれに対する原因分析において共用することができる。
　ここで、サブネットＸ、Ｙは、互いにネットワークサービスを提供し利用し合っているノード装置（すなわちサービス提供装置とサービス利用装置）が所属するサブネットを意味している。ここでは、サブネットＸは、サービス利用装置であるサーバ１０２が所属するサブネットであり、サブネットＹは、サービス提供装置であるストレージ１０４が所属するサブネットである（分解ルール１２０１を参照）。例えば、情報処理システム１００が構成例２の場合、サーバ１がサブネット０に所属し、ストレージ２がサブネット２に所属している。従って、集約内部条件オブジェクト（Ｅａ（Ｎｅｔ１－Ｎｅｔ２））が生成される（図１７の集約内部条件オブジェクト１７２１）。また、ルールローダープログラム１２２は、ＩＦ部の上記生成した集約内部条件オブジェクトの上流側に、ＯＲ演算子オブジェクト１６３１ｂを生成する。そして、ルールローダープログラム１２２は、生成したＯＲ演算子オブジェクト１６３１ｂから生成した集約内部条件オブジェクトへ向けた接続を生成する。すなわち、ルールローダープログラム１２２は、ＯＲ演算子オブジェクト１６３１ｂの出力値が集約内部条件オブジェクト１７２１の入力値となるように接続を生成する。
　＜１．２．内部条件オブジェクトの生成＞。
　＜１．２．１．内部条件オブジェクト（ＥａＤｉｖ１－１（ＮｅｔＸ））の生成＞。
　（ステップ３００４）ルールローダープログラム１２２は、分解ルール１２１１から抽出された内部条件１２２１の内容に基づいて、サブネットＸに所属し、サブネットＸとサブネットＹとの間の通信に利用されるネットワーク装置１０３（図１２の分解ルールではＩＰスイッチ）を検索する。ルールローダープログラム１２２は、処理をステップ３００５に進める。
　（ステップ３００５）ルールローダープログラム１２２は、ＩＦ部に、分解ルール１２１１から抽出された内部条件１２２１に対応する内部条件オブジェクト（ＥａＤｉｖ１－１（ＮｅｔＸ））を生成する。なお、内部条件１２２１に対応する内部条件オブジェクト（ＥａＤｉｖ１－１（ＮｅｔＸ））がルールメモリデータに存在する場合には、対応するオブジェクトを生成しない。このように、既に存在する内部条件オブジェクトを利用することができるので、ルールメモリデータのデータ量を削減することができる。サブネットＸは、サービス利用装置であるサーバ１０２が所属するサブネットであり、情報処理システム１００が構成例２の場合、サーバ１がサブネット１に所属している。従って、内部条件オブジェクト（ＥａＤｉｖ１－１（Ｎｅｔ１））が生成される（図１７の内部条件オブジェクト１７２２ａ）。また、ルールローダープログラム１２２は、ＩＦ部の生成した内部条件オブジェクトの上流側に、ＯＲ演算子オブジェクト１６３１ｂを生成する（図１７では図示せず）。そして、ルールローダープログラム１２２は、生成したＯＲ演算子オブジェクト１６３１ｂから生成した内部条件オブジェクトへ向けた接続を生成する。その後、ルールローダープログラム１２２は、処理をステップ３００６に進める。
　（ステップ３００６）ルールローダープログラム１２２は、サブネットＸ内のネットワーク装置１０３（図１２の分解ルールではＩＰスイッチ）の各々に関係する条件に対応する条件オブジェクトを生成する。なお、条件に対応する条件オブジェクトがルールメモリデータに存在する場合には、対応するオブジェクトを生成しない。このように、既に存在する条件オブジェクトを利用することができるので、ルールメモリデータのデータ量を削減することができる。情報処理システム１００が構成例２の場合、サブネットＸはサブネット１であり、サブネット１にはスイッチ１が所属している。従って、スイッチ１に関係する条件に対応する条件オブジェクトが生成される。そして、ルールローダープログラム１２２は、生成した条件オブジェクトの各々からステップ３００５で生成したＯＲ演算子オブジェクト１６３１ｂへ向けた接続を生成する。その後、ルールローダープログラム１２２は、処理をステップ３００７に進める。
　＜１．２．２．内部条件オブジェクト（ＥａＤｉｖ１－５（ＮｅｔＸ））の生成＞。
　（ステップ３００７）ルールローダープログラム１２２は、分解ルール１２１２から抽出された内部条件１２２２の内容に基づいて、サブネットＹに所属し、サブネットＸとサブネットＹとの間の通信に利用されるネットワーク装置１０３（図１２の分解ルールではＩＰスイッチ）を検索する。その後、ルールローダープログラム１２２は、処理をステップ３００８に進める。
　（ステップ３００８）ルールローダープログラム１２２は、ＩＦ部に、分解ルール１２１２から抽出された内部条件１２２２に対応する内部条件オブジェクト（ＥａＤｉｖ１－５（ＮｅｔＹ））を生成する。なお、内部条件１２２２に対応する内部条件オブジェクト（ＥａＤｉｖ１－５（ＮｅｔＹ））がルールメモリデータに存在する場合には、対応するオブジェクトを生成しない。このように、既に存在する内部条件オブジェクトを利用することができるので、ルールメモリデータのデータ量を削減することができる。サブネットＹは、サービス提供装置であるストレージ１０４が所属するサブネットであり、情報処理システム１００が構成例２の場合、ストレージ２はサブネット２に所属している。従って、内部条件オブジェクト（ＥａＤｉｖ１－５（Ｎｅｔ２））が生成される（図１７の内部条件オブジェクト１７２２ｃ）。また、ルールローダープログラム１２２は、ＩＦ部の生成した内部条件オブジェクトの上流側に、ＯＲ演算子オブジェクト１６３１ｂを生成する（図１７では図示せず）。そして、ルールローダープログラム１２２は、生成したＯＲ演算子オブジェクト１６３１ｂから生成した内部条件オブジェクトへ向けた接続を生成する。その後、ルールローダープログラム１２２は、処理をステップ３００９に進める。
　（ステップ３００９）ルールローダープログラム１２２は、サブネットＹ内のネットワーク装置１０３（図１２の分解ルールではＩＰスイッチ）の各々に関係する条件に対応する条件オブジェクトを生成する。なお、条件に対応する条件オブジェクトがルールメモリデータに存在する場合には、対応するオブジェクトを生成しない。このように、既に存在する条件オブジェクトを利用することができるので、ルールメモリデータのデータ量を削減することができる。情報処理システム１００が構成例２の場合、サブネットＹはサブネット２であり、サブネット２にはスイッチ４が所属している。従って、スイッチ４に関係する条件に対応する条件オブジェクトが生成される。そして、ルールローダープログラム１２２は、生成した条件オブジェクトの各々からステップ３００８で生成したＯＲ演算子オブジェクト１６３１ｂへ向けた接続を生成する。その後、ルールローダープログラム１２２は、処理をステップ３０１０に進める。
　＜１．２．３．サブネットＸの境界ルータ関係＞。
　（ステップ３０１０）ルールローダープログラム１２２は、サブネットＸの境界ルータ（サブネット同士を接続するルータ）であって、サブネットＸとサブネットＹとの間の通信に利用されるルータを検索する。そして、ルールローダープログラム１２２は、検索したルータに関係する条件に対応する条件オブジェクトを生成する。なお、対応するルータに関係する条件に対応する条件オブジェクトがルールメモリデータに存在する場合には、対応するオブジェクトを生成しない。このように、既に存在する条件オブジェクトを利用することができるので、ルールメモリデータのデータ量を削減することができる。さらに、ルールローダープログラム１２２は、生成した条件オブジェクトからステップ３００３で生成したＯＲ演算子オブジェクト１６３１ｂへ向けた接続を作成する。その後、ルールローダープログラム１２２は、処理をステップ３０１１に進める。
　＜１．２．４．サブネットＹの境界ルータ関係＞。
　（ステップ３０１１）ルールローダープログラム１２２は、サブネットＹの境界ルータであって、サブネットＸとサブネットＹとの間の通信に利用されるルータを検索する。そして、ルールローダープログラム１２２は、検索したルータに関係する条件に対応する条件オブジェクトを生成する。なお、対応するルータに関係する条件に対応する条件オブジェクトがルールメモリデータに存在する場合には、対応するオブジェクトを生成しない。このように、既に存在する条件オブジェクトを利用することができるので、ルールメモリデータのデータ量を削減することができる。さらに、ルールローダープログラム１２２は、生成した条件オブジェクトからステップ３００３で生成したＯＲ演算子オブジェクト１６３１ｂへ向けた接続を作成する。その後、ルールローダープログラム１２２は、処理をステップ３０１２に進める。
　＜１．２．５．内部条件オブジェクト（ＥａＤｉｖ１－３（ＮｅｔＸ－ＮｅｔＹ））の生成＞。
　（ステップ３０１２）ルールローダープログラム１２２は、分解ルール１２１３から抽出された内部条件１２２３の内容に基づいて、サブネットＸとサブネットＹとの間に位置し、サブネットＸとサブネットＹとの間の通信に利用されるネットワーク装置１０３（図１２の分解ルールではＩＰスイッチ）を検索する。なお、ここでは、他のサブネットとの接続を行うサブネットＸ、Ｙ内のルータ（境界ルータ）は、検索の対象とされない。なお、これらの境界ルータについては、ステップ３０１０、ステップ３０１１では検索の対象とせずに、その代わりにステップ３０１２で検索の対象としてもよい。その後、ルールローダープログラム１２２は、処理をステップ３０１３に進める。
　（ステップ３０１３）ルールローダープログラム１２２は、ＩＦ部に、分解ルール１２１３から抽出された内部条件１２２３に対応する内部条件オブジェクト（ＥａＤｉｖ１－３（ＮｅｔＺ））を生成する。なお、内部条件１２２３に対応する内部条件オブジェクト（ＥａＤｉｖ１－３（ＮｅｔＺ））がルールメモリデータに存在する場合には、対応するオブジェクトを生成しない。このように、既に存在する内部条件オブジェクを利用することができるので、ルールメモリデータのデータ量を削減することができる。例えば、この内部条件オブジェクト（ＥａＤｉｖ１－３（ＮｅｔＺ））は、サブネットＺを跨って接続された２つのサブネット間における、サービス提供装置及びサービス利用装置に関しての原因分析において共用することができる。情報処理システム１００が構成例２の場合、サブネット１とサブネット２との間には、サブネット０が介在している。従って、内部条件オブジェクト（ＥａＤｉｖ１－３（Ｎｅｔ０））が生成される（図１７の内部条件オブジェクト１７２２ｂ）。また、ルールローダープログラム１２２は、ＩＦ部の生成した内部条件オブジェクトの上流側に、ＯＲ演算子オブジェクト１６３１ｂを生成する。そして、ルールローダープログラム１２２は、上記生成したＯＲ演算子オブジェクト１６３１ｂから生成した内部条件オブジェクトへ向けた接続を生成する。その後、ルールローダープログラム１２２は、処理をステップ３０１４に進める。
　（ステップ３０１４）ルールローダープログラム１２２は、サブネットＸとサブネットＹとの間にあるネットワーク装置１０３（図１２の分解ルールではＩＰスイッチ）の各々に関係する条件に対応する条件オブジェクトを生成する。なお、条件に対応する条件オブジェクトがルールメモリデータに存在する場合には、対応するオブジェクトを生成しない。このように、既に存在する条件オブジェクトを利用することができるので、ルールメモリデータのデータ量を削減することができる。情報処理システム１００が構成例２の場合、サブネット１とサブネット２との間にはサブネット０が介在しており、サブネット０にはスイッチ２及びスイッチ３が所属している。従って、スイッチ２及びスイッチ３のそれぞれに関係する条件に対応する条件オブジェクトが生成される。そして、ルールローダープログラム１２２は、生成した条件オブジェクトの各々からステップ３００８で生成したＯＲ演算子オブジェクト１６３１ｂへ向けた接続を生成する。その後、ルールローダープログラム１２２は、処理をステップ３０１５に進める。
　＜１．３．サービス提供装置又はサービス利用装置に対応した内部条件オブジェクトの生成＞。
　（ステップ３０１５）ルールローダープログラム１２２は、分解ルール１２０１を参照して、その分解ルール１２０１に関するサービス提供装置又はサービス利用装置のうちその分解ルール１２０１においてイベントが規定されているものを特定する。情報処理システム１００が構成例２の場合、分解ルール１２０１に関するサービス提供装置又はサービス利用装置には、サーバ１、サーバ２、ストレージ２が該当するが、分解ルール１２０１においてストレージ１０２に関係するイベントは規定されていない。従って、情報処理システム１００が構成例２の場合、サーバ１及びサーバ２が特定される。
　（ステップ３０１６）ルールローダープログラム１２２は、ステップ３０１５で特定したサービス提供装置及びサービス利用装置のそれぞれに関係する条件に対応する条件オブジェクトを生成する。なお、条件に対応する条件オブジェクトがルールメモリデータに存在する場合には、対応するオブジェクトを生成しない。このように、既に存在する条件オブジェクトを利用することができるので、ルールメモリデータのデータ量を削減することができる。情報処理システム１００が構成例２の場合、サーバ１及びサーバ２のそれぞれに関係する条件に対応した条件オブジェクトが生成される。また、ルールローダープログラム１２２は、ＩＦ部の生成した条件オブジェクトの下流側に、ＡＮＤ演算子オブジェクト１６３１ａを生成する。そして、ルールローダープログラム１２２は、生成したＡＮＤ演算子オブジェクト１６３１ａから生成した条件オブジェクトへ向けた接続を生成する。その後、ルールローダープログラム１２２は、処理をステップ３０１５に進める。
　（ステップ３０１７）ルールローダープログラム１２２は、ステップ３００３で生成した集約内部条件オブジェクト（Ｅａ（ＮｅｔＸ－ＮｅｔＹ））からステップ３０１６で生成したＡＮＤ演算子オブジェクト１６３１ｂへ向けた接続を生成する。その後、ルールローダープログラム１２２は、処理をステップ３０１５に進める。
　＜２．ルールメモリデータのＴＨＥＮ部の生成＞。
　＜２．１．集約内部結論オブジェクト（Ｅａ（ＮｅｔＸ－ＮｅｔＹ））の生成＞。
　（ステップ３０１８）ルールローダープログラム１２２は、ＴＨＥＮ部にＯＲ演算子オブジェクトを生成し、ステップ３０１６で生成したＡＮＤ演算子オブジェクト１６３１ｂの各々から生成したＯＲ演算子へ向けた接続を生成する。なお、この接続の太さは、接続したＡＮＤ演算子オブジェクト１６３１ｂの入力の数である。その後、ルールローダープログラム１２２は、処理をステップ３０１９に進める。
　（ステップ３０１９）ルールローダープログラム１２２は、ＴＨＥＮ部に集約内部結論オブジェクト（Ｅａ（ＮｅｔＸ－ＮｅｔＹ））を生成する。なお、集約内部結論オブジェクト（Ｅａ（ＮｅｔＸ－ＮｅｔＹ））がルールメモリデータに存在する場合には、対応する集約内部結論オブジェクトを生成しない。このように、既に存在する集約内部結論オブジェクトを利用することができるので、ルールメモリデータのデータ量を削減することができる。情報処理システム１００が構成例２の場合、集約内部結論オブジェクト（Ｅａ（Ｎｅｔ１－Ｎｅｔ２））が生成される（図１７の集約内部結論オブジェクト１７４１）。また、ルールローダープログラム１２２は、ステップ３０１８で生成したＯＲ演算子オブジェクト１６３１ｂから生成した集約内部結論オブジェクトへ向けた接続を生成する。なお、この接続の太さは、接続したＯＲ演算子オブジェクト１６３１ｂの入力の太さと同じである。その後、ルールローダープログラム１２２は、処理をステップ３０２０に進める。
　＜２．２．内部結論オブジェクトの生成＞。
　＜２．２．１．内部結論オブジェクト（ＥａＤｉｖ１－１（ＮｅｔＸ））の生成＞。
　（ステップ３０２０）ルールローダープログラム１２２は、ＴＨＥＮ部に内部結論オブジェクト（ＥａＤｉｖ１－１（ＮｅｔＸ））を生成する。なお、内部結論オブジェクト（ＥａＤｉｖ１－１（ＮｅｔＸ））がルールメモリデータに存在する場合には、対応するオブジェクトを生成しない。このように、既に存在する内部結論オブジェクトを利用することができるので、ルールメモリデータのデータ量を削減することができる。情報処理システム１００が構成例２の場合、内部結論オブジェクト（ＥａＤｉｖ１－１（Ｎｅｔ１））が生成される（図１７の内部結論オブジェクト１７４２ａ）。また、ルールローダープログラム１２２は、ステップ３０１９で生成した集約内部結論オブジェクト（Ｅａ（ＮｅｔＸ－ＮｅｔＹ））から、生成した内部結論オブジェクトへ向けた接続を生成する。なお、この接続の太さは、接続した集約内部結論オブジェクトの入力の太さと同じである。また、この接続は、ＯＲ演算子オブジェクト１６３１ｂ又はＡＮＤ演算子オブジェクト１６３１ａを介して行われてもよい。その後、ルールローダープログラム１２２は、処理をステップ３０２１に進める。
　（ステップ３０２１）ルールローダープログラム１２２は、ステップ３００４で検索したサブネットＸ内のネットワーク装置１０３のそれぞれについて、以下のステップ３０２１－１～ステップ３０２１－４の処理を繰り返す。なお、それぞれに対して処理を終えた後、ルールローダープログラム１２２は、処理をステップ３０２２に進める。まず、ルールローダープログラム１２２は、ステップ３００４で検索したサブネットＸ内のネットワーク装置１０３のうちの一つ（以下のステップ３０２１－１～ステップ３０２１－４において「対象装置」という）を選択する。
　　　（ステップ３０２１－１）ルールローダープログラム１２２は、対象装置に関係する結論に対応する結論オブジェクト１６１２とＢＬＥＮＤ演算子オブジェクト１６３１ｃとを生成する。なお、対象装置に関係する結論に対応する結論オブジェクトがルールメモリデータに存在する場合には、対応するオブジェクトを生成しない。このように、既に存在する結論オブジェクトを利用することができるので、ルールメモリデータのデータ量を削減することができる。その後、ルールローダープログラム１２２は、処理をステップ３０２１－２に進める。
　　　（ステップ３０２１－２）ルールローダープログラム１２２は、ステップ３０２１－１で生成したＢＬＥＮＤ演算子オブジェクト１６３１ｃからステップ３０２１－１で生成した結論オブジェクトのそれぞれへ向けた接続を生成する。その後、ルールローダープログラム１２２は、処理をステップ３０２１－３に進める。
　　　（ステップ３０２１－３）ルールローダープログラム１２２は、ステップ３０２０で生成した内部結論オブジェクト（ＥａＤｉｖ１－１（ＮｅｔＸ））からステップ３０２１－１で生成したＢＬＥＮＤ演算子オブジェクト１６３１ｃの基礎入力へ向けた接続を生成する。なお、この接続の太さは、接続した内部結論オブジェクト（ＥａＤｉｖ１－１（ＮｅｔＸ））の入力の太さと同じである。その後、ルールローダープログラム１２２は、処理をステップ３０２１－４に進める。
　　　（ステップ３０２１－４）ルールローダープログラム１２２は、対象装置に関係する条件に対応する条件オブジェクトからステップ３０２１－１で生成したＢＬＥＮＤ演算子オブジェクト１６３１ｃのデルタ入力へ向けた接続を生成する。
　＜２．２．２．内部結論オブジェクト（ＥａＤｉｖ１－５（ＮｅｔＹ））の生成＞。
　（ステップ３０２２）ルールローダープログラム１２２は、ＴＨＥＮ部に内部結論オブジェクト（ＥａＤｉｖ１－５（ＮｅｔＹ））を生成する。なお、内部結論オブジェクト（ＥａＤｉｖ１－５（ＮｅｔＸ））がルールメモリデータに存在する場合には、対応するオブジェクトを生成しない。このように、既に存在する内部結論オブジェクトを利用することができるので、ルールメモリデータのデータ量を削減することができる。情報処理システム１００が構成例２の場合、内部結論オブジェクト（ＥａＤｉｖ１－５（Ｎｅｔ２））が生成される（図１７の内部結論オブジェクト１７４２ｃ）。また、ルールローダープログラム１２２は、ステップ３０１９で生成した集約内部結論オブジェクト（Ｅａ（ＮｅｔＸ－ＮｅｔＹ））から生成した内部結論オブジェクトへ向けた接続を生成する。なお、この接続の太さは、接続した集約内部結論オブジェクトの入力の太さと同じである。また、この接続は、ＯＲ演算子オブジェクト１６３１ｂ又はＡＮＤ演算子オブジェクト１６３１ａを介して行われてもよい。その後、ルールローダープログラム１２２は、処理をステップ３０２３に進める。
　（ステップ３０２３）ルールローダープログラム１２２は、ステップ３００７で検索したサブネットＹ内のネットワーク装置１０３のそれぞれについて、以下のステップ３０２３－１～ステップ３０２３－４の処理を繰り返す。なお、それぞれに対して処理を終えた後、ルールローダープログラム１２２は、処理をステップ３０２４に進める。まず、ルールローダープログラム１２２は、ステップ３００７で検索したサブネットＹ内のネットワーク装置１０３のうちの一つ（以下のステップ３０２３－１～ステップ３０２３－４において「対象装置」という）を選択する。
　　　（ステップ３０２３－１）ルールローダープログラム１２２は、対象装置に関係する結論に対応する結論オブジェクトとＢＬＥＮＤ演算子オブジェクト１６３１ｃとを生成する。その後、ルールローダープログラム１２２は、処理をステップ３０２３－２に進める。
　　　（ステップ３０２３－２）ルールローダープログラム１２２は、ステップ３０２３－１で生成したＢＬＥＮＤ演算子オブジェクト１６３１ｃから同じステップ３０２３－１で生成した結論オブジェクトのそれぞれへ向けた接続を生成する。その後、ルールローダープログラム１２２は、処理をステップ３０２３－３に進める。
　　　（ステップ３０２３－３）ルールローダープログラム１２２は、ステップ３０２２で生成した内部結論オブジェクト（ＥａＤｉｖ１－５（ＮｅｔＹ））からステップ３０２３－１で生成したＢＬＥＮＤ演算子オブジェクト１６３１ｃの基礎入力へ向けた接続を生成する。なお、この接続の太さは、接続した内部結論オブジェクト（ＥａＤｉｖ１－５（ＮｅｔＹ））の入力の太さと同じである。その後、ルールローダープログラム１２２は、処理をステップ３０２３－４に進める。
　　　（ステップ３０２３－４）ルールローダープログラム１２２は、対象装置に関係する条件に対応する条件オブジェクトからステップ３０２３－１で生成したＢＬＥＮＤ演算子オブジェクト１６３１ｃのデルタ入力へ向けた接続を生成する。
　＜２．２．３．サブネットＸの境界ルータ関係＞。
　（ステップ３０２４）ルールローダープログラム１２２は、ステップ３０１０で検索した境界ルータのそれぞれについて、以下のステップ３０２４－１～ステップ３０２４－４の処理を繰り返す。なお、それぞれに対して処理を終えた後、ルールローダープログラム１２２は、処理をステップ３０２５に進める。まず、ルールローダープログラム１２２は、ステップ３０１０で検索した境界ルータのうちの一つ（以下のステップ３０２４－１～ステップ３０２４－４において「対象装置」という）を選択する。
　　　（ステップ３０２４－１）ルールローダープログラム１２２は、対象装置に関係する結論に対応する結論オブジェクトとＢＬＥＮＤ演算子オブジェクト１６３１ｃとを生成する。その後、ルールローダープログラム１２２は、処理をステップ３０２４－１に進める。
　　　（ステップ３０２４－２）ルールローダープログラム１２２は、ステップ３０２４－１で生成したＢＬＥＮＤ演算子オブジェクト１６３１ｃからステップ３０２４－１で生成した結論オブジェクトのそれぞれへ向けた接続を生成する。その後、ルールローダープログラム１２２は、処理をステップ３０２４－３に進める。
　　　（ステップ３０２４－３）ルールローダープログラム１２２は、ステップ３０１９で生成した集約内部結論オブジェクト（Ｅａ（ＮｅｔＸ－ＮｅｔＹ））からステップ３０２４－１で生成したＢＬＥＮＤ演算子オブジェクト１６３１ｃの基礎入力へ向けた接続を生成する。なお、この接続の太さは、接続した集約内部結論オブジェクト（Ｅａ（ＮｅｔＸ－ＮｅｔＹ））の入力の太さと同じである。その後、ルールローダープログラム１２２は、処理をステップ３０２４－４に進める。
　　　（ステップ３０２４－４）ルールローダープログラム１２２は、対象装置に関係する条件に対応する条件オブジェクトからステップ３０２４－１で生成したＢＬＥＮＤ演算子オブジェクト１６３１ｃのデルタ入力へ向けた接続を生成する。
　＜２．２．４．サブネットＹの境界ルータ関係＞。
　（ステップ３０２５）ルールローダープログラム１２２は、ステップ３０１１で検索した境界ルータのそれぞれについて、以下のステップ３０２５－１～ステップ３０２５－４の処理を繰り返す。なお、それぞれに対して処理を終えた後、ルールローダープログラム１２２は、処理をステップ３０２６に進める。まず、ルールローダープログラム１２２は、ステップ３０１１で検索した境界ルータのうちの一つ（以下のステップ３０２５－１～ステップ３０２５－４において「対象装置」という）を選択する。
　　　（ステップ３０２５－１）ルールローダープログラム１２２は、対象装置に関係する結論に対応する結論オブジェクトとＢＬＥＮＤ演算子オブジェクト１６３１ｃとを生成する。その後、ルールローダープログラム１２２は、処理をステップ３０２５－２に進める。
　　　（ステップ３０２５－２）ルールローダープログラム１２２は、ステップ３０２５－１で生成したＢＬＥＮＤ演算子オブジェクト１６３１ｃからステップ３０２５－１で生成した結論オブジェクトのそれぞれへ向けた接続を生成する。その後、ルールローダープログラム１２２は、処理をステップ３０２５－３に進める。
　　　（ステップ３０２５－３）ルールローダープログラム１２２は、ステップ３０１９で生成した集約内部結論オブジェクト（Ｅａ（ＮｅｔＸ－ＮｅｔＹ））からステップ３０２５－１で生成したＢＬＥＮＤ演算子オブジェクト１６３１ｃの基礎入力へ向けた接続を生成する。なお、この接続の太さは、接続した集約内部結論オブジェクト（Ｅａ（ＮｅｔＸ－ＮｅｔＹ））の入力の太さと同じである。その後、ルールローダープログラム１２２は、処理をステップ３０２５－４に進める。
　　　（ステップ３０２５－４）ルールローダープログラム１２２は、対象装置に関係する条件に対応する条件オブジェクトからステップ３０２５－１で生成したＢＬＥＮＤ演算子オブジェクト１６３１ｃのデルタ入力へ向けた接続を生成する。
　＜２．２．５．内部結論オブジェクト（ＥａＤｉｖ１－３（ＮｅｔＺ））の生成＞。
　（ステップ３０２６）ルールローダープログラム１２２は、ＴＨＥＮ部に内部結論オブジェクト（ＥａＤｉｖ１－３（ＮｅｔＺ））を生成する。なお、内部結論オブジェクト（ＥａＤｉｖ１－３（ＮｅｔＺ））がルールメモリデータに存在する場合には、対応するオブジェクトを生成しない。このように、既に存在する内部結論オブジェクトを利用することができるので、ルールメモリデータのデータ量を削減することができる。情報処理システム１００が構成例２の場合、内部結論オブジェクト（ＥａＤｉｖ１－３（Ｎｅｔ０））が生成される（図１７の内部結論オブジェクト１７４２ｂ）。また、ルールローダープログラム１２２は、ステップ３０１９で生成した集約内部結論オブジェクト（Ｅａ（ＮｅｔＸ－ＮｅｔＹ））から生成した内部結論オブジェクトへ向けた接続を生成する。なお、この接続の太さは、接続した集約内部結論オブジェクトの入力の太さと同じである。また、この接続は、ＯＲ演算子オブジェクト１６３１ｂ又はＡＮＤ演算子オブジェクト１６３１ａを介して行われてもよい。その後、ルールローダープログラム１２２は、処理をステップ３０２７に進める。
　（ステップ３０２７）ルールローダープログラム１２２は、ステップ３０１２で検索したサブネットＸとサブネットＹとの間にあるネットワーク装置１０３のそれぞれについて、以下のステップ３０２７－１～ステップ３０２７－４の処理を繰り返す。なお、それぞれに対して処理を終えた後、ルールローダープログラム１２２は、処理をステップ３０２８に進める。まず、ルールローダープログラム１２２は、ステップ３０１２で検索したサブネットＸとサブネットＹとの間にあるネットワーク装置１０３のうちの一つ（以下のステップ３０２７－１～ステップ３０２７－４において「対象装置」という）を選択する。
　　　（ステップ３０２７－１）ルールローダープログラム１２２は、対象装置に関係する結論に対応する結論オブジェクトとＢＬＥＮＤ演算子オブジェクト１６３１ｃとを生成する。その後、ルールローダープログラム１２２は、処理をステップ３０２７－２に進める。
　　　（ステップ３０２７－２）ルールローダープログラム１２２は、ステップ３０２７－１で生成したＢＬＥＮＤ演算子オブジェクト１６３１ｃからステップ３０２７－１で生成した結論オブジェクトのそれぞれへ向けた接続を生成する。その後、ルールローダープログラム１２２は、処理をステップ３０２７－３に進める。
　　　（ステップ３０２７－３）ルールローダープログラム１２２は、ステップ３０２６で生成した内部結論オブジェクト（ＥａＤｉｖ１－３（ＮｅｔＺ））からステップ３０２７－１で生成したＢＬＥＮＤ演算子オブジェクト１６３１ｃの基礎入力へ向けた接続を生成する。なお、この接続の太さは、接続した内部結論オブジェクト（ＥａＤｉｖ１－３（ＮｅｔＺ））の入力の太さと同じである。その後、ルールローダープログラム１２２は、処理をステップ３０２７－４に進める。
　　　（ステップ３０２７－４）ルールローダープログラム１２２は、対象装置に関係する条件に対応する条件オブジェクトからステップ３０２７－１で生成したＢＬＥＮＤ演算子オブジェクト１６３１ｃのデルタ入力へ向けた接続を生成する。
　（ステップ３０２８）ルールローダープログラム１２２は、ループ１を終了する。
　次に、マッチング率計算処理について説明する。
　マッチング率計算処理は、マッチング率評価プログラム１２５により行われる。図１６及び図１７を参照して説明したとおり、ルールメモリデータに含まれる各オブジェクトは、ソースオブジェクトからの出力に応じた値を出力する。条件オブジェクトが真（１）を出力することを契機に、その条件オブジェクトの出力は、オブジェクトの接続関係を辿って下流側へ流れる。出力が最終的に結論オブジェクトに至ることで、その結論オブジェクトの出力が、マッチング率になる。例えば、或る条件オブジェクトが真（１）を新たに出力することを契機に、マッチング率評価プログラム１２５は、以下の再帰的処理を行う。
　（ステップ４００１）マッチング率評価プログラム１２５は、出力値が変化した条件オブジェクトのターゲットオブジェクト（下流側に接続されたオブジェクトであり、以下「オブジェクトＡ」という）を特定する。その後、マッチング率評価プログラム１２５は、処理をステップ４００２に進める。
　（ステップ４００２）マッチング率評価プログラム１２５は、オブジェクトＡの各々について、オブジェクトの種類に従った処理を行い、新たな出力値を生成する。その後、マッチング率評価プログラム１２５は、処理をステップ４００３に進める。
　（ステップ４００３）マッチング率評価プログラム１２５は、新たな出力値を生成したオブジェクトＡのターゲットオブジェクト（以下「オブジェクトＢ」）を特定する。もし、オブジェクトＢが結論オブジェクトならば、マッチング率評価プログラム１２５は、当該新たな出力値をマッチング率として保存する。オブジェクトＢが結論オブジェクト以外のオブジェクトであれば、マッチング率評価プログラム１２５は、オブジェクトＢを「オブジェクトＡの各々」としてステップ４００２の処理を行う。
　以上の処理により、イベント検知によって真（１）となったイベントに関係する条件オブジェクトから、マッチング率の計算が開始される。なお、所定の時間経過によってある条件イベントの出力が真（１）から未検知を意味する０に変更された場合も、上記と同様の処理を行うことでマッチング率を再計算することができる。ただし、各オブジェクトの実行は、上記によらず他の方法で制御されても構わない。
　このように、マッチング率が計算された後に、マッチング率評価プログラム１２５は、例えば、ルールメモリデータから、マッチング率が所定の値を超えている結論オブジェクト１６１２を検出し、当該結論オブジェクト１６１２が管理する結論のイベントを、根本原因と特定し、当該根本原因を示す情報を、例えば、入出力デバイス１１４を介して、ディスプレイ１１７に表示出力させる。なお、根本原因のイベントを示す情報を、他の装置に出力（送信）して、他の装置において表示させるようにしてもよい。
　なお、一般ルールは、結論に含まれるイベントが発生した場合は、条件に含まれるイベントも必ず発生することを意味している。しかし、こうした影響を受けるノード装置からは必ずしもイベント検知ができるとは限らない。しかし、本実施形態のルールメモリデータで影響ノード装置を監視コンピュータで求める場合は、Ａｇｇｒｅｇａｔｅイベント（Ｅａ（ＮｅｔＸ－ＮｅｔＹ））によって影響範囲をたどることが難しくなる。そのため、ＣＰＵ１１１が、指定されたノード装置とイベント種別とをキーに、該当する一般ルールを検索することで対応する条件イベント（つまり影響を受けるノード装置を示す）を特定し、記憶資源１１２に一時生成するようにして、例えば、ディスプレイ装置１１７に表示するようにしてもよい。
　図２１は、イベント受信処理のフローチャートである。
　（ステップ２１０１）イベント受信プログラム１２３は、監視対象装置（具体的には、監視対象装置内の監視エージェント１４１、１６６）からイベントメッセージ１４０１を受信する。
　（ステップ２１０２）イベント受信プログラム１２３は、ステップ２１０１で受信したイベントメッセージ１４０１から監視対象名１４１１及びイベントタイプ１４１２を取得し、取得した情報１４１１、１４１２に監視対象タイプ及び受信日時を加えてイベント情報１５１１を作成する。そして、イベント受信プログラム１２３は、その作成したイベント情報１５１１をイベントキューテーブル１３４に追加して、処理を終了する。
　図２２は、イベント書込処理のフローチャートである。
　（ステップ２２０１）イベント書込プログラム１２４は、イベントキューテーブル１３４からイベント情報１５１１を一つ取得する。
　（ステップ２２０２）イベント書込プログラム１２４は、ステップ２２０１で取得したイベント情報１５１１から監視対象タイプ１５０１、監視対象名１５０２及びイベントタイプ１５０３を取得する。
　（ステップ２２０３）その後、イベント書込プログラム１２４は、ステップ２２０２で取得した監視対象名１５０２及びイベントタイプ１５０３をキーに、ルールメモリデータを検索し、監視対象名１５０２及びイベントタイプ１５０３が一致する条件オブジェクトを特定する。そして、イベント書込プログラム１２４は、特定した条件オブジェクトの出力値を真（すなわち１）とし、処理を終了する。なお、このようにオブジェクトの出力値が変更されると、上記したマッチング率計算処理が実行されることとなる。
　以上、実施形態を説明したが、本発明は、この実施形態に限定されるものでなく、その趣旨を逸脱しない範囲で種々変更可能であることはいうまでもない。例えば、監視コンピュータ１０１がネットワーク装置、例えば、スイッチにより構成されてもよい。
　１０１：監視コンピュータ、１０２：サーバ、１０３：ネットワーク装置、１０４：ストレージ。

Claims (9)

  1. 　複数のサブネットワークを構成する複数のネットワーク装置と、
    　前記複数のサブネットワークに属する複数のノード装置と、
    　発生した事象の原因を特定するコンピュータと
    を有し、
    　前記コンピュータは、
    　記憶資源と、前記記憶資源に接続された制御デバイスと、を有し、
    　前記記憶資源は、１以上のルールと、前記ネットワーク装置及び前記ノード装置がどのサブネットワークに所属するかを表したサブネットワーク情報とを記憶し、
    　各ルールは、一端のノード装置と他端のノード装置とそれらを中継するネットワーク装置とを含んだトポロジに関するトポロジ情報と、そのトポロジにおける事象を示す条件と、その条件を満たす原因となる事象を示す結論と、を含み、
    　（Ａ）前記制御デバイスは、以下の（ａ１）～（ａ１３）を行うことにより、ルールメモリデータを生成して前記記憶資源に格納し、
    （ａ１）前記サブネットワーク情報に基づいて、或る第１のサブネットワークにおける１以上のネットワーク装置を特定し、当該ネットワーク装置による前記ルールの前記条件となる事象の発生情報を管理する１以上の第１の条件オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記１以上の第１の条件オブジェクトを前記ルールメモリデータに含め、
    （ａ２）１以上の前記第１の条件オブジェクトの全ての事象の発生情報を集約するための第１の内部条件オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記第１の内部条件オブジェクトを前記ルールメモリデータに含め、
    （ａ３）前記第１の内部条件オブジェクトを前記第１の条件オブジェクトに関連付け、
    （ａ４）前記サブネットワーク情報に基づいて、或る第２のサブネットワークにおける１以上のネットワーク装置を特定し、当該ネットワーク装置による前記ルールの前記条件となる事象の発生情報を管理する１以上の第２の条件オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記１以上の第２の条件オブジェクトを前記ルールメモリデータに含め、
    （ａ５）１以上の前記第２の条件オブジェクトの全てからの事象の発生情報を集約する第２の内部条件オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記２の内部条件オブジェクトを前記ルールメモリデータに含め、
    （ａ６）前記第２の内部条件オブジェクトを前記第２の条件オブジェクトに関連付け、
    （ａ７）前記第１の内部条件オブジェクト、前記第２の内部条件オブジェクトの事象の発生情報を集約した集約情報を管理する集約内部条件オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記集約内部条件オブジェクトを前記ルールメモリデータに含め、
    （ａ８）前記集約内部条件オブジェクトを、前記第１及び第２の内部条件オブジェクトに関連付け、
    （ａ９）前記サブネットワーク情報に基づいて、前記第１のサブネットワークにおける複数のノード装置を特定し、当該ノード装置による前記ルールの前記条件となる事象の発生情報を管理する複数の第３の条件オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記複数の第３の条件オブジェクトを、前記ルールメモリデータに含め、
    （ａ１０）前記集約内部条件オブジェクトの集約情報と、前記第３の条件オブジェクトの事象の前記発生情報とに基づいた、条件を判定するための判定情報を管理する集約内部結論オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記集約内部結論オブジェクトを前記ルールメモリデータに含め、
    （ａ１１）前記集約内部結論オブジェクトを、前記集約内部条件オブジェクト及び前記第３の条件オブジェクトに関連付け、
    （ａ１２）前記第１のサブネットワークにおけるネットワーク装置、及び前記第２のサブネットワークのネットワーク装置のそれぞれで発生する事象を示す結論が原因である可能性を示す指標を管理する複数の結論オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記複数の結論オブジェクトを前記ルールメモリデータに含め、
    （ａ１３）複数の前記結論オブジェクトを前記集約内部結論オブジェクトに関連付け、
    　（Ｂ）前記制御デバイスは、前記複数のネットワーク装置又は前記複数のノード装置における事象の発生情報を受信し、前記ルールメモリデータに基づいて、前記受信した発生情報を管理する条件オブジェクトを特定し、特定した前記条件オブジェクトの管理する事象の前記発生情報を更新するとともに、前記条件オブジェクトに対する関連付けを辿って、前記発生情報の更新の影響が及ぶ各オブジェクトの管理する情報を更新していくことにより、前記結論オブジェクトの前記指標を更新し、更新した結論オブジェクトの前記指標に基づいて、事象の原因を特定し出力する、
    情報システム。
  2. 　請求項１において、
    　前記第１のサブネットワークと、前記第２のサブネットワークとの間には、第３のサブネットワークが介在しており、
    　前記制御デバイスは、前記（Ａ）において、さらに、以下の（ａ１４）～（ａ１６）を実行し、
    （ａ１４）前記サブネットワーク情報に基づいて、前記第３のサブネットワークにおける１以上のネットワーク装置による前記ルールの前記条件となる事象の発生情報を管理する１以上の第４の条件オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記１以上の第４の条件オブジェクトを前記ルールメモリデータに含め、
    （ａ１５）１以上の前記第４の条件オブジェクトの全ての事象の前記発生情報を集約するための第３の内部条件オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記第３の内部条件オブジェクトを前記ルールメモリデータに含め、
    （ａ１６）前記第３の内部条件オブジェクトを前記第４の条件オブジェクトに関連付け、
    　前記（ａ７）において生成された集約内部条件オブジェクトは、前記第１の内部条件オブジェクト、前記第２の内部条件オブジェクト、及び前記第３の内部条件オブジェクトの事象の発生情報を集約した集約情報を管理するオブジェクトであり、
    　前記（ａ８）において、前記制御デバイスは、前記集約内部条件オブジェクトを、前記第１、第２及び第３の内部条件オブジェクトに関連付ける、
    情報システム。
  3. 　請求項２において、
    　前記結論オブジェクトの前記指標は、前記結論オブジェクトに対応する事象の発生情報を管理する条件オブジェクトの事象の発生情報と、前記集約内部結論オブジェクトの前記判定情報とに基づいて、決定される、
    情報システム。
  4. 　複数のサブネットワークを構成する複数のネットワーク装置と前記複数のサブネットワークに属する複数のノード装置とを有する情報システムにおいて発生した事象の原因を特定するコンピュータであって、
    　記憶資源と、
    　前記記憶資源に接続された制御デバイスと
    を有し、
    　前記記憶資源は、１以上のルールと、前記ネットワーク装置及び前記ノード装置がどのサブネットワークに所属するかを表したサブネットワーク情報とを記憶し、
    　各ルールは、一端のノード装置と他端のノード装置とそれらを中継するネットワーク装置とを含んだトポロジに関するトポロジ情報と、そのトポロジにおける事象を示す条件と、その条件を満たす原因となる事象を示す結論と、を含み、
    　（Ａ）前記制御デバイスは、以下の（ａ１）～（ａ１３）を行うことにより、ルールメモリデータを生成して前記記憶資源に格納し、
    （ａ１）前記サブネットワーク情報に基づいて、或る第１のサブネットワークにおける１以上のネットワーク装置を特定し、当該ネットワーク装置による前記ルールの前記条件となる事象の発生情報を管理する１以上の第１の条件オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記１以上の第１の条件オブジェクトを前記ルールメモリデータに含め、
    （ａ２）１以上の前記第１の条件オブジェクトの全ての事象の発生情報を集約するための第１の内部条件オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記第１の内部条件オブジェクトを前記ルールメモリデータに含め、
    （ａ３）前記第１の内部条件オブジェクトを前記第１の条件オブジェクトに関連付け、
    （ａ４）前記サブネットワーク情報に基づいて、或る第２のサブネットワークにおける１以上のネットワーク装置を特定し、当該ネットワーク装置による前記ルールの前記条件となる事象の発生情報を管理する１以上の第２の条件オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記１以上の第２の条件オブジェクトを前記ルールメモリデータに含め、
    （ａ５）１以上の前記第２の条件オブジェクトの全てからの事象の発生情報を集約する第２の内部条件オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記２の内部条件オブジェクトを前記ルールメモリデータに含め、
    （ａ６）前記第２の内部条件オブジェクトを前記第２の条件オブジェクトに関連付け、
    （ａ７）前記第１の内部条件オブジェクト、前記第２の内部条件オブジェクトの事象の発生情報を集約した集約情報を管理する集約内部条件オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記集約内部条件オブジェクトを前記ルールメモリデータに含め、
    （ａ８）前記集約内部条件オブジェクトを、前記第１及び第２の内部条件オブジェクトに関連付け、
    （ａ９）前記サブネットワーク情報に基づいて、前記第１のサブネットワークにおける複数のノード装置を特定し、当該ノード装置による前記ルールの前記条件となる事象の発生情報を管理する複数の第３の条件オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記複数の第３の条件オブジェクトを、前記ルールメモリデータに含め、
    （ａ１０）前記集約内部条件オブジェクトの集約情報と、前記第３の条件オブジェクトの事象の前記発生情報とに基づいた、条件を判定するための判定情報を管理する集約内部結論オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記集約内部結論オブジェクトを前記ルールメモリデータに含め、
    （ａ１１）前記集約内部結論オブジェクトを、前記集約内部条件オブジェクト及び前記第３の条件オブジェクトに関連付け、
    （ａ１２）前記第１のサブネットワークにおけるネットワーク装置、及び前記第２のサブネットワークのネットワーク装置のそれぞれで発生する事象を示す結論が原因である可能性を示す指標を管理する複数の結論オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記複数の結論オブジェクトを前記ルールメモリデータに含め、
    （ａ１３）複数の前記結論オブジェクトを前記集約内部結論オブジェクトに関連付け、
    　（Ｂ）前記制御デバイスは、前記複数のネットワーク装置又は前記複数のノード装置における事象の発生情報を受信し、前記ルールメモリデータに基づいて、前記受信した発生情報を管理する条件オブジェクトを特定し、特定した前記条件オブジェクトの管理する事象の前記発生情報を更新するとともに、前記条件オブジェクトに対する関連付けを辿って、前記発生情報の更新の影響が及ぶ各オブジェクトの管理する情報を更新していくことにより、前記結論オブジェクトの前記指標を更新し、更新した結論オブジェクトの前記指標に基づいて、事象の原因を特定し出力する、
    コンピュータ。
  5. 　請求項４において、
    　前記第１のサブネットワークと、前記第２のサブネットワークとの間には、第３のサブネットワークが介在しており、
    　前記制御デバイスは、前記（Ａ）において、さらに、以下の（ａ１４）～（ａ１６）を実行し、
    （ａ１４）前記サブネットワーク情報に基づいて、前記第３のサブネットワークにおける１以上のネットワーク装置による前記ルールの前記条件となる事象の発生情報を管理する１以上の第４の条件オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記１以上の第４の条件オブジェクトを前記ルールメモリデータに含め、
    （ａ１５）１以上の前記第４の条件オブジェクトの全ての事象の前記発生情報を集約するための第３の内部条件オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記第３の内部条件オブジェクトを前記ルールメモリデータに含め、
    （ａ１６）前記第３の内部条件オブジェクトを前記第４の条件オブジェクトに関連付け、
    　前記（ａ７）において生成された集約内部条件オブジェクトは、前記第１の内部条件オブジェクト、前記第２の内部条件オブジェクト、及び前記第３の内部条件オブジェクトの事象の発生情報を集約した集約情報を管理するオブジェクトであり、
    　前記（ａ８）において、前記制御デバイスは、前記集約内部条件オブジェクトを、前記第１、第２及び第３の内部条件オブジェクトに関連付ける、
    コンピュータ。
  6. 　請求項４において、
    　前記結論オブジェクトの前記指標は、前記結論オブジェクトに対応する事象の発生情報を管理する条件オブジェクトの事象の発生情報と、前記集約内部結論オブジェクトの前記判定情報とに基づいて、決定される、
    コンピュータ。
  7. 　複数のサブネットワークを構成する複数のネットワーク装置と前記複数のサブネットワークに属する複数のノード装置とを有する情報システムにおいて発生した事象の原因を特定する方法であって、
    　（Ａ）コンピュータが、以下の（ａ１）～（ａ１３）を行うことにより、ルールメモリデータを生成して、１以上のルールとサブネットワーク情報とを記憶する記憶資源に格納し、各ルールは、一端のノード装置と他端のノード装置とそれらを中継するネットワーク装置とを含んだトポロジに関するトポロジ情報と、そのトポロジにおける事象を示す条件と、その条件を満たす原因となる事象を示す結論と、を含み、前記サブネットワーク情報は、前記ネットワーク装置及び前記ノード装置がどのサブネットワークに所属するかを表し、
    （ａ１）前記サブネットワーク情報に基づいて、或る第１のサブネットワークにおける１以上のネットワーク装置を特定し、当該ネットワーク装置による前記ルールの前記条件となる事象の発生情報を管理する１以上の第１の条件オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記１以上の第１の条件オブジェクトを前記ルールメモリデータに含め、
    （ａ２）１以上の前記第１の条件オブジェクトの全ての事象の発生情報を集約するための第１の内部条件オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記第１の内部条件オブジェクトを前記ルールメモリデータに含め、
    （ａ３）前記第１の内部条件オブジェクトを前記第１の条件オブジェクトに関連付け、
    （ａ４）前記サブネットワーク情報に基づいて、或る第２のサブネットワークにおける１以上のネットワーク装置を特定し、当該ネットワーク装置による前記ルールの前記条件となる事象の発生情報を管理する１以上の第２の条件オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記１以上の第２の条件オブジェクトを前記ルールメモリデータに含め、
    （ａ５）１以上の前記第２の条件オブジェクトの全てからの事象の発生情報を集約する第２の内部条件オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記２の内部条件オブジェクトを前記ルールメモリデータに含め、
    （ａ６）前記第２の内部条件オブジェクトを前記第２の条件オブジェクトに関連付け、
    （ａ７）前記第１の内部条件オブジェクト、前記第２の内部条件オブジェクトの事象の発生情報を集約した集約情報を管理する集約内部条件オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記集約内部条件オブジェクトを前記ルールメモリデータに含め、
    （ａ８）前記集約内部条件オブジェクトを、前記第１及び第２の内部条件オブジェクトに関連付け、
    （ａ９）前記サブネットワーク情報に基づいて、前記第１のサブネットワークにおける複数のノード装置を特定し、当該ノード装置による前記ルールの前記条件となる事象の発生情報を管理する複数の第３の条件オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記複数の第３の条件オブジェクトを、前記ルールメモリデータに含め、
    （ａ１０）前記集約内部条件オブジェクトの集約情報と、前記第３の条件オブジェクトの事象の前記発生情報とに基づいた、条件を判定するための判定情報を管理する集約内部結論オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記集約内部結論オブジェクトを前記ルールメモリデータに含め、
    （ａ１１）前記集約内部結論オブジェクトを、前記集約内部条件オブジェクト及び前記第３の条件オブジェクトに関連付け、
    （ａ１２）前記第１のサブネットワークにおけるネットワーク装置、及び前記第２のサブネットワークのネットワーク装置のそれぞれで発生する事象を示す結論が原因である可能性を示す指標を管理する複数の結論オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記複数の結論オブジェクトを前記ルールメモリデータに含め、
    （ａ１３）複数の前記結論オブジェクトを前記集約内部結論オブジェクトに関連付け、
    　（Ｂ）前記コンピュータは、前記複数のネットワーク装置又は前記複数のノード装置における事象の発生情報を受信し、前記ルールメモリデータに基づいて、前記受信した発生情報を管理する条件オブジェクトを特定し、特定した前記条件オブジェクトの管理する事象の前記発生情報を更新するとともに、前記条件オブジェクトに対する関連付けを辿って、前記発生情報の更新の影響が及ぶ各オブジェクトの管理する情報を更新していくことにより、前記結論オブジェクトの前記指標を更新し、更新した結論オブジェクトの前記指標に基づいて、事象の原因を特定し出力する、
    方法。
  8. 　請求項７において、
    　前記第１のサブネットワークと、前記第２のサブネットワークとの間には、第３のサブネットワークが介在しており、
    　前記コンピュータは、前記（Ａ）において、さらに、以下の（ａ１４）～（ａ１６）を実行し、
    （ａ１４）前記サブネットワーク情報に基づいて、前記第３のサブネットワークにおける１以上のネットワーク装置による前記ルールの前記条件となる事象の発生情報を管理する１以上の第４の条件オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記１以上の第４の条件オブジェクトを前記ルールメモリデータに含め、
    （ａ１５）１以上の前記第４の条件オブジェクトの全ての事象の前記発生情報を集約するための第３の内部条件オブジェクトを、前記ルールメモリデータに存在しない場合に生成し、生成した前記第３の内部条件オブジェクトを前記ルールメモリデータに含め、
    （ａ１６）前記第３の内部条件オブジェクトを前記第４の条件オブジェクトに関連付け、
    　前記（ａ７）において生成された集約内部条件オブジェクトは、前記第１の内部条件オブジェクト、前記第２の内部条件オブジェクト、及び前記第３の内部条件オブジェクトの事象の発生情報を集約した集約情報を管理するオブジェクトであり、
    　前記（ａ８）において、前記コンピュータは、前記集約内部条件オブジェクトを、前記第１、第２及び第３の内部条件オブジェクトに関連付ける、
    方法。
  9. 　請求項７において、
    　前記結論オブジェクトの前記指標は、前記結論オブジェクトに対応する事象の発生情報を管理する条件オブジェクトの事象の発生情報と、前記集約内部結論オブジェクトの前記判定情報とに基づいて、決定される、
    方法。 
PCT/JP2012/050114 2012-01-05 2012-01-05 事象の原因を特定する情報システム、コンピュータ及び方法 WO2013103008A1 (ja)

Priority Applications (2)

Application Number Priority Date Filing Date Title
PCT/JP2012/050114 WO2013103008A1 (ja) 2012-01-05 2012-01-05 事象の原因を特定する情報システム、コンピュータ及び方法
US13/580,753 US20130179563A1 (en) 2012-01-05 2012-01-05 Information system, computer and method for identifying cause of phenomenon

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2012/050114 WO2013103008A1 (ja) 2012-01-05 2012-01-05 事象の原因を特定する情報システム、コンピュータ及び方法

Publications (1)

Publication Number Publication Date
WO2013103008A1 true WO2013103008A1 (ja) 2013-07-11

Family

ID=48744740

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2012/050114 WO2013103008A1 (ja) 2012-01-05 2012-01-05 事象の原因を特定する情報システム、コンピュータ及び方法

Country Status (2)

Country Link
US (1) US20130179563A1 (ja)
WO (1) WO2013103008A1 (ja)

Families Citing this family (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
CN111708677B (zh) * 2020-06-19 2023-07-07 浪潮云信息技术股份公司 一种云计算环境下的云硬盘使用量采集方法

Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009153901A1 (en) * 2008-06-17 2009-12-23 Hitachi, Ltd. Method and apparatus for performing root cause analysis
JP2011198262A (ja) * 2010-03-23 2011-10-06 Hitachi Ltd 計算機システムにおけるシステム管理方法、及び管理システム

Family Cites Families (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US7043661B2 (en) * 2000-10-19 2006-05-09 Tti-Team Telecom International Ltd. Topology-based reasoning apparatus for root-cause analysis of network faults
US7269757B2 (en) * 2003-07-11 2007-09-11 Reflectent Software, Inc. Distributed computer monitoring system and methods for autonomous computer management
US7668953B1 (en) * 2003-11-13 2010-02-23 Cisco Technology, Inc. Rule-based network management approaches
US7733788B1 (en) * 2004-08-30 2010-06-08 Sandia Corporation Computer network control plane tampering monitor
US20060271677A1 (en) * 2005-05-24 2006-11-30 Mercier Christina W Policy based data path management, asset management, and monitoring
CA2926677C (en) * 2007-09-26 2020-07-14 Nicira, Inc. Network operating system for managing and securing networks
WO2013086204A1 (en) * 2011-12-07 2013-06-13 Citrix Systems, Inc. Controlling a network interface using virtual switch proxying

Patent Citations (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2009153901A1 (en) * 2008-06-17 2009-12-23 Hitachi, Ltd. Method and apparatus for performing root cause analysis
JP2011198262A (ja) * 2010-03-23 2011-10-06 Hitachi Ltd 計算機システムにおけるシステム管理方法、及び管理システム

Also Published As

Publication number Publication date
US20130179563A1 (en) 2013-07-11

Similar Documents

Publication Publication Date Title
JP6307453B2 (ja) リスク評価システムおよびリスク評価方法
US10313183B2 (en) Network function virtualization NFV fault management apparatus, device, and method
US9294338B2 (en) Management computer and method for root cause analysis
US7552447B2 (en) System and method for using root cause analysis to generate a representation of resource dependencies
US9329924B2 (en) Monitoring system and monitoring program
EP3327637B1 (en) On-demand fault reduction framework
JP6208770B2 (ja) イベントの根本原因の解析を支援する管理システム及び方法
JP5698429B2 (ja) 構成要素を管理するためのコンピュータ・システム、並びにその方法及びコンピュータ・プログラム
US9246777B2 (en) Computer program and monitoring apparatus
US20200059396A1 (en) Correlating computing network events
JP6160064B2 (ja) 適用判定プログラム、障害検出装置および適用判定方法
WO2003005200A1 (en) Method and system for correlating and determining root causes of system and enterprise events
JP2016091402A (ja) リスク評価システムおよびリスク評価方法
US20230040635A1 (en) Graph-based impact analysis of misconfigured or compromised cloud resources
US9021078B2 (en) Management method and management system
JP2012003406A (ja) 障害原因判定ルール検証装置及びプログラム
JP2010128597A (ja) 情報処理装置及び情報処理装置の運用方法
US11218357B1 (en) Aggregation of incident data for correlated incidents
WO2013103008A1 (ja) 事象の原因を特定する情報システム、コンピュータ及び方法
JP5239072B2 (ja) 構成要素を管理するためのコンピュータ・システム、並びにその方法及びコンピュータ・プログラム
JP2017211806A (ja) 通信の監視方法、セキュリティ管理システム及びプログラム
WO2015019488A1 (ja) 管理システム及びその管理システムによるイベント解析方法
JP2019009726A (ja) 障害切り分け方法および管理サーバ
JP6926646B2 (ja) 事業者間一括サービス管理装置および事業者間一括サービス管理方法
JP5938495B2 (ja) 根本原因を解析する管理計算機、方法及び計算機システム

Legal Events

Date Code Title Description
WWE Wipo information: entry into national phase

Ref document number: 13580753

Country of ref document: US

121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 12864200

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 12864200

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP