WO2011007394A1 - 障害の根本原因に対応した復旧方法を表す情報を出力する管理システム - Google Patents

障害の根本原因に対応した復旧方法を表す情報を出力する管理システム Download PDF

Info

Publication number
WO2011007394A1
WO2011007394A1 PCT/JP2009/003358 JP2009003358W WO2011007394A1 WO 2011007394 A1 WO2011007394 A1 WO 2011007394A1 JP 2009003358 W JP2009003358 W JP 2009003358W WO 2011007394 A1 WO2011007394 A1 WO 2011007394A1
Authority
WO
WIPO (PCT)
Prior art keywords
event
information
rule
meta
failure history
Prior art date
Application number
PCT/JP2009/003358
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 JP2011522628A priority Critical patent/JP5385982B2/ja
Priority to PCT/JP2009/003358 priority patent/WO2011007394A1/ja
Priority to US12/529,522 priority patent/US8429453B2/en
Priority to EP09847293A priority patent/EP2455863A4/en
Priority to CN200980160965.4A priority patent/CN102473129B/zh
Publication of WO2011007394A1 publication Critical patent/WO2011007394A1/ja
Priority to US13/845,992 priority patent/US9189319B2/en

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079—Root cause analysis, i.e. error or fault diagnosis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0748—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a remote unit communicating with a single-box computer node experiencing an error/fault
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3055—Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/32—Monitoring with visual or acoustical indication of the functioning of the machine
    • G06F11/324—Display of status information
    • G06F11/327—Alarm or error message display

Definitions

  • the present invention relates to output of information representing a recovery method from a failure.
  • Patent Document 1 As a system for supporting specification of a recovery method, for example, there is a failure history database system disclosed in Patent Document 1.
  • the system administrator registers the failure that has occurred in the monitoring target node and the method of actually recovering from the failure as a failure history in the database system.
  • the database system holds a plurality of failure histories.
  • the administrator of the monitoring target node (hereinafter sometimes referred to as “system administrator”) inputs a desired keyword when a new failure occurs.
  • the database system searches for a failure history that matches the input keyword from a plurality of failure histories.
  • the monitoring system receives a change in the operating state of the monitoring target node (for example, an input / output (I / O) error with respect to the disk device and a decrease in the throughput of the processor) from the monitoring target node as an event.
  • the system administrator knows the contents of the event by receiving the event using a message or a patrol card.
  • the administrator knows the failure (for example, service stoppage or performance degradation) of the monitored node from the contents of the event, and predicts the root cause of the failure.
  • Root ⁇ ⁇ Cause Analysis (hereinafter referred to as RCA) as a technique for predicting the root cause of failure.
  • the monitoring system holds in advance a combination of an event group and a root cause as a rule.
  • the monitoring system estimates the root cause of the event from the rule including the event.
  • the inconsistency amount is calculated for each of the cases where the generated event is known and unknown, and the calculated inconsistency amount is taken into account in estimating the root cause of the failure.
  • Patent Document 3 information representing the environmental relationship between monitored nodes is constructed. When estimating the root cause of a failure, it is specified on which monitoring target node a failure occurring in a certain monitoring target node affects based on the information.
  • the monitoring target node is a server A having a switch A and a communication interface device (communication I / F) connected to the switch A, and the server A performs I / O to the storage device via the switch A.
  • a failure occurs in the communication I / F (for example, NIC (Network Interface Card)) of the server A. Due to the failure, a first event in which the I / O throughput of the server A reaches an abnormal value and a second event in which the network traffic of the switch A reaches an abnormal value occur.
  • the monitoring system detects a group of events including the first and second events. The contents of the event group are transmitted to the system administrator. At this time, in the failure history database system, the same case is not stored but the same case is stored.
  • “Same case” represents the same failure as the failure that occurred (failure corresponding to the event group). It is a failure history including information. “Class” is a failure history that includes information that represents a failure different from the failure that has occurred but includes information that represents the same recovery method as the recovery method from the failure that has occurred.
  • Patent Document 1 a keyword desired by a system administrator is used for searching for a failure history. Therefore, depending on the keyword, there is a possibility that the target failure history does not hit or many irrelevant failure histories hit.
  • Patent Document 2 when the root cause of a failure is a search query, there is a possibility that a similar item will not hit even if the same item is hit.
  • Patent Document 3 when a monitoring target node in which a failure as a root cause has occurred or a monitoring target node affected by the failure is set as a search query, there may be many unrelated failure histories. .
  • an object of the present invention is to enable a system administrator to quickly identify an appropriate recovery method according to the root cause of a failure.
  • the management server has a meta rule that identifies an event that is a root cause of an event that can occur in a plurality of node devices, and a failure recovery method that corresponds to the meta rule, and the root cause of the event detected by the management server And a recovery method from this cause event is displayed.
  • the recovery method may be information created or updated based on a recovery method that is input by an administrator who uses the management server and is generated when the above-described plurality of node devices are recovered.
  • FIG. 1 is a block diagram illustrating the configuration of the computer system according to the first embodiment.
  • FIG. 2 is a block diagram showing the configuration of the management server.
  • FIG. 3 is a block diagram showing the configuration of the display computer.
  • FIG. 4 is a block diagram showing a configuration of server information.
  • FIG. 5 is a block diagram showing a configuration of switch information.
  • FIG. 6 is a block diagram showing the configuration of storage information.
  • FIG. 7 is a block diagram showing a configuration of topology information.
  • FIG. 8 is a block diagram showing a configuration of the meta RCA rule information.
  • FIG. 9 is a block diagram showing the configuration of the expanded RCA rule information.
  • FIG. 10 is a block diagram showing a configuration of event information.
  • FIG. 11 is a block diagram illustrating a configuration of the failure analysis context.
  • FIG. 12A is a block diagram illustrating a configuration of a failure history entry.
  • FIG. 12B is a block diagram illustrating a configuration of server weight information.
  • FIG. 12C is a block diagram illustrating a configuration of switch weight information.
  • FIG. 12D is a block diagram illustrating a configuration of storage weight information.
  • FIG. 13 is a flowchart for creating a deployment RCA rule.
  • FIG. 14 is a flowchart for determining a root cause candidate and its certainty factor.
  • FIG. 15 is a flowchart for creating a failure analysis context.
  • FIG. 16 is a flowchart for selecting a root cause.
  • FIG. 17 is a flowchart for registering a failure history.
  • FIG. 18A is a flowchart for matching failure analysis contexts.
  • FIG. 18B is a flowchart showing details of step 1026 in FIG. 18A.
  • FIG. 18C is a flowchart showing details of step 1031 in FIG. 18B.
  • FIG. 18D is a flowchart showing details of step 1034 in FIG. 18B.
  • FIG. 18E is a diagram showing an overview of failure analysis context matching.
  • FIG. 18F is a flowchart showing details of step 1035 in FIG. 18B.
  • FIG. 18G is a diagram showing an overview of failure analysis context matching.
  • FIG. 19 shows an example of the candidate / confidence level screen.
  • FIG. 20 shows an example of a failure history search result screen.
  • FIG. 21 shows an example of a failure history registration screen.
  • FIG. 22A shows an example of a meta restoration method registration screen displayed in the second embodiment.
  • FIG. 22B shows another example of the display area e13 on the meta recovery method registration screen.
  • FIG. 23 shows an example of the candidate / confidence level screen displayed in the second embodiment.
  • FIG. 24A shows a first example of the matching degree comparison screen.
  • FIG. 24B shows a second example of the matching degree comparison screen.
  • FIG. 1 is a block diagram relating to the configuration of the computer system 1 according to the first embodiment of the present invention.
  • the computer system 1 includes a management server 10, a display computer 20, and a monitoring target node 30. Note that one management server 10, one display computer 20, and one monitoring target node 30 are shown, but any number may be provided.
  • the monitored node 30 is a device managed by the management server 10.
  • the monitoring target node 20 include a server computer, a storage device (for example, a disk array device having a RAID configuration), a network switch (for example, an FC (Fibre-Channel) switch), a router), a proxy server, and the like. Other devices may be used.
  • the management server 10 is a computer that manages one or more monitoring target nodes 30.
  • the display computer 20 is a computer having a display screen for displaying information output from the management server 10.
  • the management server 10, the display computer 20, and the monitoring target node 30 are connected to each other via a network 50.
  • the network 50 that connects the management server 10 and the display computer 20 and the network 50 that connects the management server 10 and the monitoring target node 30 are the same network, but may be separate networks.
  • the management server 10 and the display computer 20 may be integrated.
  • the management server 10 may be composed of a plurality of computers, and the plurality of computers may have the functions of the management server 10.
  • one or more computers constituting the management server 10 and the display computer 20 may be described as a “management system”.
  • the management computer is a management system, and the combination of the management server 10 and the display computer 20 is also a management system.
  • FIG. 2 shows the configuration of the management server 10.
  • the management server 10 is a computer including a memory 110, a memory interface 161, a processor 140, and a network interface 150.
  • the memory interface 161, the processor 140, and the network interface 150 are connected to each other by an internal network (for example, a bus) 160.
  • the processor 140 accesses the memory 110 via the memory interface 161.
  • the processor 140 performs various processes by executing a program stored in the memory 110.
  • program may be used as the subject. However, since the program is executed by the processor 140, a predetermined process is performed using the memory 110 and the network interface 150.
  • the subject may be an explanation. Further, the processing disclosed with the program as the subject may be processing performed by a computer such as the management server 10. Moreover, a part or all of the program may be realized by dedicated hardware.
  • Various programs may be installed in each computer from a program source (for example, a program distribution server or a computer-readable storage medium (for example, a portable medium)).
  • a program source for example, a program distribution server or a computer-readable storage medium (for example, a portable medium)
  • the memory 110 stores a program executed by the processor 140, information required by the processor 140, and the like. Specifically, for example, in the memory 110, server information 111, switch information 112, storage information 113, topology information 114, meta RCA rule information 115, expanded RCA rule information 116, event information 117, failure history information 119, topology An application program 121, a rule matching analysis program 122, a generation program 123, a context matching analysis program 124, and a failure history management program 125 are stored. Further, the memory 110 stores an application program (hereinafter referred to as AP) 131 and an OS (Operating System) 132.
  • AP application program
  • OS Operating System
  • the AP 131 is a program that implements various processes.
  • the AP 117 provides a database management function or a WEB server function.
  • the OS 132 is a program that controls the entire processing of the management server 10.
  • the server information 111 is information for managing configuration information of a server that is a kind of monitoring target node.
  • the switch information 112 is information for managing configuration information of a switch that is a kind of monitoring target node.
  • Storage information 113 is information for managing configuration information of a storage device that is a kind of monitoring target node.
  • the topology information 114 is information for managing information on the connection configuration (topology) of servers, switches, and storages that are monitoring target nodes.
  • the meta RCA rule information 115 is information for managing meta RCA rules. The details of the meta RCA rule will be described later in ⁇ 1-1: Definition of terms>.
  • the expanded RCA rule information 116 is information for managing the expanded RCA rules. Details of the expanded RCA rule will be described in ⁇ 1-1: Term definition> described later.
  • the event information 117 is information for managing event records of events that have occurred in the monitoring target node.
  • the failure history information 119 includes one or more failure history entries.
  • One failure history entry includes information indicating the cause of a failure that has occurred in the past, information indicating a recovery method, and a failure analysis context.
  • At least the failure history information 119 may be stored in an external storage resource (for example, an external storage device). In that case, for example, the processor 140 can access the failure history information 119 via the network interface 150.
  • the topology application program 121 creates the deployment RCA rule information 116 using the meta RCA rule information 115, the server information 111, the switch information 112, the storage information 113, and the topology information 114.
  • the rule matching analysis program 122 uses the expanded RCA rule information 116 and the event information 117 to determine the meta RCA rule information 115 associated with the event information 117, the expanded RCA rule information 116, and the certainty factor.
  • the generation program 123 generates a failure analysis context using the meta RCA rule information 115, the expanded RCA rule information 116, the server information 111, the switch information 112, the storage information 113, and the topology information 114.
  • the context matching analysis program 124 matches the generated failure analysis context with the failure analysis context in each failure history entry.
  • the failure history management program 125 generates a failure analysis context including the generated failure analysis context, information indicating the recovery method, and information indicating the content of the failure that has occurred, and the failure analysis context is referred to as the failure history information 119. Include in
  • the network interface 150 transmits / receives data to / from another computer (for example, a monitoring target node) via the network 50.
  • another computer for example, a monitoring target node
  • the various programs stored in the memory 110 are not necessarily separate program codes, and one or more program codes may realize program processing.
  • the management server 10 may have an input / output device.
  • input / output devices include a display, a keyboard, and a pointer device, but other devices may be used.
  • a serial interface or an Ethernet interface is used as the input / output device, a display computer having a display or a keyboard or a pointer device is connected to the interface, and display table information is transmitted to the display computer.
  • the display computer may perform the display, or the input may be replaced with the input / output device by receiving the input.
  • FIG. 3 shows the configuration of the display computer 20.
  • the display computer 20 includes a memory 210, a processor 240, a network interface 250, and an input / output device 260 (for example, the memory interface shown in FIG. 2 is not shown).
  • the memory 210, the processor 240, the network interface 250, and the input / output device 260 are connected to each other by an internal network 270.
  • the processor 240 performs various processes by executing a program stored in the memory 210.
  • the memory 210 stores a program executed by the processor 240, information required by the processor 240, and the like. Specifically, for example, the screen display program 211 is stored in the memory 210. Further, the memory 210 stores an application program (hereinafter referred to as AP) 221 and an OS (Operating System) 222.
  • the AP 221 is a program that implements various processes. For example, the AP 221 provides a WEB client function.
  • the OS 222 is a program that controls the entire processing of the display computer 20.
  • the screen display program 211 is a program for displaying information on the input / output device 260, for example, a display device.
  • the network interface 250 transmits / receives data to / from another computer (for example, the management server 10) via the network 50.
  • another computer for example, the management server 10.
  • An example of the input / output device 260 is a display, a keyboard, and a pointer device, but other devices may be used.
  • a serial interface or an Ethernet interface may be connected, and a display computer having a display, a keyboard, or a pointer device may be connected to the interface as the input / output device.
  • the display computer 20 may receive display information from the management server 10 or transmit input information to the management server 10.
  • the management server 10 has first and second computers, the first computer executes the topology application program 121, the rule matching analysis program 122, and the generation program 123, and the second computer
  • the matching analysis program 124 and the failure history management program 125 may be executed.
  • the server information 111, the switch information 121, the storage information 113, the topology information 114, the meta RCA rule information 115, and the expanded RCA rule information 116 are included in the first computer, and the event information 117 and the failure history information 119 are:
  • the second computer may have.
  • Event is an event of a change in the operating state that has occurred in the monitoring target node 30.
  • Event record is information for identifying an event.
  • the event record includes, for example, an event type that is information indicating the type of the event, an identifier of the monitoring target node 30 that is the generation source, information that represents the content of the event, and information that represents the occurrence date and time of the event. There is one event record for each event.
  • RCA is an abbreviation of Root Cause Analysis, and is a function for specifying a monitoring target node as a root cause of an event based on an event record of the monitoring target node (for example, server, switch, storage device). .
  • Metal RCA rule is a rule that defines a certain failure and a group of events that are expected to occur due to the failure. Used by RCA. By using the meta RCA rule, it is possible to derive the root cause failure from the event group.
  • the meta RCA rule is information (meta information) that does not include topology information representing a topology composed of one or more monitoring target nodes.
  • “Expanded RCA rule” is a rule in which a meta RCA rule is expanded for each monitoring target node. Used by RCA.
  • fault analysis context is information used when analyzing a fault.
  • the failure analysis context includes a record in the meta RCA rule information 115, a record in the expanded RCA rule information 116, a record in the server information 111, a record in the switch information 112, a record in the storage information 113, and topology information 114.
  • the records in are associated. Details will be described later with reference to FIG.
  • FIG. 4 is a diagram showing the server information 111.
  • the server information 111 is a table having one record per server (hereinafter referred to as server record).
  • the server record is a record having a server ID 501, a server name 502, a server vendor 503, a server IP address 504, a server OS 505, and a server continuous operation time 506 as attribute values.
  • the information elements 501 to 506 will be described by taking one server (hereinafter referred to as “target server” in the description of FIG. 4) as an example.
  • the server ID 501 is an identifier assigned to the target server that is the monitoring target node 30 by the topology application program 121.
  • the server name 502 is a computer name of the target server.
  • the server vendor 503 is the manufacturer name of the target server.
  • the server IP address 504 is an identifier to which the target server is assigned on the network.
  • the server OS 505 is an OS name installed in the target server.
  • the continuous operation time 506 of the server is a continuous operation time from the last start of the target server to the present.
  • the server information 111 may have a data structure other than a table as long as it has an attribute value related to the server, or may have an attribute value other than the attribute values described above. Further, the server information 111 may not have at least one attribute value other than the server ID 501.
  • FIG. 5 is a diagram showing the switch information 112.
  • the switch information 112 is a table having one record per switch (hereinafter referred to as switch record).
  • the switch record is a record having the switch ID 511, the switch name 512, the switch vendor 513, the switch IP address 514, the switch type 515, and the switch continuous operation time 516 as attribute values.
  • the information elements 511 to 516 will be described by taking one switch (hereinafter referred to as “target switch” in the description of FIG. 5) as an example.
  • the switch ID 511 is an identifier assigned to the target switch that is the monitoring target node 30 by the topology application program 121.
  • the switch name 512 is a computer name of the target switch.
  • the switch vendor 513 is the manufacturer name of the target switch.
  • the switch IP address 514 is an identifier to which the target switch is assigned on the network.
  • Switch type 515 is the model name of the target switch.
  • the continuous operation time 516 of the switch is a continuous operation time from the last activation of the target switch to the present.
  • the switch information 112 may have a data structure other than a table as long as it has an attribute value related to a switch, and may have an attribute value other than the attribute values described above.
  • the switch information 112 may not have at least one attribute value other than the switch ID 511.
  • FIG. 6 is a diagram showing the storage information 113.
  • Storage information 113 is a table having one record (hereinafter referred to as storage record) for each storage device.
  • the storage record is a record having a storage ID 521, a storage name 522, a storage vendor 523, a storage IP address 524, a storage firmware 525, and a continuous operation time 526 of the storage as attribute values.
  • the information elements 521 to 526 will be described by taking one storage apparatus (hereinafter referred to as “target storage” in the description of FIG. 6) as an example.
  • the storage ID 521 is an identifier assigned to the target storage that is the monitoring target node 30 by the topology application program 121.
  • Storage name 522 is the computer name of the target storage.
  • the storage vendor 523 is the manufacturer name of the target storage.
  • the storage IP address 524 is an identifier to which the target storage is allocated on the network.
  • Storage firmware 525 is the name of the firmware installed in the target storage.
  • the continuous operation time 526 of the storage is the continuous operation time from the last start of the target storage to the present.
  • the storage information 113 may have a data structure other than a table as long as it has an attribute value related to the storage device, and may have an attribute value other than the attribute values described above. In addition, the storage information 113 may not have at least one attribute value other than the storage ID 521.
  • FIG. 7 is a diagram showing the topology information 114.
  • the topology information 114 is a table having one record for each topology (hereinafter, topology record).
  • the topology record is a record having the topology ID 531, server ID 532, switch ID 533, and storage ID 534 as attribute values.
  • the information elements 531 to 534 will be described by taking one topology (hereinafter referred to as “target topology” in the description of FIG. 7) as an example.
  • the topology ID 531 is an identifier of the target topology.
  • the “topology” is a connection form between the monitoring target nodes 30, in other words, a combination of the monitoring target nodes 30. Specifically, the types and arrangement of monitoring target nodes are defined as the topology.
  • the server ID 532 is the server ID 501 of the server that the target topology has.
  • Switch ID 533 is the switch ID 511 of the switch that the target topology has.
  • the storage ID 534 is the storage ID 521 of the storage device that the target topology has.
  • the topology information 114 may have a data structure other than the table as long as it has an attribute value related to the connection form of the monitoring target node 30, and may have an attribute value other than the attribute values described above.
  • the topology is typically a connection form in which a server (computer) is connected to a storage device via a switch (network switch).
  • the server issues an I / O command (write command or read command) specifying a logical volume provided from the storage apparatus.
  • the I / O command reaches the storage device via the switch.
  • the storage apparatus performs I / O with respect to the logical volume specified by the command.
  • FIG. 8 is a diagram showing the meta RCA rule information 115.
  • the meta RCA rule information 115 is a table having one record for each meta RCA rule (hereinafter, “meta RCA record”).
  • the meta RCA record is a record having a meta RCA rule ID 541, a server event 542, a switch event 543, a storage event 544, a cause node 545, and cause content 546 as attribute values.
  • the information elements 541 to 546 will be described by taking one meta RCA rule (hereinafter referred to as “target meta RCA rule” in the description of FIG. 8) as an example.
  • the meta RCA rule ID 541 is an identifier assigned by the rule matching analysis program 122 to the target meta RCA rule.
  • the server event 542 is information representing the content of the event at the server included in the target meta RCA rule.
  • the switch event 543 is information indicating the content of the event at the switch of the target meta RCA rule.
  • the storage event 544 is information indicating the content of the event in the storage device possessed by the target meta RCA rule.
  • the cause node 545 is information indicating the type of node that is the root cause of the event included in the target meta RCA rule.
  • the cause content 546 is information indicating the content of the root cause of the event included in the target meta RCA rule.
  • a combination of the cause content 546 and the above-described cause node 545 represents the root cause of the event group.
  • the meta RCA rule information 115 may have a data structure other than a table as long as it has an attribute value related to the meta RCA rule, and may have an attribute value other than the attribute values described above.
  • FIG. 9 is a diagram showing the expanded RCA rule information 116.
  • the expanded RCA rule information 116 is a table having one record (hereinafter referred to as an expanded RCA record) for each expanded RCA rule.
  • the expanded RCA record is a record having expanded RCA rule ID 551, meta RCA rule ID 552, topology ID 553, cause node ID 554, and cause details 555 as attribute values.
  • the information elements 551 to 555 will be described by taking one expanded RCA rule (hereinafter referred to as “target expanded RCA rule” in the description of FIG. 9) as an example.
  • the expanded RCA rule ID 551 is an identifier assigned by the rule matching analysis program 122 to the target expanded RCA rule.
  • the meta RCA rule ID 552 is the meta RCA rule ID 541 of the meta RCA rule to which the target deployment RCA rule belongs.
  • the topology ID 553 is the topology ID 531 of the topology to which the target deployment RCA rule belongs.
  • the cause node ID 554 is a server ID 501, a switch ID 511, or a storage ID 521 for identifying the monitoring target node 30 that is the root cause of the target deployment RCA rule.
  • the cause detail 555 is a cause content 546 representing the content of the root cause of the target deployment RCA rule.
  • the expanded RCA rule information 116 may have a data structure other than a table as long as it has an attribute value related to the expanded RCA rule, and may have an attribute value other than the attribute values described above.
  • FIG. 10 is a diagram showing the event information 117.
  • the event information 117 is a table having one event record for each event.
  • the event record is a record having an event ID 561, an event type 562, a target node type 563, a target node ID 564, an event content 565, an occurrence date and time 566, and a state 567 as attribute values.
  • the information elements 561 to 567 will be described by taking one event (hereinafter referred to as “target event” in the description of FIG. 10) as an example.
  • the event ID 561 is an identifier assigned to the event record of the target event by the rule matching analysis program 122.
  • the event type 562 is information indicating the type of target event. Specific values of the event type 562 include, for example, “Critical”, “Warning”, and “Information”.
  • the target node type 563 is information indicating the node type (for example, server, switch, or storage device) of the monitoring target node 30 that is the source of the target event.
  • the target node ID 564 is a server ID 501, a switch ID 511, or a storage ID 521 that represents the monitoring target node 30 that is the source of the target event.
  • the event content 565 is information representing the content of the target event.
  • the occurrence date and time 566 is information representing the occurrence date and time of the target event.
  • the state 567 is information indicating whether or not the target event has been resolved.
  • the event information 117 may have a data structure other than the table as long as it has an attribute value related to the event, and may have an attribute value other than the attribute values described above. Further, the event information 117 may not have at least one attribute value other than the event ID 551, the target node ID 564, the event content 565, and the occurrence date / time 566.
  • FIG. 11 is a diagram showing the failure analysis context 120.
  • the failure analysis context 120 is data having a failure analysis context ID 601, a meta RCA rule ID 602, a deployment RCA rule ID 603, a topology ID 604, a server ID 605, a switch ID 606, and a storage ID 607 as attribute values.
  • the failure analysis context ID 601 is an identifier assigned to the failure analysis context 120 by the generation program 123.
  • the meta RCA rule ID 602 is a meta RCA rule ID 541 for identifying the meta RCA rule associated with the failure analysis context 120.
  • the expanded RCA rule ID 603 is an expanded RCA rule ID 551 for identifying the expanded RCA rule associated with the failure analysis context 120.
  • the topology ID 604 is a topology ID 531 for identifying the topology associated with the failure analysis context 120.
  • the server ID 605 is a server ID 501 for identifying a server associated with the failure analysis context 120.
  • the switch ID 606 is a switch ID 511 for identifying a switch associated with the failure analysis context 120.
  • the storage ID 607 is a storage ID 521 for identifying the storage device associated with the failure analysis context 120.
  • failure analysis context 120 may have an attribute value other than the attribute values described above.
  • FIG. 12A is a diagram showing a failure history entry 1191 included in the failure history information 119.
  • Failure history entry 1191 includes failure history ID 701, meta RCA rule ID 702, expanded RCA rule ID 703, topology ID 704, server ID 705, switch ID 706, storage ID 707, server weight ID 708, switch weight ID 709, storage weight ID 710, cause 711 and recovery method 712. Are data having attribute values.
  • the failure history ID 701 is an identifier assigned to the failure history entry 1191 by the failure history management program 125.
  • the meta RCA rule ID 702 is a meta RCA rule ID 541 for identifying the meta RCA rule associated with the failure history entry 1191.
  • the expanded RCA rule ID 703 is an expanded RCA rule ID 551 for identifying the expanded RCA rule associated with the failure history entry 1191.
  • the topology ID 704 is a topology ID 531 for identifying the topology associated with the failure history entry 1191.
  • the server ID 705 is a server ID 501 for identifying the server associated with the failure history entry 1191.
  • the switch ID 706 is a switch ID 511 for identifying the switch associated with the failure history entry 1191.
  • the storage ID 707 is a storage ID 521 for identifying the storage device associated with the failure history entry 1191.
  • the server weight ID 708 is a server weight ID 801 (see FIG. 12B) for identifying the server weight record associated with the failure history entry 1191.
  • the server weight record is a record that the server weight information 800 has.
  • the switch weight ID 709 is a switch weight ID 811 (see FIG. 12C) for identifying the switch weight record associated with the failure history entry 1191.
  • the switch weight record is a record that the switch weight information 810 has.
  • the storage weight ID 710 is a storage weight ID 821 (see FIG. 12D) for identifying the storage weight record associated with the failure history entry 1191.
  • the storage weight record is a record that the storage weight information 820 has.
  • the cause 711 is information indicating the cause of the failure corresponding to the failure history entry 1191.
  • the recovery method 712 is information representing a recovery method from a failure corresponding to the failure history entry 1191.
  • IDs 702 to 707 included in the failure history entry 1191 are duplicates of IDs 602 to 607 included in the failure analysis context 120 (see FIG. 11). That is, as described above, the failure history entry 1191 has the failure analysis context 120. According to FIG. 12A, the failure analysis context ID 601 is not included in the failure history entry 1191, but the ID 601 may be included in the record 1191.
  • the failure history information 119 may have a data structure other than the data structure described above, or may have an attribute value other than the attribute values described above. Further, the failure history information 119 may not include the server weight ID 708, the switch weight ID 709, and the storage weight ID 710.
  • FIG. 12B is a diagram showing server weight information 800.
  • the server weight information 800 is a table having one record (server weight record) for each server weight.
  • the server weight record is a record having the server weight ID 801, the server vendor 802, the server IP address 803, the server OS 804, and the server continuous operation time 805 as attribute values.
  • the information elements 801 to 805 will be described by taking one server weight (referred to as “target server weight” in the description of FIG. 12B) as an example.
  • the server weight ID 801 is an identifier assigned to the target server weight.
  • the server vendor 802 is a kind of weight belonging to the target server weight, and is a value representing how much importance is given to the item of server vendor.
  • the server IP address 803 is a kind of weight belonging to the target server weight, and is a value representing how important the item of the server IP address is.
  • the server OS 804 is a kind of weight belonging to the target server weight, and is a value representing how much the item of server OS is regarded as important.
  • the continuous operation time 805 of the server is a kind of weight belonging to the target server weight, and represents how much importance is given to the item of continuous operation time of the server.
  • server weight is defined by the weights of a plurality of types of items related to the server.
  • server weight information 800 may have a data structure other than a table as long as it has an attribute value related to the server weight, and may also have an attribute value other than the attribute values described above. Further, the server weight information 800 may not have at least one attribute value other than the server weight ID 801.
  • FIG. 12C is a diagram showing switch weight information 810.
  • the switch weight information 810 is a table having one record (switch weight record) for one switch weight.
  • the switch weight record is a record having a switch weight ID 811, a switch vendor 812, a switch IP address 813, a switch type 814, and a switch continuous operation time 815 as attribute values.
  • the information elements 811 to 815 will be described by taking one switch weight (referred to as “target switch weight” in the description of FIG. 12C) as an example.
  • the switch weight ID 811 is an identifier assigned to the target switch weight.
  • the switch vendor 812 is a kind of weight belonging to the target switch weight, and is a value indicating how much importance is given to the item of switch vendor.
  • the switch IP address 813 is a kind of weight belonging to the target switch weight, and is a value representing how much importance is given to the item of the switch IP address.
  • the switch type 814 is a kind of weight belonging to the target switch weight, and is a value representing how much importance is given to the item of switch type.
  • the continuous operation time 815 of the switch is a kind of weight belonging to the target switch weight, and represents how much importance is given to the item of continuous operation time of the switch.
  • switch weight is defined by the weights of a plurality of types of items related to the switch.
  • the switch weight information 810 may have a data structure other than a table as long as it has an attribute value related to the switch weight, and may also have an attribute value other than the attribute values described above.
  • the switch weight information 810 may not have at least one attribute value other than the switch weight ID 811.
  • FIG. 12D is a diagram showing the storage weight information 820.
  • the storage weight information 820 is a table having one record (storage weight record) for one storage weight.
  • the storage weight record is a record having a storage weight ID 821, storage vendor 822, storage IP address 823, storage firmware 824, and storage continuous operation time 825 as attribute values.
  • the information elements 821 to 825 will be described by taking one storage weight (referred to as “target storage weight” in the description of FIG. 12D) as an example.
  • the storage weight ID 821 is an identifier assigned to the target storage weight.
  • the storage vendor 822 is a kind of weight belonging to the target storage weight, and is a value indicating how much importance is given to the item of storage vendor.
  • the storage IP address 823 is a kind of weight belonging to the target storage weight, and is a value indicating how much importance is given to the item of storage IP address.
  • the storage firmware 824 is a kind of weight belonging to the target storage weight, and is a value indicating how much importance is given to the item of storage firmware.
  • the continuous operation time 825 of the storage is a kind of weight belonging to the target storage weight, and represents how much importance is given to the item of continuous operation time of the storage.
  • “storage weight” is defined by the weights of a plurality of types of items related to storage.
  • the storage weight information 820 may have a data structure other than the table as long as it has an attribute value related to the storage weight, and may also have an attribute value other than the attribute values described above. Further, the storage weight information 820 may not have at least one attribute value other than the storage weight ID 821.
  • the server weight information 800, the switch weight information 810, and the storage weight information 820 described above are included in the failure history information, for example.
  • a topology composed of servers, switches, and storage devices is described as an example.
  • the present invention is not limited to such a topology but can be applied to other types of topologies.
  • a service providing node device an example is a storage device
  • a service using node device an example is a server
  • the server information is service using node device information.
  • the service using node device information includes the following information (a1) to (a3): (A1) Network identifier such as the IP address of the service using node device; (A2) Information indicating the hardware or software configuration of the node device; (A3) Information indicating setting contents, Can be included.
  • the switch information (see FIG. 5) is more abstractly relay device information (or relay node device information).
  • the relay device information includes the following information (b1) and (b2): (B1) Information indicating a hardware or software configuration of a node device (an example is a switch) that mediates communication between the service using node device and the service providing node device; (B2) Information indicating setting contents, Can be included.
  • the service providing node device information includes the following information (c1) to (c3): (C1) Network identifier such as the IP address of the service providing node device; (C2) Information indicating the hardware or software configuration of the node device; (C3) Information indicating setting contents, Can be included. Further, the service providing node device information may include information indicating the type of network service provided by the service using node device.
  • the topology information can include information representing a set (or correspondence) of an identifier of a service using node device and an identifier of a service providing node device used by the service using node device. If the service using node device communicates with the service using node device via one or more relay devices, the identifier of the one or more relay devices may be included in the topology information.
  • the meta RCA rule information includes the following information (d1) and (d2) for each network service to be monitored by the management server: (D1) Type of first event (service utilization node device occurrence event) that can occur in the service utilization node device, and second event (service provision node device occurrence) that can occur in the service provision node device (or relay device) Information indicating the combination with the event type; (D2) Indicates the cause (or cause type) that can occur in the service providing node device or the relay device that can be determined (or estimated to be the cause) when the first event and the second event occur information, Can be included.
  • D1 Type of first event (service utilization node device occurrence event) that can occur in the service utilization node device, and second event (service provision node device occurrence) that can occur in the service provision node device (or relay device) Information indicating the combination with the event type;
  • D2 Indicates the cause (or cause type) that can occur in the service providing node device or the relay device that can be determined (or estimated to be the cause)
  • the expanded RCA rule information includes the following information (e1) to (e3) for each monitored node that uses or provides a network service: (E1) The type of the first event that can occur in the node device that is the service using node device and the identifier of the service using node device, the type of the second event that can occur in the service providing node device (or relay device), and Information indicating a combination with an identifier of a service providing node device (or relay device); (E2) an identifier of a service providing node device (or relay device) that can be determined (or estimated to be a cause) when the first event and the second event occur; (E3) Information indicating a cause (or cause type) that may occur in the service providing node device (or relay device); Can be included.
  • E1 The type of the first event that can occur in the node device that is the service using node device and the identifier of the service using node device, the type of the second event that can occur in the service providing node device (or relay device), and Information
  • the failure analysis context can include the identifier of the meta RCA rule used to identify the root cause of the failure. Note that the identifier of the deployment RCA rule, the topology identifier, or the identifier of the monitoring target node used to identify the root cause of the failure may be included.
  • the failure history entry can include the content of the failure analysis context and information indicating a recovery method (for example, a recovery procedure) from the failure corresponding to the context.
  • the failure history entry may include an evaluation value for evaluating the matching degree of the failure analysis context included in the record, or an identifier of information in which the evaluation value is recorded.
  • the server weight information can include a value for evaluating the matching degree, which is distributed to the hardware or software configuration of the service using node device and the setting content element.
  • Switch weight information (see FIG. 12C): It can include a value for evaluating the matching degree, which is distributed to the hardware or software configuration of the relay device and the setting content elements.
  • the storage weight information can include a value for evaluating the matching degree, which is distributed to the hardware or software configuration of the service providing node device and the setting content element.
  • FIG. 13 shows a flow for creating an expanded RCA rule.
  • the topology application program 121 acquires information from the monitoring target node 30 through the network 50. If the monitoring target node 30 is a server, information including the server name, the server vendor name, the server IP address, the server OS name, and the continuous operation time of the server (hereinafter, server acquisition information) is acquired. . The topology application program 121 creates or updates the server information 111 based on the server acquisition information received from each monitoring target node (each server).
  • the topology application program 121 performs the following processes (A) and (B):
  • (A) When the identifier in the server acquisition information is not stored in the server information 111, the server record in the server information 111 corresponding to the server acquisition information (hereinafter referred to as “target server record” in the description of FIG. 13).
  • the server ID 501 for example, an identifier in the server acquisition information
  • the server ID 501 is stored in the target record
  • the server name 502, the vendor name 503, the IP address 504, the OS name 505, and the continuous operation time 506 in the server acquisition information are stored in the target server record. I do.
  • step 1001 may be omitted for a monitoring target node that is clearly not a server in advance.
  • the topology application program 121 acquires information from the monitoring target node 30 through the network 50. If the monitoring target node 30 is a switch, information including the switch name, the switch vendor name, the switch IP address, the switch type, and the continuous operation time of the switch (hereinafter, switch acquisition information) is acquired. The topology application program 121 creates or updates the switch information 112 based on the switch acquisition information received from each monitoring target node (each switch).
  • the topology application program 121 performs the following processes (A) and (B):
  • (A) When the identifier in the switch acquisition information is not stored in the switch information 112, the switch record in the switch information 112 corresponding to the switch acquisition information (hereinafter referred to as “target switch record” in the description of FIG. 13).
  • target switch record Is assigned a switch ID 511 (for example, an identifier in the switch acquisition information), and the switch ID 511 is stored in the target switch record;
  • the switch name 512, the vendor name 513, the IP address 514, the type 515, and the continuous operation time 516 of the switch acquisition information are stored in the target switch record. I do.
  • step 1002 may be omitted for a monitoring target node that is clearly not a switch in advance.
  • the topology application program 121 acquires information from the monitoring target node 30 through the network 50. If the monitoring target node 30 is a storage device, the storage name, storage vendor name, storage IP address, storage firmware name, and information including the continuous operation time of the storage (hereinafter referred to as storage acquisition information) are acquired. The The topology application program 121 creates or updates the storage information 113 based on the storage acquisition information received from each monitoring target node (each storage device).
  • the topology application program 121 performs the following processes (A) and (B):
  • (A) When the identifier in the storage acquisition information is not stored in the storage information 113, the storage record in the storage information 113 corresponding to the storage acquisition information (hereinafter referred to as “target storage record” in the description of FIG. 13) ) Is assigned a storage ID 521 (for example, an identifier in the storage acquisition information), and the storage ID 521 is stored in the target storage record;
  • the storage name 522, the vendor name 523, the IP address 524, the firmware 525, and the continuous operation time 526 of the storage acquisition information are stored in the target storage record. I do.
  • step 1003 may be omitted for a monitoring target node that is clearly not a storage in advance.
  • the topology application program 121 receives the topology acquisition information of the monitoring target node 30 through the network 50.
  • the topology acquisition information the ID of a switch and the IDs of servers and storage devices connected to the switch are included.
  • the topology application program 121 performs the following processes (A) and (B): (A) When the identifier in the topology acquisition information is not stored in the topology information 114, the topology record in the topology information 114 corresponding to the topology acquisition information (hereinafter referred to as “target topology record” in the description of FIG. 13).
  • topology ID 531 for example, an identifier in the topology acquisition information
  • topology ID 321 is stored in the target topology record
  • B Store the switch ID 533, server ID 532, and storage ID 534 in the topology acquisition information in the target topology record. I do.
  • the data structure of the topology acquisition information is not limited to the above structure as long as the topology information 114 can be updated.
  • step 1004 may be omitted for nodes to be monitored that are clearly not switches, servers, or storage devices in advance.
  • the topology record may be updated as follows. In other words, connection destination information indicating which monitoring target node is directly connected to each monitoring target node is acquired, and path information indicating which logical volume is accessed from which server from the server or storage device And the target topology record may be updated based on the connection destination information and the path information.
  • the topology application program 121 has the following (Step A) to (Step D): (Step A) acquiring at least one value included in each of the acquisition information from the monitoring target node as node acquisition information; (Step B) Update service using node device information, service providing node device information, or relay node device information based on the node acquisition information; (Step C) Based on the topology acquisition information, the correspondence between the identifier of the service providing node device for the predetermined network service and the identifier of the service using node device that uses the node device is included in the topology information; (Step D) Update the expanded RCA rule information based on the topology information and the meta RCA rule information; It can be performed.
  • one record of the expanded RCA rule information is created from one record of the meta RCA rule information, but the present invention is not limited to this.
  • One example is multi-level reasoning.
  • a new rule can be derived from a plurality of rules using a three-level reasoning method or the like.
  • the expanded RCA rule information may actually be created by one or more meta RCA rule records and topology information.
  • An example of deriving a new rule from a plurality of rules is as follows.
  • Event A For a first network service (for example, WWW (World Wide Web)), a first type event (hereinafter referred to as event A) that occurs in a service using node device and a service providing node device
  • event B the second type event
  • the root cause of event A is the occurrence of event B.
  • a third type of event (hereinafter referred to as event C) that occurs in a service using node device, and a service providing node device
  • event D a fourth type of event that occurs
  • the root cause of event C is the occurrence of event D.
  • the node device A is a service using node device and the node device B is a service providing node device.
  • the node device B is a service using node device
  • the node device C is a service providing node device.
  • the first network service in the node apparatus B is provided using the second network service.
  • First deployment RCA rule to be generated When event A occurring in node device A is detected and event B occurring in node device B is detected, the root cause of event A occurring in node device A is An event B occurs in the node device B.
  • Second deployment RCA rule to be generated When the event C occurring in the node device B is detected and the event D occurring in the node device C is detected, the root cause of the event C occurring in the node device B is An event D occurs in the node device C.
  • second deployment RCA rule to be generated When event A occurring in node device A is detected and event D occurring in node device C is detected, the root cause of event A occurring in node device A is An event D occurs in the node device C.
  • topology information When multi-stage reasoning is used, in addition to the dependency between physical devices (for example, between nodes), information representing the dependency between network services or logical objects may be included in the topology information.
  • the third topology information is an example.
  • the root cause is identified while referring to the meta RCA rule represented by the meta RCA rule information 115 and the topology represented by the topology information based on the meta RCA rule ID 552 and the topology ID 553. Is called.
  • information representing a meta RCA rule and a rule developed based on the topology may be included in the developed RCA rule information. According to this method, the consumption amount of the memory 110 of the management server 10 is increased, but the speed of identifying the root cause is higher.
  • the meta RCA rule ID 552 is required in the expanded RCA rule information.
  • FIG. 14 shows a flow from detection of an event to identification of the root cause of the event. This flow is executed at regular time intervals (for example, every 10 minutes) or simply by repetition.
  • the program 122 requests an event entry, which is information including an event type, a target node type, a target node ID, an event content, and an occurrence date and time, to all the monitoring target nodes 30.
  • Each information element included in the event entry is as follows: (Event type) Indicates the type of event (for example, Critical, Warning, Information) to which the event entry belongs; (Target node type) Indicates the node type (for example, server, switch or storage device) of the monitoring target node 30 that is the target of the event that has occurred; (Target node ID) An identifier (server ID 501, switch ID 511, or storage ID 521) indicating the monitoring target node 30 in which the event has occurred; (Event content) The content of the event that occurred; (Occurrence date and time) This is the event occurrence date and time.
  • the event entry may be transmitted from the monitoring target node 30 without receiving a request from the rule matching analysis program 122. Moreover, the information showing the date and time of occurrence does not necessarily have to be included. In that case, instead of the occurrence date and time, the date and time when the management server 10 received the event entry can be adopted.
  • Step 1012 When the rule matching analysis program 122 receives an event entry from the monitoring target node 30 in Step 1011, the rule matching analysis program 122 performs Step 1013. If no event entry has been received from the monitoring target node 30, step 1011 is performed.
  • the rule matching analysis program 122 adds information to the event information 117 based on the event entry. Specifically, for example, the program 122 executes the following processes (A) to (C): (A) A new event ID 561 is acquired, and the ID 561 is stored in a blank record in the event information 117 (hereinafter referred to as “target record” in the description of step 1013); (B) Store in the target record the event type, target node type, target node ID, event content, and occurrence date and time in the event entry; (C) A value “unresolved” is stored as the state 567 in the target record. I do.
  • event entry may include other values as long as the event record of the event information 117 (record in the event information 117) can be added or updated.
  • Step 1014 The rule matching analysis program 122 sets the state 567 representing “unsolved” based on the event record including the state 567 representing “unsolved”, the topology information 114, and the expanded RCA rule information 116.
  • An expanded RCA record (a record in the expanded RCA rule information 116) associated with the included event record is specified.
  • the rule matching analysis program 122 performs the following processes (A) to (H): (A) Identifying the event record (first event record) with the latest occurrence date and time 565 from among the event records whose state 556 is “unresolved”; (B) One or more second event records are identified based on the first event record identified in the immediately preceding step (the occurrence date and time 565 in the first event record and the second event record) The difference from the occurrence date and time 565 is within a predetermined time (for example, around 10 minutes)); (C) With reference to the target node types 563 in all the second event records obtained in (B) above, the target node types are different based on all the target node IDs in the second event records.
  • node ID sets composed of target node IDs (for example, there are four event records, two of which are records related to servers A and B, and the remaining two are switches A and In the case of the record relating to B, the server A ID—the switch A ID, the server A ID—the switch B ID, the server B ID—the switch A ID, and the server B ID—the switch B ID Create node ID set); (D-1) There is a second event record that includes a target node ID that is not included in any ID set obtained in (C) above (an event record that includes a state 556 representing “unresolved”).
  • the second event entry with the latest occurrence date and time 565 is identified, and (B) is performed with the second event entry as the first event entry; (D-2) There is no second event record including the target node ID that is not included in any of the ID sets obtained in (C) (an event record including a state 556 indicating “unresolved”).
  • Meta RCA record (record of meta RCA rule information 115): (Condition F1) having a server event 542 that matches the event content 564 in the event record having the target node ID of the server in the event ID set; (Condition F2) having a switch event 543 that matches the event content 564 in the event record having the target node ID of the switch in the event ID set; (Condition F3) having a storage event 544 that matches the event content 564 in the event record having the target node ID of the storage device in the event ID set, If such a meta RCA record is found, the meta RCA rule ID 541 of the meta RCA record is extracted, and the ID 541 is associated with the corresponding node ID set; (G) The following processing (g1) to (g4) for each node ID set (set associated with the meta RCA rule ID 541) obtained in (F) above: (G1) extracting the cause node 545 from the meta RCA record having the meta RCA rule ID 541 associated with the node ID set; (G2) identifying an
  • Step 1015 The rule matching analysis program 122 compiles the plurality of expanded RCA records obtained in Step 1014 into records having the same meta RCA rule ID 552. As a result, one or a plurality of expanded RCA record groups having the same meta RCA rule ID 552 can be created.
  • Step 1016 The program 122 compiles the expanded RCA rules belonging to the group obtained in Step 1015 with records having the same cause node ID 554. As a result, one or a plurality of subgroups of the expanded RCA record having the same cause node ID 554 can be generated per group of the expanded RCA record having the same meta RCA rule ID 552.
  • the monitoring target node 30 indicated by the cause node ID 554 is a root cause candidate.
  • the program 122 calculates the certainty of the root cause candidate obtained in Step 1016 as a certainty factor.
  • a certainty factor calculation method for example, there is a method based on the number of expanded RCA rule records with matching cause node IDs 554. For example, a certainty factor corresponding to the number of expanded RCA rule records with the matching cause node ID 554 is assigned to each root cause candidate. The certainty factor allocated to the root cause candidate having a large number of expanded RCA rule records having the same cause node ID 554 is higher than the certainty factor allocated to the root cause candidate having a small number of such expanded RCA rule records.
  • the certainty factor may be calculated by another method.
  • FIG. 15 is a flowchart for creating a failure analysis context. This flow is started immediately after step 1017, for example.
  • the generation program 123 creates a failure analysis context 118. Specifically, for example, the generation program 123 performs the following processes (A) to (G): (A) Include the meta RCA rule ID 552 obtained in step 1015 in the failure analysis context; (B) Of one or more expanded RCA records having one or more expanded RCA rule IDs 551 obtained in step 1014, expanded from a record having an ID 552 that matches the meta RCA rule ID 552 obtained in (A) above.
  • the server ID 532 is extracted from the topology record having the ID 531 that matches the topology ID 553 (605) obtained in (C) above, and the ID 532 is included in the failure analysis context;
  • E Extract the switch ID 533 from the topology record having the ID 531 that matches the topology ID 553 (605) obtained in (C) above, and include the ID 533 in the failure analysis context;
  • F Extract the storage ID 534 from the topology record having the ID 531 that matches the topology ID 553 (605) obtained in (C) above, and include the ID 534 in the failure analysis context;
  • the generation program 123 allocates a failure analysis context ID 601 and includes the ID 601 in the failure analysis context.
  • FIG. 16 shows a flow for selecting the root cause. This flow is started immediately after step 1018, for example.
  • the generation program 123 includes first display information including the following elements (a) to (c): (A) The server name 502 in the server record having the server ID 501 that matches the cause node ID 554 in step 1016, the switch name 512 in the switch record having the switch ID 511 that matches the cause node ID 554 in step 1016, or the step A storage name 522 in the storage record having a storage ID 521 that matches the cause node ID 554 at 1016; (B) Cause details 555 in the expanded RCA record corresponding to the cause node ID 554 in (a) above (the expanded RCA record compiled in step 1015); (C) The certainty factor corresponding to the cause node ID 554 in (a) above (the certainty factor obtained in step 1017), Is transmitted to the display computer 20 through the network 50.
  • Step 1020 The screen display program 211 receives the first display information transmitted in Step 1019.
  • Step 1021 The screen display program 211 displays the first display information received in Step 1020 on the input / output device 260 (for example, a display device).
  • FIG. 19 shows a candidate / confidence screen 2010.
  • a screen 2010 is an example of a display screen of first display information.
  • Candidate ID 2011 is an identifier of a root cause candidate. Each root cause candidate is assigned by a candidate ID, for example, the display program 211.
  • the cause node name 2012 is an element included in the first display information, and is the server name 502, switch name 512, or storage name 522 of the root cause candidate (monitored node 30).
  • the cause details 2013 are cause details 555 included in the first display information.
  • the certainty factor 2014 is the certainty factor included in the first display information.
  • the screen display program 211 uses the input / output device 260 (for example, a mouse) to transmit information (for example, the cause node ID) for identifying the root cause candidate selected by the system administrator via the network 50 to the management server. Send to.
  • information for example, the cause node ID
  • Step 1023 The generation program 123 receives the information transmitted in Step 1022.
  • Step 1024 The generation program 123 determines the failure analysis context 118 corresponding to the information received in Step 1023.
  • This failure analysis context 118 is the failure analysis context created in step 1018.
  • FIG. 17 shows the flow of failure registration. When the number of failure history entries is zero, this flow is started after the flow of FIG. When there are one or more failure history entries, this flow is started after the flow of FIG. 16 and the flow of FIG. 18A.
  • Step 1040 The display computer 20 displays a failure history registration screen.
  • FIG. 21 shows a registration screen 2030.
  • This screen 2030 is an example of a failure history registration screen.
  • the root cause 2031 is the server name 502, the switch name 512, or the switch name 522 indicating the root cause candidate (monitored node 30) corresponding to the cause node ID in step 1016.
  • Failure analysis context ID 2032 to storage ID 2038 are failure analysis context ID 601 to storage ID 607 in the failure analysis context (context determined in step 1024) corresponding to the cause node ID in step 1016.
  • the screen shown in FIG. 19 may be closed between step 1024 and the step. In this case, it is necessary to record the failure analysis context obtained in step 1024 in a storage device such as a memory before closing the screen of FIG. 19 and read in this step.
  • Cause 2039 is a system administrator form in which the content of the cause of the failure is registered in a natural language by the system administrator using the input / output device 260.
  • the recovery method 2040 is a system administrator form in which the content of the recovery method from the failure is registered in a natural language by the system administrator using the input / output device 260.
  • the system administrator transmits the meta RCA rule ID 2033 to storage ID 2038, the cause 2039, and the recovery method 2040 to the failure history management program 125 by pressing the registration button after inputting the fields of the cause 2039 and the recovery method 2040.
  • Step 1041 The failure history management program 125 receives the meta RCA rule ID 2033 to storage ID 2038, the cause 2039, and the recovery method 2040 transmitted in Step 1040.
  • Step 1042 The failure history management program 125 registers the meta RCA rule ID 2033 to storage ID 2038, the cause 2039, and the recovery method 2040 received in Step 1041 in the failure history entry.
  • the program 125 allocates a failure history ID 701 to this record.
  • Step 1043 The failure history management program 125 creates a new record in the server weight information 800.
  • An initial value (for example, 100) is substituted for the server vendor 802 to the server continuous operation time 805 of the record, and the server weight ID is stored in the record.
  • the initial value may be another value as long as it indicates the weight of each element.
  • Step 1044 The failure history management program 125 creates a new record in the switch weight information 810.
  • An initial value (for example, 100) is assigned to the switch vendor 812 to the switch continuous operation time 815 in the record, and the switch weight ID is stored in the record.
  • the initial value may be another value as long as it indicates the weight of each element.
  • Step 1045 The failure history management program 125 creates a new record in the storage weight information 820.
  • An initial value (for example, 100) is assigned to the storage vendor 822 to the continuous operation time 825 of the record, and the storage weight ID is stored in the record.
  • the initial value may be another value as long as it indicates the weight of each element.
  • Step 1043 to Step 1045 an evaluation value for matching the failure analysis context is allocated to an arbitrary element of the hardware or software configuration of the monitoring target node and the setting contents of the failure analysis context. There should be processing.
  • FIG. 18A is a flow for acquiring the same and / or similar fault history entries from the fault history information.
  • Step 1025 If the number of failure history entries is 0, the context matching analysis program 124 ends this flow.
  • the program 124 executes Step 1022 when the number of failure history entries is one or more.
  • Step 1026 The program 124 searches for failure history information using the failure analysis context. Details of step 1026 will be described later with reference to FIG. 18B.
  • the program 124 transmits the search result information obtained in Step 1026 to the display computer 20.
  • the search result information includes, for example, failure history ID 701, meta RCA rule ID 702, expanded RCA rule ID 703, topology ID 704, server ID 705, switch ID 706, storage ID 707, server weight ID 708, switch weight ID 709, storage weight ID 710, cause 711, recovery method 712, and matching rate.
  • failure history ID 701 meta RCA rule ID 702
  • expanded RCA rule ID 703 topology ID 704
  • server ID 705 switch ID 706, storage ID 707, server weight ID 708, switch weight ID 709, storage weight ID 710, cause 711, recovery method 712, and matching rate.
  • server ID 705 for example, failure history ID 701, meta RCA rule ID 702, expanded RCA rule ID 703, topology ID 704, server ID 705, switch ID 706, storage ID 707, server weight ID 708, switch weight ID 709, storage weight ID 710, cause 711, recovery method 712, and matching rate.
  • other information may be
  • the screen display program 211 (display computer 20) receives the information transmitted in Step 1027 and displays it on the input / output device 260 (for example, a display device). At that time, the program 211 preferentially displays information with a high matching rate (for example, displays information in descending order (highest order) of the matching rate).
  • FIG. 20 shows the search result screen 2020 displayed in step 1028.
  • This screen 2020 is an example of a search result screen.
  • the history ID is an identifier (for example, a serial number) assigned to the searched search history.
  • the failure history ID 2022 is the failure history ID 701 of the hit failure history entry.
  • the failure history node name 2023 is the server name 502 in the server record, the switch name 512 in the switch record, or the storage name 522 in the storage record. Records having those elements 502, 522, or 512 have an ID that matches the cause node ID 554.
  • the cause node ID 554 is in the expanded RCA record having the expanded RCA rule ID 551 that matches the expanded RCA rule ID 703 of the hit failure history entry.
  • Cause 2024 is a cause 711 of the hit failure history entry.
  • the recovery method 2025 is a recovery method 712 included in the hit failure history entry.
  • the matching rate 2026 indicates the matching rate transmitted from the context matching analysis program 124 in step 1027. Search results are displayed in descending order of the matching rate.
  • search result screen instead of or in addition to the information elements shown in FIG. 20, other types of information elements related to the failure history search results may be displayed.
  • FIG. 24A shows a first example of the matching degree comparison screen.
  • the display area e01 Details of the information regarding the failure that has occurred this time are displayed in the display area e01.
  • the meta RCA rule ID 541 corresponding to the current failure, the node name 502, 512 or 522 of the event that has occurred, and the event content 565 are displayed.
  • the details of the selected failure history are displayed in the display area e02.
  • the failure history meta RCA rule ID 541, the node name 502, 512 or 522 of the event that has occurred, and the event content 565 are displayed.
  • a matching rate 2026 between the current failure and the failure history is displayed.
  • a failure history recovery method 2025 is displayed.
  • FIG. 24A shows a second example of the matching degree comparison screen.
  • a diagram based on event information, topology information, and node information regarding the current failure is displayed.
  • the figure shows how the connections between the nodes are and what events occur on which nodes.
  • there are three blocks in the display area e05 each block corresponds to one of the nodes, and the connection between the blocks follows the topology specified from the topology information.
  • the character string displayed in the box represents the node name of the node corresponding to the block and the contents of the event (failure) that occurred in the node.
  • a diagram based on event information, topology information, and node information is displayed regarding the failure history. Specifically, for example, three blocks are displayed in the display area e06, and each block corresponds to one of the nodes as in the display area e05.
  • the portion that matches each other (the portion that matches the meta RCA rule) of the information displayed in the display area e05 and the information displayed in the display area e06 is indicated by a method such as enclosing with a broken line.
  • the system administrator can visually grasp the difference between the failure history selected by the system administrator and the current failure. Specifically, it can be seen that the failure that has occurred this time does not cause an IO error in the node with the node name “BOTAN”, compared to the selected failure history.
  • FIG. 18B shows details of step 1026 of FIG. 18A.
  • Step 1031 The context matching analysis program 124 performs meta RCA rule matching as the processing of Step 1031. Details of step 1031 will be described later with reference to FIG. 18C.
  • the context matching analysis program 124 transmits a failure history entry search request including a specific failure analysis context to the failure history management program 125.
  • the “specific failure analysis context” is a failure analysis context having a meta RCA rule ID equal to the meta RCA rule ID of the failure analysis context 119 obtained in step 1024.
  • Step 1102 The failure history management program 125 receives the search request transmitted in Step 1101.
  • Step 1103 In response to the search request received in Step 1102, the failure history management program 125 searches for a failure history entry having the specific failure analysis context.
  • the program 125 transmits information representing the search result to the context matching analysis program 124.
  • the transmitted information includes information registered in the failure history entry including a specific failure analysis context.
  • Step 1104 The context matching analysis program 124 receives the information transmitted in Step 1103.
  • Step 1033 The context matching analysis program 124 executes Step 1034 when the number of failure history entries obtained in Step 1031 is less than a first threshold (for example, 10). On the other hand, when the number of failure history entries obtained in step 1031 exceeds the second threshold (for example, 50), the program 124 executes step 1035.
  • the second threshold value is equal to or greater than the first threshold value. If the number of failure history entries obtained in step 1031 is an appropriate number (for example, not less than the first threshold value and not more than the second threshold value), this flow ends.
  • Step 1034 The program 124 performs processing for obtaining more fault history entries than the step 1031 by relaxing the search conditions. Specifically, the process shown in FIG. 18D is performed.
  • a failure analysis context that is a search query has a plurality of meta RCA rules (that is, when an expanded RCA rule is composed of multi-stage inference of meta RCA rules)
  • the context matching analysis program 124 has k meta RCA rule IDs 702 equal to a plurality of meta RCA rule IDs 602 included in a failure analysis context (failure analysis context serving as a search key) 119 (k is a natural number).
  • the failure history entry search request having the above is transmitted to the failure history management program 125. Note that the value of k can be arbitrarily set by the system administrator.
  • Step 1112 The failure history management program 125 receives the search request transmitted in Step 1111.
  • Step 1114 The context matching analysis program 124 receives the information transmitted in Step 1113. Note that the number of pieces of information to be transmitted (the number of failure history entries to be search hits) may be suppressed to an appropriate number (for example, a first number and / or a second number described later) or less.
  • the search method is not limited to the method described above, and other methods may be employed.
  • a meta RCA rule hereinafter, referred to as a meta RCA rule identified from the meta RCA rule ID in the failure analysis context of the search source.
  • the failure history management program 125 A failure history entry having the ID of the second meta RCA rule whose matching rate with one meta RCA rule is X% or more (X is a natural number) may be a search hit target.
  • the matching rate is based on the degree of overlap between the event group belonging to the first meta RCA rule and the event group belonging to the second meta RCA rule. Specifically, for example, the first ratio of the number of duplicated events to the total number of events belonging to the first meta RCA rule, and the number of duplicated events to the total number of events belonging to the second meta RCA rule.
  • the matching rate is calculated based on at least one of the two ratios.
  • the first meta RCA rule displayed in the display area e05 and the second meta RCA rule displayed in the display area e06 partially match.
  • Step 1035 The context matching analysis program 124 performs the process shown in FIG. 18F.
  • Matching evaluation is, for example, the following (A) and (B): (A) Monitored node hardware or software configuration specified from the failure analysis context of the search source, and elements of setting contents; (B) Hardware or software configuration of the monitoring target node identified from the failure history entry, and elements of the setting contents, Based on the degree of agreement of each other.
  • Step 1121 The context matching analysis program 124 transmits to the failure history management program 125 a search request including the meta RCA rule ID (first meta RCA rule ID) of the failure analysis context 119 obtained in step 1024. .
  • Step 1122 The program 125 receives the search request transmitted in Step 1101.
  • Step 1123 The program 125 performs a search in response to the search request received in Step 1102, and records it in the failure history entry having the meta RCA rule ID equal to the first meta RCA rule ID in the context matching analysis program 124. Information being sent.
  • Step 1124 The context matching analysis program 124 receives the information transmitted in Step 1103.
  • Step 1125 The program 124 performs the following processing (A) to (D): (A) Server record identified from at least one of the server record, switch record, and storage record identified from the ID in the failure analysis context of the search source, and the ID in the failure history entry obtained in step 1124 , A value that matches or approximates each other is extracted from at least one of the switch record and the storage record (for example, if the continuous operation time is within 3000, the values are approximate to each other).
  • each item corresponding to each value obtained in (A) is extracted from the server weight information 800, switch weight information 810, and storage weight information 820 included in the failure history information;
  • a matching rate corresponding to the cumulative weight value to each fault history entry obtained in step 1124 (for example, a fault history entry with a high cumulative weight value is assigned a high matching rate, and the cumulative weight value Low failure history entries are assigned a low matching rate) I do.
  • other elements may be considered instead of or in addition to the cumulative weight value.
  • Step 1126 The program 124 rearranges the failure history entries in descending order of the matching rate obtained in Step 1125. By performing this process, the system administrator can refer to the failure that occurred this time and the failure history having a high matching rate in order.
  • Step 1127 In the comparison process of Step 1125, the program 124 selects the item of the value extracted in Step 1125 from the information 800, 810 and 820 included in the failure history information (hereinafter, in the description of FIGS. 18F and 18G, The weight corresponding to the “target item”) is relatively increased. “To relatively increase” may be to increase the weight corresponding to the target item, or to decrease the weight corresponding to the non-target item.
  • the program 124 transmits an update request including the identification information (for example, name) of the item whose weight has been changed and the updated weight (and / or change amount) to the failure history management program 125.
  • Step 1129 The failure history management program 125 updates at least one of the information 800, 810, and 820 in the failure history information in response to the update request. That is, the weight calculated in step 1127 is reflected in the corresponding record in the information 800, 810, and 820 in the failure history information.
  • the failure analysis context (or search query) of the search source includes a value representing the weight of each attribute other than the type of the node device for each node device belonging to the expanded RCA rule (or topology) specified from the context. .
  • the vendor and the OS match among the multiple types of attributes. For this reason, the cumulative value for the first failure history entry is the sum “130” of the weight “50” for the vendor and the weight “80” for the OS.
  • the cumulative value for the second failure history entry is the sum “30” of the weight “20” for the IP address and the continuous operation time “10”.
  • the first failure history entry has a higher similarity with the search source failure analysis context than the second failure history entry.
  • the weights of these attributes are set to higher values in step 1127.
  • the weight of the attribute corresponding to each value included in the failure analysis record including the information indicating the recovery method selected by the system administrator is greater. It may be a high value.
  • the system administrator identifies the recovery method for the failure that occurred this time from the failure history information as described above. After finishing the recovery of the failure that has occurred this time, the system administrator performs the flow of FIG. 17 using this event as the failure history. As a result, the failure analysis context corresponding to the failure that has occurred this time, information that represents the root cause of the failure that has occurred this time, and information that represents the recovery method that has been taken this time are associated.
  • Step 1124 and the subsequent steps may be performed based on the information obtained in step 1031 of FIG. 18B.
  • the failure history entry includes a failure analysis context corresponding to the failure that has occurred, in addition to the information indicating the root cause of the failure that has occurred and the information that represents the recovery method according to the root cause.
  • the failure analysis context is information including information (hereinafter, rule specifying information) for specifying the cause / result rule that is the basis of the root cause of the failure among the plurality of cause / result rules.
  • the cause / result rules are the following (x) and (y): (X) The type of node device and the content of the event that occurred as the root cause; (Y) As a result, the type of the node device and the content of the event that occurred (what type of event occurred in which type of node device), Represents the correspondence relationship.
  • a search query including a failure analysis context corresponding to the occurred failure is input from the system administrator to the management server.
  • the management server sends a failure analysis context (first failure analysis context) included in the search query and a failure analysis context (second failure analysis context) in each failure history entry included in the failure history information. )
  • first failure analysis context included in the search query
  • second failure analysis context failure analysis context
  • the management server displays information registered in the specified second failure history entry (information including information indicating the recovery method). As a result, the system administrator can quickly specify a recovery method from the failure that has occurred.
  • a new failure history entry including the first failure analysis context corresponding to the failure that has occurred and information indicating the identified recovery method can be registered.
  • This registration operation may be performed manually by the system administrator or automatically by the management server.
  • the management server includes a failure history entry including the first failure analysis context used in the search, information indicating the specified root cause, and information indicating the specified recovery method. Can be registered.
  • a failure history entry including a second failure analysis context similar to the first failure analysis context which type of node is based on the rule specifying information in the first and second failure analysis contexts Information indicating what event has occurred in the device is specified. That is, the node device types are compared with each other. For this reason, even if the node devices in which the event having the same content has occurred are different, if the type of the node device is the same, the second failure analysis context is similar to the first failure analysis context. Thus, for example, if a previous event occurred on server A and this event occurred on server B this time, a failure history entry including the second failure analysis context corresponding to the previous failure is found as a search hit. May be subject to In other words, it is possible to hit similar items.
  • a fault including a second fault analysis context associated with a cause / result rule that completely matches the cause / result rule specified from the first fault analysis context A history entry becomes the target of a search hit.
  • the search is performed again with relaxed conditions. Specifically, for example, if the cause / result rules are similar to each other with a predetermined similarity (but less than 100%), the search history record becomes a hit.
  • the search history record becomes a hit.
  • the search history record Becomes a hit.
  • the management system includes a function that assists in metasizing and registering a recovery method procedure as a meta recovery method, a function that associates the meta recovery method with a meta RCA rule, and a root cause reference time. And a function for displaying the meta-recovery method together.
  • the management system displays an identifier such as the IP address of a node that has failed in the past, and the system administrator replaces the displayed recovery method information with the node that has failed this time. I do.
  • the management system displays the recovery method using the identifier of the node where the failure has occurred this time.
  • the system administrator can specify a recovery method candidate that can be taken when referring to the root cause.
  • ⁇ 2-1 Difference in Configuration of Embodiment 2 from Embodiment 1> Information indicating a meta recovery method (described later) is associated with the meta RCA rule information 115 (meta RCA record) of the first embodiment.
  • a meta recovery method registration screen (FIG. 22A) is added to the failure history registration screen (FIG. 21), and a step of registering the meta recovery method is added.
  • step 1020 of the first embodiment information indicating the meta-recovery method is added to the root cause candidate list and the certainty factor screen (FIG. 19) (FIG. 23).
  • Metal recovery method is a recovery method defined by a combination of finite elements (objects) provided by the management system.
  • the meta recovery method is a method that does not depend on a specific node, and can be registered in association with the meta RCA rule.
  • the format of the information is not limited as long as the recovery method can be defined.
  • the meta-recovery method is defined by a combination of one or more of three elements, Arc, Branch, and Command.
  • Arc indicates a transition between Branch or Command.
  • Branch indicates a conditional branch.
  • Common indicates processing.
  • Registration of the meta-recovery method is performed, for example, at a timing immediately before transmitting the failure history registration information in step 1040 in the first embodiment.
  • FIG. 22A shows an example of a meta recovery method registration screen.
  • icons of Arc, Branch, and Command are installed in the display area e11.
  • the system administrator can place an icon in the display area e12 by dragging and dropping any icon to the display area e12.
  • Fig. 22Ae02 is an edit screen for defining the meta recovery method. By arranging the icons in the display area e01, the configuration of the meta recovery method can be defined.
  • the display area e13 is a window for performing detailed setting of each icon installed in the display area e12. This figure shows an example of the Branch setting screen.
  • the display area e14 shows the identifier of the icon.
  • the display area e15 is a form for selecting a condition target in a conditional branch. Selection items are finite elements provided by the system.
  • the display area e16 is a form for selecting the content of the condition in the conditional branch. Selection items are finite elements provided by the system.
  • the display area e17 defines a transition destination when the condition defined in the display area e16 is true and a transition destination when the condition is false.
  • the display area e18 is a form for inputting details of branch contents that cannot be expressed only by the display area e16.
  • the information is registered in a natural language by the system administrator.
  • the display area e13 shown in FIG. 23B shows an example when the display area e13 is a command setting screen.
  • the display area e14 shown in FIG. 23B indicates the identifier of the icon.
  • the display area e15 shown in FIG. 23B is a form for selecting a processing target. Selection items are finite elements provided by the system.
  • the display area e16 shown in FIG. 23B is a form for selecting the content of processing. Selection items are finite elements provided by the system.
  • the display area e17 shown in FIG. 23B is a form for inputting details of processing contents that cannot be expressed only by the display area e16.
  • the information is registered in a natural language by the system administrator.
  • the meta recovery method definition defines the flow of object transitions from the start to the end of recovery. Specifically, it is defined which object (conditional branching or processing) to which object the transition is made to.
  • the acquisition of the meta recovery method is performed, for example, immediately after extracting the meta RCA rule in step 1015 in the first embodiment. Since the meta-recovery method is registered in association with the meta-RCA rule, when the meta-RCA rule is determined, the meta-recovery method is also determined.
  • step 1019 in the first embodiment the meta recovery method is also transmitted.
  • step 1020 in the first embodiment the meta recovery method is displayed in addition to the root cause and the certainty factor.
  • FIG. 23 is an example of a candidate / confidence screen displayed in the second embodiment.
  • a list of the display area e21 which is a table showing the accumulated processing contents of the command and a list of command processes of the meta restoration method is listed.
  • a column e22 which is the selected column is added.
  • a meta recovery method defined by a series of flows using common parts such as conditional branch (Branch) and treatment (Command) is prepared.
  • the meta recovery method is associated with the meta RCA rule of the combination of the event group and the root cause. As a result, it is possible to define from the detection of the occurred failure to the recovery method as one rule.
  • the present embodiment is an embodiment of the present invention to which the general-purpose rule base system of Non-Patent Document 1 described above is applied.
  • Non-Patent Document 1 discloses a general-purpose rule base system having a rule memory and a fact memory on a rule base system.
  • the rule memory stores general-purpose rules described without depending on a specific individual.
  • the fact memory stores specific information of a specific individual.
  • the rule base system is a system for deriving new facts using the rules and the information.
  • Causality Rule is a rule that describes the relationship between an event and its cause without depending on a specific topology. Specific examples of the Causality Rule are as follows.
  • Topology Rule is a rule that describes the connection state of a node without depending on a specific topology.
  • a specific example of Topology Rule is as follows.
  • T-RULE-200 IF FC-connected (x, y) & FC-connected (z, y) THEN FC-connected (x, z).
  • the topology application program 121 stores the Causality Rule and Topology Rule in the rule memory on the rule base system.
  • the topology application program 121 detects the following topology fact by applying the Topology rule to the monitoring target node 30, and stores it in the fact memory on the rule base system.
  • TF1 Serer (“ServerA”)
  • TF2 Storage (“Storage A”)
  • TF3 Switch (“SwitchA”)
  • TF4 FC-Connected (“ServerA”, “ABC”)
  • TF5 FC-Connected (“AMS1000”, “ABC”).
  • the rule base system creates an instance like the following example by combining Causality Rule and topology fact.
  • C-RULE-100-INSTANCE-1 IF EventHappensOn (IO_ERROR, “ServerA”, t1) & EventHappensOn (CTRL_FAIL, “StorageA”, t2) & WithTimeTimeWindow (t1, t2, “10 minutes”) THEN IdentifyRootCause (CTRL_FAIL, “StorageA”).
  • C-RULE-100-INSTANCE-1 is also stored in the memory.
  • the topology application program 121 When the topology application program 121 monitors the monitoring target node 30 and observes that the “ServerA” IO_ERROR event and the “StorageA” CTRL_FAIL event occur within the event correlation processing time width, the topology application program 121 stores the following event fact in the memory for the rule-based system.
  • EF1 EventHappensOn (IO_ERROR, "ServerA”, “12:32:12 22009/03/10"
  • EF2 EventHappensOn (CTRL_FAIL, "AMS1000", “12:32:10 22009/03/10"
  • EF3 WithinTimeWindow ("12:32:10 22009/03/10", "12:32:12 22009/03/10 ",” 10 minutes ").
  • the rule-based system derives IdentifyRootCause (CTRL_FAIL, “StorageA”) from C-RULE-100-INSTANCE-1 and event facts, thereby identifying the root cause.
  • CRL_FAIL IdentifyRootCause
  • C-RULE-100-INSTANCE-1 is the expanded RCA rule
  • C-RULE-100 (Causality Rule) corresponds to the meta RCA rule
  • C-RULE-100 becomes the meta RCA rule ID 541.
  • Multi-stage inference may be performed using a plurality of Causality Rules, and there may be a plurality of meta RCA rules.
  • the Causality Rule corresponding to the meta RCA rule used to derive the root cause and the instance corresponding to the expanded RCA rule are acquired and handled as a fault analysis context.
  • the effects of the invention can be obtained.
  • a general rule-based system can be applied.
  • the following storage format may be employed as the data structure of the expanded RCA rule information.
  • All combination patterns are stored for an event that occurs in a monitoring target node and that is to be managed by the management system (including a node device) and an event that distinguishes the event contents.
  • the root cause can be identified among the combinations of (A)
  • the occurrence site including the node device
  • the event contents are stored in association with each other.
  • an interface that communicates with a plurality of node devices, a processor that detects an event that occurs in the plurality of node devices via the interface, event information, and a meta rule A management system comprising a storage resource for storing information, failure history information, a display device for displaying information about the plurality of node devices, and an input device:
  • the event information includes an event entry indicating information for identifying a node device that has generated the event and a type of the event that has occurred.
  • the meta-rule information indicates the type of latent event that may potentially occur in the node device, and the type of event that can be identified as the root cause when an event corresponding to the type of the latent event occurs.
  • Meta rules *
  • the failure history information includes a failure history entry including information indicating a recovery method and information for identifying the meta-rule corresponding to the recovery method.
  • the processor is: (A) Based on the meta rule information, a first cause event that is a root cause of the first event specified by the event entry stored in the event information is specified, and is used for specifying the first cause event. Identify the first meta-rule that was (B) A first recovery method, which is a method of recovering from the first cause event, is received via the input device, and the failure history information includes the first recovery method based on the first recovery method.
  • the display device (X) displaying information about the second cause event as a root cause of the second event; (Y) displaying a recovery method from the second cause event based on the predetermined failure history entry;
  • the management system characterized by this was explained.
  • the failure history entry includes an identifier of a node device to which the recovery method is applied, and the display device: (Z)
  • the identifier of the node device indicated by the predetermined failure history entry may be displayed as the identifier of the node device to which the recovery method indicated by the predetermined failure history entry of (Y) is applied.
  • the management system may be configured such that when the first cause event generation node device and the second cause event generation node device are different node devices, the display device: (A) As a display of information on the second cause event in (X), information including an identifier of the node device that has generated the second cause event is displayed. (B) The identifier of the node device that has generated the first cause event may be displayed as the identifier of the node device indicated by the predetermined failure history entry in (Z).
  • the identification of (D) is as follows: (D1) Select the failure history entry indicating the same meta rule as the second meta rule, (D2) When the number of failure history entries selected in (D1) is less than a first threshold, the predetermined number is determined based on a matching rate between a meta rule corresponding to the failure history entry and the second meta rule. Identify fault history entries for (D3) The failure history entry selected in (D1) may be specified as the predetermined failure history entry.
  • the storage resource stores configuration setting information of the plurality of node devices
  • the failure history entry includes past configuration setting information corresponding to the entry creation time of the plurality of node devices
  • the storage resource may store weight information indicating a weight value for an item of configuration setting information, and the identification of (D4) may be performed based on the weight information.
  • the first recovery method of (B) is a meta recovery method that is a recovery method that does not include the identifier of the node device that generated the first cause event, and the second cause of (Y)
  • the display of the recovery method from the event may be a display of the meta recovery method and the identifier of the node device that has generated the second cause event.
  • Storage resources may be inside or outside the management system. If in, the storage resource is, for example, a memory. When the storage resource is outside, the storage resource is, for example, a storage device (for example, a disk array device).

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Computer Hardware Design (AREA)
  • Data Exchanges In Wide-Area Networks (AREA)
  • Debugging And Monitoring (AREA)

Abstract

　管理サーバは、複数のノード装置で発生しうるイベントについて、根本原因となる事象を特定するメタルールと、メタルールに対応させた障害復旧方法と、を有し、管理サーバが検知したイベントの根本原因となる原因イベントを表示すると共に、この原因イベントからの復旧方法を表示する。

Description

障害の根本原因に対応した復旧方法を表す情報を出力する管理システム
　本発明は、障害からの復旧方法を表す情報の出力に関する。
　昨今のインターネットビジネスの本格化に伴い、システムの障害によるサービスの停止が招く企業信用力の低下や機会損失の問題が大きくなってきている。そのため、障害から迅速に復旧することが望まれる。
　復旧方法を特定することを支援するためのシステムとして、例えば、特許文献１に開示の障害履歴データベースシステムがある。システム管理者が、監視対象ノードにて発生した障害と実際に障害から復旧させた方法とを、障害履歴として、そのデータベースシステムに登録する。データベースシステムは、複数の障害履歴を保持する。監視対象ノードの管理者（以下、「システム管理者」と言うことがある）は、新たに障害が発生した場合、所望のキーワードを入力する。データベースシステムは、入力されたキーワードに適合する障害履歴を、複数の障害履歴から検索する。
　一方、監視対象ノードの稼働状況を監視するために、監視システムがある。監視システムは、監視対象ノードの稼働状態の変化（例えば、ディスク装置に対する入出力（Ｉ／Ｏ）のエラー、及び、プロセッサのスループット低下）を、その監視対象ノードからイベントとして受け取る。システム管理者は、メッセージやパトランプを用いてそのイベントを受け取ることで、そのイベントの内容を知る。管理者は、そのイベントの内容から、その監視対象ノードの障害（例えば、サービスの停止や性能低下）を知り、その障害の根本原因を予測する。
　また、障害の根本原因を予測する技術として、Root Cause Analysis（以後、ＲＣＡと呼ぶ）がある。監視システムは、イベント群と根本原因との組み合わせをルールとして予め保持しておき、イベントを受け取った場合、そのイベントを含んだルールから、そのイベントの根本原因を推測する。
　特許文献２によれば、発生したイベントが既知の場合と未知の場合のそれぞれの場合について、不整合量が算出され、障害の根本原因の推測に、算出された不整合量が考慮される。
　特許文献３によれば、監視対象ノード間の環境の関係性を表す情報が構築される。障害の根本原因の推測の際には、その情報を基に、或る監視対象ノードで発生した障害がどの監視対象ノードに影響を与えるかが特定される。
特開２００９－４３０２９号公報 特開２００６－５２６８４２号公報 米国特許第７，４７８，４０４号明細書
Ｆｒｅｄｅｒｉｃｋ　Ｈａｙｅｓ－Ｒｏｔｈ，　"Ｒｕｌｅ－Ｂａｓｅｄ　ｓｙｓｔｅｍｓ"，　Ｃｏｍｍｕｎｉｃａｔｉｏｎｓ　ｏｆ　ｔｈｅ　ＡＣＭ，　Ｓｅｐｔ．　１９８５，　ｐａｇｅ９２１－９３２
　しかし、特許文献１乃至３のいずれの技術でも、システム管理者は、障害からの適切な復旧方法を迅速に特定することができない。
　例えば、監視対象ノードが、スイッチＡと、スイッチＡに接続される通信インターフェース装置（通信Ｉ／Ｆ）を有するサーバＡであり、サーバＡが、スイッチＡを介して、ストレージ装置に対してＩ／Ｏを行うようになっており、サーバＡが有する通信Ｉ／Ｆ（例えばＮＩＣ（Network Interface Card））に障害が発生したとする。その障害により、サーバＡのＩ／Ｏスループットが異常値に達した第１のイベントと、スイッチＡのネットワークトラフィックが異常値に達した第２のイベントとが発生する。第１及び第２のイベントを含んだイベント群を監視システムが検知する。そのイベント群の内容が、システム管理者に送信される。この時、障害履歴データベースシステムには、同件は格納されていないが類件が格納されているとする「同件」とは、発生した障害（イベント群に相当する障害）と同じ障害を表す情報を含んだ障害履歴である。「類件」とは、発生した障害とは違う障害を表す情報を含んでいるが発生した障害からの復旧方法と同じ復旧方法を表す情報を含んでいる障害履歴である。
　特許文献１によれば、障害履歴の検索には、システム管理者所望のキーワードが用いられる。そのため、キーワード次第では、目的とする障害履歴がヒットしない、または、無関係の障害履歴が多数ヒットする可能性がある。
　特許文献２によれば、障害の根本原因を検索クエリとした場合、同件はヒットしても類件がヒットしない可能性がある。
　特許文献３によれば、根本原因としての障害が発生した監視対象ノード、もしくは、その障害による影響を受ける監視対象ノードが検索クエリとされた場合、無関係の障害履歴が多数ヒットする可能性がある。
　そこで、本発明の目的は、障害の根本原因に応じた適切な復旧方法をシステム管理者が迅速に特定できるようにすることにある。
　管理サーバは、複数のノード装置で発生しうるイベントについて、根本原因となる事象を特定するメタルールと、メタルールに対応させた障害復旧方法と、を有し、管理サーバが検知したイベントの根本原因となる原因イベントを表示すると共に、この原因イベントからの復旧方法を表示する。なお、復旧方法は、管理サーバを利用する管理者が入力した、前述の複数のノード装置で発生して復旧させた時に用いた復旧方法に基づいて作成又は更新された情報であってもよい。
図１は、実施例１に係る計算機システムの構成を示すブロック図である。 図２は、管理サーバの構成を示すブロック図である。 図３は、表示用計算機の構成を示すブロック図である。 図４は、サーバ情報の構成を示すブロック図である。 図５は、スイッチ情報の構成を示すブロック図である。 図６は、ストレージ情報の構成を示すブロック図である。 図７は、トポロジ情報の構成を示すブロック図である。 図８は、メタＲＣＡルール情報の構成を示すブロック図である。 図９は、展開ＲＣＡルール情報の構成を示すブロック図である。 図１０は、イベント情報の構成を示すブロック図である。 図１１は、障害分析コンテキストの構成を示すブロック図である。 図１２Ａは、障害履歴エントリの構成を示すブロック図である。 図１２Ｂは、サーバ重み情報の構成を示すブロック図である。 図１２Ｃは、スイッチ重み情報の構成を示すブロック図である。 図１２Ｄは、ストレージ重み情報の構成を示すブロック図である。 図１３は、展開ＲＣＡルールを作成するためのフロー図である。 図１４は、根本原因候補とその確信度を決定するためのフロー図である。 図１５は、障害分析コンテキストを作成するためのフロー図である。 図１６は、根本原因を選択するためのフロー図である。 図１７は、障害履歴を登録するためのフロー図である。 図１８Ａは、障害分析コンテキストのマッチングをするためのフロー図である。 図１８Ｂは、図１８Ａのステップ１０２６の詳細を表すフロー図である。 図１８Ｃは、図１８Ｂのステップ１０３１の詳細を表すフロー図である。 図１８Ｄは、図１８Ｂのステップ１０３４の詳細を表すフロー図である。 図１８Ｅは、障害分析コンテキストのマッチングの概要を示す図である。 図１８Ｆは、図１８Ｂのステップ１０３５の詳細を表すフロー図である。 図１８Ｇは、障害分析コンテキストのマッチングの概要を示す図である。 図１９は、候補／確信度画面の一例を示す。 図２０は、障害履歴の検索結果画面の一例を示す。 図２１は、障害履歴の登録画面の一例を示す。 図２２Ａは、実施例２で表示される、メタ復旧方法登録画面の一例を示す。 図２２Ｂは、メタ復旧方法登録画面における表示領域ｅ１３の別の一例を示す。 図２３は、実施例２で表示される候補／確信度画面の一例を示す。 図２４Ａは、マッチング度合比較画面の第１の例を示す。 図２４Ｂは、マッチング度合比較画面の第２の例を示す。
　以下に、本発明の幾つかの実施例を説明する。
　＜１－０：実施例１に係る計算機システム等の構成＞。
　図１は、本発明の実施例１に係る計算機システム１の構成に関するブロック図である。
　計算機システム１は、管理サーバ１０、表示用計算機２０、監視対象ノード３０を備える。なお、管理サーバ１０、表示用計算機２０、監視対象ノード３０は、それぞれ一台ずつが図示されているが、何台備わっていてもよい。
　監視対象ノード３０は、管理サーバ１０によって管理される装置である。なお、監視対象ノード２０の一例としては、サーバ計算機、ストレージ装置（例えばＲＡＩＤ構成を有するディスクアレイ装置）、ネットワークスイッチ（例えば、ＦＣ（Fibre Channel）スイッチ）、ルータ）、プロキシーサーバ等が考えられるが、他の装置であってもよい。
　管理サーバ１０は、一つ以上の監視対象ノード３０を管理する計算機である。
　表示用計算機２０は、管理サーバ１０から出力された情報を表示するためのディスプレイ画面を有する計算機である。
　管理サーバ１０、表示用計算機２０、監視対象ノード３０は、ネットワーク５０を介して相互に接続される。なお、管理サーバ１０と表示用計算機２０とを接続するネットワーク５０と、管理サーバ１０と監視対象ノード３０を接続するネットワーク５０は、同一のネットワークであるが、別々なネットワークであってもよい。
　また、管理サーバ１０と表示用計算機２０は一体であってもよい。管理サーバ１０を複数の計算機で構成し、管理サーバ１０が有する機能をそれら複数の計算機が有しても良い。なお、以後の説明では、管理サーバ１０と表示用計算機２０を構成する一つ以上の計算機を「管理システム」と記載することがある。管理サーバ１０が表示用情報を表示する場合は、管理計算機が管理システムである、また、管理サーバ１０と表示用計算機２０の組み合わせも管理システムである。
　図２は、管理サーバ１０の構成を示す。
　管理サーバ１０は、メモリ１１０、メモリインターフェース１６１、プロセッサ１４０及びネットワークインターフェース１５０を備える計算機である。メモリインターフェース１６１、プロセッサ１４０及びネットワークインターフェース１５０は、内部ネットワーク（例えばバス）１６０によって相互に接続される。
　プロセッサ１４０は、メモリインターフェース１６１を介してメモリ１１０にアクセスする。プロセッサ１４０は、メモリ１１０に記憶されるプログラムを実行することによって、各種処理を行う。以後の説明では、「プログラム」を主語として説明を行う場合があるが、プログラムは、プロセッサ１４０によって実行されることで、定められた処理をメモリ１１０及びネットワークインターフェース１５０を用いながら行うため、プロセッサ１４０を主語とした説明としてもよい。また、プログラムを主語として開示された処理は、管理サーバ１０等の計算機が行う処理としてもよい。また、プログラムの一部または全ては、専用ハードウェアによって実現されてもよい。
　また、各種プログラムは、プログラムソース（例えば、プログラム配布サーバ、又は、コンピュータ読取可能な記憶メディア（例えば可搬型のメディア））から各計算機にインストールされてもよい。
　メモリ１１０には、プロセッサ１４０によって実行されるプログラム、及び、プロセッサ１４０によって必要とされる情報等が記憶される。具体的には、例えば、メモリ１１０には、サーバ情報１１１、スイッチ情報１１２、ストレージ情報１１３、トポロジ情報１１４、メタＲＣＡルール情報１１５、展開ＲＣＡルール情報１１６、イベント情報１１７、障害履歴情報１１９、トポロジ適用プログラム１２１、ルールマッチング解析プログラム１２２、生成プログラム１２３、コンテキストマッチング解析プログラム１２４、及び障害履歴管理プログラム１２５が記憶される。更に、メモリ１１０には、アプリケーションプログラム（以下、ＡＰ）１３１及びＯＳ（Operating System）１３２が記憶される。
　ＡＰ１３１は、各種処理を実現するプログラムである。例えば、ＡＰ１１７は、データベース管理機能又はＷＥＢサーバ機能を提供する。ＯＳ１３２は、管理サーバ１０の処理の全体を制御するプログラムである。
　サーバ情報１１１は、一種の監視対象ノードであるサーバの構成情報を管理するための情報である。
　スイッチ情報１１２は、一種の監視対象ノードであるスイッチの構成情報を管理するための情報である。
　ストレージ情報１１３は、一種の監視対象ノードであるストレージ装置の構成情報を管理するための情報である。
　トポロジ情報１１４は、監視対象ノードであるサーバ、スイッチ及びストレージの接続構成（トポロジ）の情報を管理するための情報である。
　メタＲＣＡルール情報１１５は、メタＲＣＡルールを管理するための情報である。なお、メタＲＣＡルールについては、後述の＜１－１：用語定義＞で詳細を説明する。
　展開ＲＣＡルール情報１１６は、展開ＲＣＡルールを管理するための情報である。なお、展開ＲＣＡルールについては、後述の＜１－１：用語定義＞で詳細を説明する。
　イベント情報１１７は、監視対象ノードで発生したイベントのイベントレコードを管理するための情報である。
　障害履歴情報１１９は、一以上の障害履歴エントリで構成されている。一つの障害履歴エントリが、過去に発生した障害の原因を表す情報と、復旧方法を表す情報と、障害分析コンテキストとを含んでいる。少なくとも障害履歴情報１１９は、外部の記憶資源（例えば外部のストレージ装置）に格納されていても良い。その場合には、例えば、プロセッサ１４０は、ネットワークインターフェース１５０を介して障害履歴情報１１９にアクセスすることができる。
　トポロジ適用プログラム１２１は、メタＲＣＡルール情報１１５、サーバ情報１１１、スイッチ情報１１２、ストレージ情報１１３及びトポロジ情報１１４を用いて、展開ＲＣＡルール情報１１６を作成する。
　ルールマッチング解析プログラム１２２は、展開ＲＣＡルール情報１１６とイベント情報１１７を用いて、イベント情報１１７と関連するメタＲＣＡルール情報１１５と展開ＲＣＡルール情報１１６と確信度とを決定する。
　生成プログラム１２３は、メタＲＣＡルール情報１１５、展開ＲＣＡルール情報１１６、サーバ情報１１１、スイッチ情報１１２、ストレージ情報１１３及びトポロジ情報１１４を用いて、障害分析コンテキストを生成する。
　コンテキストマッチング解析プログラム１２４は、生成された障害分析コンテキストと、各障害履歴エントリ内の障害分析コンテキストのマッチングを行う。
　障害履歴管理プログラム１２５は、生成された障害分析コンテキストと、復旧方法を表す情報と、発生した障害の内容を表す情報とを含んだ障害分析コンテキストを生成し、障害分析コンテキストを、障害履歴情報１１９に含める。
　ネットワークインターフェース１５０は、別の計算機（例えば監視対象ノード）とネットワーク５０を介してデータの送受信を行う。
　なお、メモリ１１０に格納された各種プログラムは、必ずしも別々なプログラムコードである必要は無く、一つ以上のプログラムコードが、プログラムの処理を実現してもよい。
　また、メモリ１１０に代えて、他種の記憶資源（記憶装置）が採用されても良い。
　また、管理サーバ１０は、入出力装置を有してもよい。入出力装置の例としてはディスプレイとキーボードとポインタデバイスが考えられるが、これ以外の装置であってもよい。また、入出力装置の代替としてシリアルインターフェースやイーサーネットインターフェースを入出力装置として、当該インターフェースにディスプレイ又はキーボード又はポインタデバイスを有する表示用計算機を接続し、表示表情報を表示用計算機に送信したり、入力用情報を表示用計算機から受信することで、表示用計算機で表示を行ったり、入力を受け付けることで入出力装置での入力及び表示を代替してもよい。
　図３は、表示用計算機２０の構成を示す。
　表示用計算機２０は、メモリ２１０、プロセッサ２４０、ネットワークインターフェース２５０及び入出力装置２６０を有する（例えば、図２に示したようなメモリインタフェースは図示を省略している）。メモリ２１０、プロセッサ２４０、ネットワークインターフェース２５０及び入出力装置２６０は、内部ネットワーク２７０によって相互に接続される。
　プロセッサ２４０は、メモリ２１０に記憶されているプログラムを実行することによって、各種処理を行う。
　メモリ２１０には、プロセッサ２４０によって実行されるプログラム、及び、プロセッサ２４０によって必要とされる情報等が記憶される。具体的には、例えば、メモリ２１０には、画面表示プログラム２１１が記憶される。更に、メモリ２１０には、アプリケーションプログラム（以下、ＡＰ）２２１及びＯＳ（Operating System）２２２が記憶される。ＡＰ２２１は、各種処理を実現するプログラムである。例えば、ＡＰ２２１は、ＷＥＢクライアント機能を提供する。ＯＳ２２２は、表示用計算機２０の処理の全体を制御するプログラムである。
　画面表示プログラム２１１は、入出力装置２６０、例えばディスプレイ装置に情報を表示するプログラムである。
　ネットワークインターフェース２５０は、別の計算機（例えば管理サーバ１０）とネットワーク５０を介してデータの送受信を行う。
　入出力装置２６０の例としてはディスプレイとキーボードとポインタデバイスが考えられるが、これ以外の装置であってもよい。また、入出力装置２６０の代替として、シリアルインターフェースやイーサーネットインターフェースが、入出力装置として、当該インターフェースにディスプレイ又はキーボード又はポインタデバイスを有する表示用計算機が接続されても良い。表示用計算機２０が、表示用情報を管理サーバ１０から受信したり、入力用情報を管理サーバ１０に送信したりしても良い。
　また、管理サーバ１０が、第１及び第２の計算機を有し、第１の計算機が、トポロジ適用プログラム１２１、ルールマッチング解析プログラム１２２、及び生成プログラム１２３を実行し、第２の計算機が、コンテキストマッチング解析プログラム１２４及び障害履歴管理プログラム１２５を実行しても良い。この場合、サーバ情報１１１、スイッチ情報１２１、ストレージ情報１１３、トポロジ情報１１４、メタＲＣＡルール情報１１５及び展開ＲＣＡルール情報１１６は、第１の計算機が有し、イベント情報１１７及び障害履歴情報１１９は、第２の計算機が有しても良い。
　＜１－１：用語定義＞。
　以下に、実施例の説明で用いる用語の意味を記す。
　「イベント」は、監視対象ノード３０で発生した稼働状態の変化の事象である。
　「イベントレコード」は、イベントを特定するための情報である。イベントレコードは、例えば、イベントの種別を示す情報であるイベントタイプと、発生元の監視対象ノード３０の識別子と、イベントの内容を表す情報と、イベントの発生日時を表す情報とを含む。一つのイベントにつき一つのイベントレコードがある。
　「ＲＣＡ」は、Root Cause Analysisの略であり、監視対象ノード（例えば、サーバ、スイッチ、ストレージ装置）のイベントレコードを基に、イベントの根本原因としての監視対象ノードを特定するための機能である。
　「メタＲＣＡルール」は、或る障害とその障害により発生が想定されるイベント群とを定義したルールである。ＲＣＡにより用いられる。メタＲＣＡルールを用いることで、イベント群からその根本原因となる障害を導き出すことができる。メタＲＣＡルールは、一以上の監視対象ノードで構成されるトポロジを表すトポロジ情報を含まない情報（メタ情報）である。
　「展開ＲＣＡルール」は、メタＲＣＡルールを監視対象ノード毎に展開したルールである。ＲＣＡにより用いられる。
　「障害分析コンテキスト」は、障害を分析する際に用いられる情報である。障害分析コンテキストには、メタＲＣＡルール情報１１５内のレコード、展開ＲＣＡルール情報１１６内のレコード、サーバ情報１１１内のレコード、スイッチ情報１１２内のレコード、ストレージ情報１１３内のレコード、及び、トポロジ情報１１４内のレコードが関連付けられている。詳細は、図１１を参照して後に説明する。
　＜１－２：管理サーバが有する情報＞。
　以下、各種情報を説明するが、その際に、「識別子」、「名」、「ＩＤ」といった表現が用いられるが、これらは互いに置換が可能な識別情報である。
　＜１－２－１：サーバ情報＞。
　図４は、サーバ情報１１１を示す図である。
　サーバ情報１１１は、一つのサーバにつき一つのレコード（以下、サーバレコード）を有するテーブルである。サーバレコードは、サーバＩＤ５０１、サーバ名５０２、サーバのベンダ５０３、サーバのＩＰアドレス５０４、サーバのＯＳ５０５、及び、サーバの連続稼働時間５０６を属性値として有する一つのレコードである。以下、一つのサーバ（以下、図４の説明において「対象サーバ」と言う）を例に採り、情報要素５０１～５０６を説明する。
　サーバＩＤ５０１は、トポロジ適用プログラム１２１が監視対象ノード３０である対象サーバに割り当てた識別子である。
　サーバ名５０２は、対象サーバがもつコンピュータ名である。
　サーバのベンダ５０３は、対象サーバがもつ製造元名である。
　サーバのＩＰアドレス５０４は、ネットワーク上で対象サーバが割り当てられた識別子である。
　サーバのＯＳ５０５は、対象サーバにインストールされているＯＳ名である。
　サーバの連続稼働時間５０６は、対象サーバが最後に起動してから現在までの連続での稼働時間である。
　なお、サーバ情報１１１は、サーバに関する属性値を有するのであれば、テーブル以外のデータ構造でもよく、上記に記した属性値以外の属性値を有しても良い。また、サーバ情報１１１は、サーバＩＤ５０１以外の少なくとも一つの属性値を有しなくてもよい。
　＜１－２－２：スイッチ情報＞。
　図５は、スイッチ情報１１２を示した図である。
　スイッチ情報１１２は、一つのスイッチにつき一つのレコード（以下、スイッチレコード）を有するテーブルである。スイッチレコードは、スイッチＩＤ５１１、スイッチ名５１２、スイッチのベンダ５１３、スイッチのＩＰアドレス５１４、スイッチのタイプ５１５、及び、スイッチの連続稼働時間５１６を属性値とするレコードである。以下、一つのスイッチ（以下、図５の説明において「対象スイッチ」と言う）を例に採り、情報要素５１１～５１６を説明する。
　スイッチＩＤ５１１は、トポロジ適用プログラム１２１が監視対象ノード３０である対象スイッチに割り当てた識別子である。
　スイッチ名５１２は、対象スイッチがもつコンピュータ名である。
　スイッチのベンダ５１３は、対象スイッチがもつ製造元名である。
　スイッチのＩＰアドレス５１４は、ネットワーク上で対象スイッチが割り当てられた識別子である。
　スイッチのタイプ５１５は、対象スイッチの機種名である。
　スイッチの連続稼働時間５１６は、対象スイッチが最後に起動してから現在までの連続での稼働時間である。
　なお、スイッチ情報１１２は、スイッチに関する属性値を有するのであれば、テーブル以外のデータ構造でもよく、上記に記した属性値以外の属性値を有しても良い。また、スイッチ情報１１２は、スイッチＩＤ５１１以外の少なくとも一つの属性値を有しなくても良い。
　＜１－２－３：ストレージ情報＞。
　図６は、ストレージ情報１１３を示した図である。
　ストレージ情報１１３は、一つのストレージ装置につき一つのレコード（以下、ストレージレコード）を有するテーブルである。ストレージレコードは、ストレージＩＤ５２１、ストレージ名５２２、ストレージのベンダ５２３、ストレージのＩＰアドレス５２４、ストレージのファームウェア５２５、及び、ストレージの連続稼働時間５２６を属性値として有するレコードである。以下、一つのストレージ装置（以下、図６の説明において「対象ストレージ」と言う）を例に採り、情報要素５２１～５２６を説明する。
　ストレージＩＤ５２１は、トポロジ適用プログラム１２１が監視対象ノード３０である対象ストレージに割り当てた識別子である。
　ストレージ名５２２は、対象ストレージがもつコンピュータ名である。
　ストレージのベンダ５２３は、対象ストレージがもつ製造元名である。
　ストレージのＩＰアドレス５２４は、ネットワーク上で対象ストレージが割り当てられた識別子である。
　ストレージのファームウェア５２５は、対象ストレージにインストールされているファームウェア名である。
　ストレージの連続稼働時間５２６は、対象ストレージが最後に起動してから現在までの連続での稼働時間である。
　なお、ストレージ情報１１３は、ストレージ装置に関する属性値を有するのであれば、テーブル以外のデータ構造でもよく、上記に記した属性値以外の属性値を有しても良い。また、ストレージ情報１１３は、ストレージＩＤ５２１以外の少なくとも一つの属性値を有しなくても良い。
　＜１－２－４：トポロジ情報＞。
　図７は、トポロジ情報１１４を示した図である。
　トポロジ情報１１４は、一つのトポロジにつき一つのレコード（以下、トポロジレコード）を有するテーブルである。トポロジレコードは、トポロジＩＤ５３１、サーバＩＤ５３２、スイッチＩＤ５３３及びストレージＩＤ５３４を属性値とするレコードである。以下、一つのトポロジ（以下、図７の説明において「対象トポロジ」と言う）を例に採り、情報要素５３１～５３４を説明する。
　トポロジＩＤ５３１は、対象トポロジの識別子である。「トポロジ」とは、監視対象ノード３０同士の接続形態、言い換えれば、監視対象ノード３０の組合せである。具体的には、トポロジとして、監視対象ノードの種類と並びが定義されている。
　サーバＩＤ５３２は、対象トポロジが有するサーバのサーバＩＤ５０１である。
　スイッチＩＤ５３３は、対象トポロジが有するスイッチのスイッチＩＤ５１１である。
　ストレージＩＤ５３４は、対象トポロジが有するストレージ装置のストレージＩＤ５２１である。
　なお、トポロジ情報１１４は、監視対象ノード３０の接続形態に関する属性値を有するのであれば、テーブル以外のデータ構造でもよく、上記に記した属性値以外の属性値を有しても良い。本実施例では、トポロジは、典型的には、サーバ（計算機）がスイッチ（ネットワークスイッチ）を介してストレージ装置に接続されている接続形態である。このようなトポロジによれば、サーバは、ストレージ装置から提供される論理ボリュームを指定したＩ／Ｏコマンド（ライトコマンド又はリードコマンド）を発行する。Ｉ／Ｏコマンドは、スイッチを介してストレージ装置に届く。ストレージ装置は、そのＩ／Ｏコマンドに従い、そのコマンドで指定されている論理ボリュームに対するＩ／Ｏを行う。
　＜１－２－５：メタＲＣＡルール情報＞。
　図８は、メタＲＣＡルール情報１１５を示した図である。
　メタＲＣＡルール情報１１５は、一つのメタＲＣＡルールにつき一つのレコード（以下、メタＲＣＡレコード）を有するテーブルである。メタＲＣＡレコードは、メタＲＣＡルールＩＤ５４１、サーバイベント５４２、スイッチイベント５４３、ストレージイベント５４４、原因ノード５４５及び原因内容５４６を属性値として有するレコードである。以下、一つのメタＲＣＡルール（以下、図８の説明において「対象メタＲＣＡルール」と言う）を例に採り、情報要素５４１～５４６を説明する。
　メタＲＣＡルールＩＤ５４１は、ルールマッチング解析プログラム１２２が対象メタＲＣＡルールに割り当てた識別子である。
　サーバイベント５４２は、対象メタＲＣＡルールがもつサーバでのイベントの内容を表す情報である。
　スイッチイベント５４３は、対象メタＲＣＡルールがもつスイッチでのイベントの内容を表す情報である。
　ストレージイベント５４４は、対象メタＲＣＡルールがもつストレージ装置でのイベントの内容を表す情報である。
　原因ノード５４５は、対象メタＲＣＡルールがもつイベントの根本原因であるノードの種類を表す情報である。
　原因内容５４６は、対象メタＲＣＡルールがもつイベントの根本原因の内容を表す情報である。原因内容５４６と前述の原因ノード５４５との組合せが、イベント群の根本原因を表す。
　なお、メタＲＣＡルール情報１１５は、メタＲＣＡルールに関する属性値を有するのであれば、テーブル以外のデータ構造でもよく、上記に記した属性値以外の属性値を有してもよい。
　＜１－２－６：展開ＲＣＡルール情報＞。
　図９は、展開ＲＣＡルール情報１１６を示した図である。
　展開ＲＣＡルール情報１１６は、一つの展開ＲＣＡルールにつき一つのレコード（以下、展開ＲＣＡレコード）を有するテーブルである。展開ＲＣＡレコードは、展開ＲＣＡルールＩＤ５５１、メタＲＣＡルールＩＤ５５２、トポロジＩＤ５５３、原因ノードＩＤ５５４及び原因詳細５５５を属性値として有するレコードである。以下、一つの展開ＲＣＡルール（以下、図９の説明において「対象展開ＲＣＡルール」と言う）を例に採り、情報要素５５１～５５５を説明する。
　展開ＲＣＡルールＩＤ５５１は、ルールマッチング解析プログラム１２２が対象展開ＲＣＡルールに割り当てた識別子である。
　メタＲＣＡルールＩＤ５５２は、対象展開ＲＣＡルールが属するメタＲＣＡルールがもつメタＲＣＡルールＩＤ５４１である。
　トポロジＩＤ５５３は、対象展開ＲＣＡルールが属するトポロジがもつトポロジＩＤ５３１である。
　原因ノードＩＤ５５４は、対象展開ＲＣＡルールの根本原因となる監視対象ノード３０を同定するためのサーバＩＤ５０１、スイッチＩＤ５１１又はストレージＩＤ５２１である。
　原因詳細５５５は、対象展開ＲＣＡルールの根本原因の内容を表す原因内容５４６である。
　なお、展開ＲＣＡルール情報１１６は、展開ＲＣＡルールに関する属性値を有するのであれば、テーブル以外のデータ構造でもよく、上記に記した属性値以外の属性値を有してもよい。
　＜１－２－７：イベント情報＞。
　図１０は、イベント情報１１７を示した図である。
　イベント情報１１７は、一つのイベントにつき一つのイベントレコードを有するテーブルである。イベントレコードは、イベントＩＤ５６１、イベントタイプ５６２、対象ノードタイプ５６３、対象ノードＩＤ５６４、イベント内容５６５、発生日時５６６及び状態５６７を属性値として有するレコードである。以下、一つのイベント（以下、図１０の説明において「対象イベント」と言う）を例に採り、情報要素５６１～５６７を説明する。
　イベントＩＤ５６１は、ルールマッチング解析プログラム１２２が対象イベントのイベントレコードに割り当てた識別子である。
　イベントタイプ５６２は、対象イベントの種類を表す情報である。イベントタイプ５６２の具体的な値として、例えば、「Ｃｒｉｔｉｃａｌ」、「Ｗａｒｎｉｎｇ」、「Ｉｎｆｏｒｍａｔｉｏｎ」、がある。
　対象ノードタイプ５６３は、対象イベントの発生元である監視対象ノード３０のノードの種類（例えば、サーバ、スイッチもしくはストレージ装置）を表す情報である。
　対象ノードＩＤ５６４は、対象イベントの発生元である監視対象ノード３０を表すサーバＩＤ５０１、スイッチＩＤ５１１又はストレージＩＤ５２１である。
　イベント内容５６５は、対象イベントの内容を表す情報である。
　発生日時５６６は、対象イベントの発生日時を表す情報である。
　状態５６７は、対象イベントが解決済みか否かを表す情報である。
　なお、イベント情報１１７は、イベントに関する属性値を有するのであれば、テーブル以外のデータ構造でもよく、上記に記した属性値以外の属性値を有してもよい。また、イベント情報１１７は、イベントＩＤ５５１、対象ノードＩＤ５６４、イベント内容５６５及び発生日時５６６以外の少なくとも一つの属性値を有しなくても良い。
　＜１－２－８：障害分析コンテキスト＞。
　図１１は、障害分析コンテキスト１２０を示した図である。
　障害分析コンテキスト１２０は、障害分析コンテキストＩＤ６０１、メタＲＣＡルールＩＤ６０２、展開ＲＣＡルールＩＤ６０３、トポロジＩＤ６０４、サーバＩＤ６０５、スイッチＩＤ６０６及びストレージＩＤ６０７を属性値として有するデータである。
　障害分析コンテキストＩＤ６０１は、生成プログラム１２３が障害分析コンテキスト１２０に割り当てた識別子である。
　メタＲＣＡルールＩＤ６０２は、この障害分析コンテキスト１２０に関連付けられたメタＲＣＡルールを同定するためのメタＲＣＡルールＩＤ５４１である。
　展開ＲＣＡルールＩＤ６０３は、この障害分析コンテキスト１２０に関連付けられた展開ＲＣＡルールを同定するための展開ＲＣＡルールＩＤ５５１である。
　トポロジＩＤ６０４は、この障害分析コンテキスト１２０に関連付けられたトポロジを同定するためのトポロジＩＤ５３１である。
　サーバＩＤ６０５は、この障害分析コンテキスト１２０に関連付けられたサーバを同定するためのサーバＩＤ５０１である。
　スイッチＩＤ６０６は、この障害分析コンテキスト１２０に関連付けられたスイッチを同定するためのスイッチＩＤ５１１である。
　ストレージＩＤ６０７は、この障害分析コンテキスト１２０に関連付けられたストレージ装置を同定するためのストレージＩＤ５２１である。
　なお、障害分析コンテキスト１２０は、上記に記した属性値以外の属性値を有しても良い。
　＜１－２－９：障害履歴情報＞。
　図１２Ａは、障害履歴情報１１９が有する障害履歴エントリ１１９１を示した図である。
　障害履歴エントリ１１９１は、障害履歴ＩＤ７０１、メタＲＣＡルールＩＤ７０２、展開ＲＣＡルールＩＤ７０３、トポロジＩＤ７０４、サーバＩＤ７０５、スイッチＩＤ７０６、ストレージＩＤ７０７、サーバ重みＩＤ７０８、スイッチ重みＩＤ７０９、ストレージ重みＩＤ７１０、原因７１１及び復旧方法７１２を属性値として有するデータである。
　障害履歴ＩＤ７０１は、障害履歴管理プログラム１２５が障害履歴エントリ１１９１に割り当てた識別子である。
　メタＲＣＡルールＩＤ７０２は、この障害履歴エントリ１１９１に関連付けられたメタＲＣＡルールを同定するためのメタＲＣＡルールＩＤ５４１である。
　展開ＲＣＡルールＩＤ７０３は、この障害履歴エントリ１１９１に関連付けられた展開ＲＣＡルールを同定するための展開ＲＣＡルールＩＤ５５１である。
　トポロジＩＤ７０４は、この障害履歴エントリ１１９１に関連付けられたトポロジを同定するためのトポロジＩＤ５３１である。
　サーバＩＤ７０５は、この障害履歴エントリ１１９１に関連付けられたサーバを同定するためのサーバＩＤ５０１である。
　スイッチＩＤ７０６は、この障害履歴エントリ１１９１に関連付けられたスイッチを同定するためのスイッチＩＤ５１１である。
　ストレージＩＤ７０７は、この障害履歴エントリ１１９１に関連付けられたストレージ装置を同定するためのストレージＩＤ５２１である。
　サーバ重みＩＤ７０８は、この障害履歴エントリ１１９１に関連付けられたサーバ重みレコードを同定するためのサーバ重みＩＤ８０１（図１２Ｂ参照）である。サーバ重みレコードは、サーバ重み情報８００が有するレコードである。
　スイッチ重みＩＤ７０９は、この障害履歴エントリ１１９１に関連付けられたスイッチ重みレコードを同定するためのスイッチ重みＩＤ８１１（図１２Ｃ参照）である。スイッチ重みレコードは、スイッチ重み情報８１０が有するレコードである。
　ストレージ重みＩＤ７１０は、この障害履歴エントリ１１９１に関連付けられたストレージ重みレコードを同定するためのストレージ重みＩＤ８２１（図１２Ｄ参照）である。ストレージ重みレコードは、ストレージ重み情報８２０が有するレコードである。
　原因７１１は、この障害履歴エントリ１１９１に対応した障害の原因を表す情報である。
　復旧方法７１２は、この障害履歴エントリ１１９１に対応した障害からの復旧方法を表す情報である。
　障害履歴エントリ１１９１が有するＩＤ７０２～７０７は、障害分析コンテキスト１２０（図１１参照）が有するＩＤ６０２～６０７の複製である。つまり、前述したように、障害履歴エントリ１１９１は、障害分析コンテキスト１２０を有する。図１２Ａによれば、障害分析コンテキストＩＤ６０１は障害履歴エントリ１１９１に含まれていないが、そのＩＤ６０１がそのレコード１１９１に含まれても良い。
　障害履歴情報１１９は、障害履歴に関する属性値を有するのであれば、上述のデータ構造以外のデータ構造でもよく、上記に記した属性値以外の属性値を有しても良い。また、障害履歴情報１１９は、サーバ重みＩＤ７０８、スイッチ重みＩＤ７０９及びストレージ重みＩＤ７１０を有していなくても良い。
　＜１－２－１０：サーバ重み情報＞。
　図１２Ｂは、サーバ重み情報８００を示した図である。
　サーバ重み情報８００は、一つのサーバ重みにつき一つのレコード（サーバ重みレコード）を有するテーブルである。サーバ重みレコードは、サーバ重みＩＤ８０１、サーバのベンダ８０２、サーバのＩＰアドレス８０３、サーバのＯＳ８０４、及び、サーバの連続稼働時間８０５を属性値として有するレコードである。以下、一つのサーバ重み（図１２Ｂの説明において「対象サーバ重み」という）を例に採り、情報要素８０１～８０５を説明する。
　サーバ重みＩＤ８０１は、対象サーバ重みに割り当てられた識別子である。
　サーバのベンダ８０２は、対象サーバ重みに属する一種の重みであり、サーバのベンダという項目をどれだけ重要視するかを表す値である。
　サーバのＩＰアドレス８０３は、対象サーバ重みに属する一種の重みであり、サーバのＩＰアドレスという項目をどれだけ重要視するかを表す値である。
　サーバのＯＳ８０４は、対象サーバ重みに属する一種の重みであり、サーバのＯＳという項目をどれだけ重要視するかを表す値である。
　サーバの連続稼働時間８０５は、対象サーバ重みに属する一種の重みであり、サーバの連続稼働時間という項目をどれだけ重要視するかを表すである。
　以上の説明からわかるように、「サーバ重み」とは、サーバに関する複数種類の項目の重みで定義されている。
　なお、サーバ重み情報８００は、サーバ重みに関する属性値を有するのであれば、テーブル以外のデータ構造でもよく、上記に記した属性値以外の属性値も有しても良い。また、サーバ重み情報８００は、サーバ重みＩＤ８０１以外の少なくとも一つの属性値を有しなくても良い。
　＜１－２－１１：スイッチの重み情報＞。
　図１２Ｃは、スイッチの重み情報８１０を示した図である。
　スイッチ重み情報８１０は、一つのスイッチ重みにつき一つのレコード（スイッチ重みレコード）を有するテーブルである。スイッチ重みレコードは、スイッチ重みＩＤ８１１、スイッチのベンダ８１２、スイッチのＩＰアドレス８１３、スイッチのタイプ８１４、及び、スイッチの連続稼働時間８１５を属性値として有するレコードである。以下、一つのスイッチ重み（図１２Ｃの説明において「対象スイッチ重み」という）を例に採り、情報要素８１１～８１５を説明する。
　スイッチ重みＩＤ８１１は、対象スイッチ重みに割り当てられた識別子である。
　スイッチのベンダ８１２は、対象スイッチ重みに属する一種の重みであり、スイッチのベンダという項目をどれだけ重要視するかを表す値である。
　スイッチのＩＰアドレス８１３は、対象スイッチ重みに属する一種の重みであり、スイッチのＩＰアドレスという項目をどれだけ重要視するかを表す値である。
　スイッチのタイプ８１４は、対象スイッチ重みに属する一種の重みであり、スイッチのタイプという項目をどれだけ重要視するかを表す値である。
　スイッチの連続稼働時間８１５は、対象スイッチ重みに属する一種の重みであり、スイッチの連続稼働時間という項目をどれだけ重要視するかを表すである。
　以上の説明からわかるように、「スイッチ重み」とは、スイッチに関する複数種類の項目の重みで定義されている。
　なお、スイッチ重み情報８１０は、スイッチ重みに関する属性値を有するのであれば、テーブル以外のデータ構造でもよく、上記に記した属性値以外の属性値も有しても良い。また、スイッチ重み情報８１０は、スイッチ重みＩＤ８１１以外の少なくとも一つの属性値を有しなくても良い。
　＜１－２－１２：ストレージの重み情報＞。
　図１２Ｄは、ストレージ重み情報８２０を示した図である。
　ストレージ重み情報８２０は、一つのストレージ重みにつき一つのレコード（ストレージ重みレコード）を有するテーブルである。ストレージ重みレコードは、ストレージ重みＩＤ８２１、ストレージのベンダ８２２、ストレージのＩＰアドレス８２３、ストレージのファームウェア８２４、及び、ストレージの連続稼働時間８２５を属性値として有するレコードである。以下、一つのストレージ重み（図１２Ｄの説明において「対象ストレージ重み」という）を例に採り、情報要素８２１～８２５を説明する。
　ストレージ重みＩＤ８２１は、対象ストレージ重みに割り当てられた識別子である。
　ストレージのベンダ８２２は、対象ストレージ重みに属する一種の重みであり、ストレージのベンダという項目をどれだけ重要視するかを表す値である。
　ストレージのＩＰアドレス８２３は、対象ストレージ重みに属する一種の重みであり、ストレージのＩＰアドレスという項目をどれだけ重要視するかを表す値である。
　ストレージのファームウェア８２４は、対象ストレージ重みに属する一種の重みであり、ストレージのファームウェアという項目をどれだけ重要視するかを表す値である。
　ストレージの連続稼働時間８２５は、対象ストレージ重みに属する一種の重みであり、ストレージの連続稼働時間という項目をどれだけ重要視するかを表すである。
　以上の説明からわかるように、「ストレージ重み」とは、ストレージに関する複数種類の項目の重みで定義されている。
　なお、ストレージ重み情報８２０は、ストレージ重みに関する属性値を有するのであれば、テーブル以外のデータ構造でもよく、上記に記した属性値以外の属性値も有しても良い。また、ストレージ重み情報８２０は、ストレージ重みＩＤ８２１以外の少なくとも一つの属性値を有しなくても良い。
　前述したサーバ重み情報８００、スイッチ重み情報８１０およびストレージ重み情報８２０が、例えば障害履歴情報に含まれている。
　＜１－２－１３：各情報の抽象化＞。
　以下の説明では、サーバ、スイッチ及びストレージ装置で構成されたトポロジを一例として記載する。しかし、本発明は、そのようなトポロジに限らず他種のトポロジについても適用可能である。例えば、トポロジは、所定のネットワークサービスを提供するサービス提供ノード装置（一例がストレージ装置）と、その所定のネットワークサービスを利用するサービス利用ノード装置（一例がサーバ）が、監視対象ノードであればよい。そうした広い観点から考えると、各種情報は、以下の情報を有していれば良いことになる。
　サーバ情報（図４参照）は、より抽象的には、サービス利用ノード装置情報である。サービス利用ノード装置情報は、以下の情報（ａ１）～（ａ３）：
（ａ１）サービス利用ノード装置のIPアドレス等のネットワーク識別子；
（ａ２）当該ノード装置のハードウェア又はソフトウェアの構成を表す情報；
（ａ３）設定内容を表す情報、
を含むことができる。
　スイッチ情報（図５参照）は、より抽象的には、中継装置情報（または中継ノード装置情報）である。中継装置情報は、以下の情報（ｂ１）及び（ｂ２）：
（ｂ１）サービス利用ノード装置とサービス提供ノード装置との通信を仲介するノード装置（一例がスイッチ）のハードウェア又はソフトウェアの構成を表す情報；
（ｂ２）設定内容を表す情報、
を含むことができる。
　ストレージ情報（図６参照）は、より抽象的には、サービス提供ノード装置情報である。サービス提供ノード装置情報は、以下の情報（ｃ１）～（ｃ３）：
（ｃ１）サービス提供ノード装置のIPアドレス等のネットワーク識別子；
（ｃ２）当該ノード装置のハードウェア又はソフトウェアの構成を表す情報；
（ｃ３）設定内容を表す情報、
を含むことができる。また、サービス提供ノード装置情報は、サービス利用ノード装置が提供するネットワークサービスの種別を表す情報等を含んでも良い。
　トポロジ情報（図７参照）は、サービス利用ノード装置の識別子と当該サービス利用ノード装置が利用するサービス提供ノード装置の識別子との組（または対応関係）を表す情報を含むことができる。なお、サービス利用ノード装置と当該サービス利用ノード装置とが通信する際に一つ以上の中継装置を介するのであれば、それら一つ以上の中継装置の識別子がトポロジ情報に含まれても良い。
　メタＲＣＡルール情報（図８参照）は、管理サーバが監視対象とする各ネットワークサービスについて、以下の情報（ｄ１）及び（ｄ２）：
（ｄ１）サービス利用ノード装置で発生しうる第１のイベント（サービス利用ノード装置発生イベント）の種別と、サービス提供ノード装置（又は中継装置）で発生しうる第２のイベント（サービス提供ノード装置発生イベント）の種別との組み合わせを表す情報；
（ｄ２）第１のイベントと第２のイベントとが発生した場合の原因と決定できる（または原因と推定される）サービス提供ノード装置又は中継装置で発生しうる原因（または原因の種別）を示す情報、
を含むことができる。
　展開ＲＣＡルール情報（図９参照）は、ネットワークサービスを利用又は提供する各監視対象ノードについて、以下の情報（ｅ１）～（ｅ３）：
（ｅ１）サービス利用ノード装置であるノード装置で発生しうる第１のイベントの種別及びサービス利用ノード装置の識別子と、サービス提供ノード装置（又は中継装置）で発生しうる第２のイベントの種別及びサービス提供ノード装置（又は中継装置）の識別子との組み合わせを表す情報；
（ｅ２）第１のイベントと第２のイベントとが発生した場合の原因と決定できる（又は原因と推定される）サービス提供ノード装置（又は中継装置）の識別子；
（ｅ３）当該サービス提供ノード装置（又は中継装置）で発生しうる原因（または原因の種別）を示す情報、
を含むことができる。
　障害分析コンテキスト（図１１参照）は、障害の根本原因を特定するために用いたメタＲＣＡルールの識別子を含むことができる。なお、障害の根本原因を特定するために用いた展開ＲＣＡルールの識別子、トポロジの識別子又は監視対象ノードの識別子が含まれてもよい。
　障害履歴エントリ（図１２Ａ参照）は、障害分析コンテキストの内容と、そのコンテキストに対応した障害からの復旧方法（例えば復旧手順）を表す情報とを含むことができる。なお、障害履歴エントリは、そのレコードが有する障害分析コンテキストのマッチング度を評価するための評価値、又は、評価値が記録された情報の識別子を含んでも良い。
　サーバ重み情報（図１２Ｂ参照）は、サービス利用ノード装置のハードウェア又はソフトウェア構成及び設定内容の要素に振り分ける、マッチング度を評価するための値を含むことができる。
　スイッチ重み情報（図１２Ｃ参照）：中継装置のハードウェア又はソフトウェア構成及び設定内容の要素に振り分ける、マッチング度を評価するための値を含むことができる。
　ストレージ重み情報（図１２Ｄ参照）は、サービス提供ノード装置のハードウェア又はソフトウェア構成及び設定内容の要素に振り分ける、マッチング度を評価するための値を含むことができる。
　＜１－３：展開ＲＣＡルール作成＞。
　図１３は、展開ＲＣＡルールを作成するフローを示す。
　（ステップ１００１）トポロジ適用プログラム１２１は、ネットワーク５０を通じて、監視対象ノード３０から情報を取得する。監視対象ノード３０がサーバであれば、サーバ名、サーバのベンダ名、サーバのＩＰアドレス、サーバのＯＳ名、及び、サーバの連続稼働時間を含んだ情報（以下、サーバ取得情報）が取得される。トポロジ適用プログラム１２１は、各監視対象ノード（各サーバ）から受信したサーバ取得情報に基づいてサーバ情報１１１を作成又は更新する。具体的には、例えば、トポロジ適用プログラム１２１は、以下の処理（Ａ）及び（Ｂ）：
（Ａ）サーバ取得情報内の識別子がサーバ情報１１１に格納されていない場合、そのサーバ取得情報に対応した、サーバ情報１１１内のサーバレコード（以下、図１３の説明において「対象サーバレコード」と言う）に対して、サーバＩＤ５０１（例えば、サーバ取得情報内の識別子）を割り振り、そのサーバＩＤ５０１を対象レコードに格納する；
（Ｂ）サーバ取得情報内のサーバ名５０２、ベンダ名５０３、ＩＰアドレス５０４、ＯＳ名５０５及び連続稼働時間５０６を、対象サーバレコードに格納する、
を行う。
　なお、サーバ取得情報のデータ構造は、サーバ情報１１１を更新できるのであれば、上記構造に限られない。また、予めサーバでないことが明らかな監視対象ノードについてはステップ１００１が省略されてもよい。
　（ステップ１００２）トポロジ適用プログラム１２１は、ネットワーク５０を通じて、監視対象ノード３０から情報を取得する。監視対象ノード３０がスイッチであれば、スイッチ名、スイッチのベンダ名、スイッチのＩＰアドレス、スイッチのタイプ、及び、スイッチの連続稼働時間を含んだ情報（以下、スイッチ取得情報）が取得される。トポロジ適用プログラム１２１は、各監視対象ノード（各スイッチ）から受信したスイッチ取得情報に基づいてスイッチ情報１１２を作成又は更新する。具体的には、例えば、トポロジ適用プログラム１２１は、以下の処理（Ａ）及び（Ｂ）：
（Ａ）スイッチ取得情報内の識別子がスイッチ情報１１２に格納されていない場合、そのスイッチ取得情報に対応した、スイッチ情報１１２内のスイッチレコード（以下、図１３の説明において「対象スイッチレコード」と言う）に対して、スイッチＩＤ５１１（例えば、スイッチ取得情報内の識別子）を割り振り、そのスイッチＩＤ５１１を対象スイッチレコードに格納する；
（Ｂ）スイッチ取得情報のスイッチ名５１２、ベンダ名５１３、ＩＰアドレス５１４、タイプ５１５及び連続稼働時間５１６を、対象スイッチレコードに格納する、
を行う。
　なお、スイッチ取得情報のデータ構造は、スイッチ情報１１２を更新できるのであれば、上記構造に限られない。また、予めスイッチでないことが明らかな監視対象ノードについてはステップ１００２が省略されてもよい。
　（ステップ１００３）トポロジ適用プログラム１２１は、ネットワーク５０を通じて、監視対象ノード３０からから情報を取得する。監視対象ノード３０がストレージ装置であれば、ストレージ名、ストレージのベンダ名、ストレージのＩＰアドレス、ストレージのファームウェア名、及び、ストレージの連続稼働時間を含んだ情報（以下、ストレージ取得情報）が取得される。トポロジ適用プログラム１２１は、各監視対象ノード（各ストレージ装置）から受信したストレージ取得情報に基づいてストレージ情報１１３を作成又は更新する。具体的には、例えば、トポロジ適用プログラム１２１は、以下の処理（Ａ）及び（Ｂ）：
（Ａ）ストレージ取得情報内の識別子がストレージ情報１１３に格納されていない場合、そのストレージ取得情報に対応した、ストレージ情報１１３内のストレージレコード（以下、図１３の説明において「対象ストレージレコード」と言う）に対して、ストレージＩＤ５２１（例えば、ストレージ取得情報内の識別子）を割り振り、そのストレージＩＤ５２１を対象ストレージレコードに格納する；
（Ｂ）ストレージ取得情報のストレージ名５２２、ベンダ名５２３、ＩＰアドレス５２４、ファームウェア５２５及び連続稼働時間５２６を、対象ストレージレコードに格納する、
を行う。
　なお、ストレージ取得情報のデータ構造は、ストレージ情報１１２を更新できるのであれば、上記構造に限られない。また、予めストレージでないことが明らかな監視対象ノードについてはステップ１００３が省略されてもよい。
　（ステップ１００４）トポロジ適用プログラム１２１は、ネットワーク５０を通じて、監視対象ノード３０のトポロジ取得情報を受信する。トポロジ取得情報の一例として、スイッチのＩＤと、そのスイッチに接続されているサーバ及びストレージ装置のそれぞれのＩＤとを含む。具体的には、例えば、トポロジ適用プログラム１２１は、以下の処理（Ａ）及び（Ｂ）：
（Ａ）トポロジ取得情報内の識別子がトポロジ情報１１４に格納されていない場合、そのトポロジ取得情報に対応した、トポロジ情報１１４内のトポロジレコード（以下、図１３の説明において「対象トポロジレコード」と言う）に対して、トポロジＩＤ５３１（例えば、トポロジ取得情報内の識別子）を割り振り、そのトポロジＩＤ３２１を対象トポロジレコードに格納する；
（Ｂ）トポロジ取得情報内のスイッチＩＤ５３３、サーバＩＤ５３２及びストレージＩＤ５３４を、対象トポロジレコードに格納する、
を行う。
　なお、トポロジ取得情報のデータ構造は、トポロジ情報１１４を更新できるのであれば、上記構造に限られない。また、予めスイッチ、サーバ及びストレージ装置でないことが明らかな監視対象ノードについてはステップ１００４が省略されてもよい。また、トポロジレコードは、次のように更新されても良い。すなわち、各監視対象ノードから、どの監視対象ノードに直接接続されているかを表す接続先情報が取得され、且つ、サーバ又はストレージ装置から、どのサーバからどの論理ボリュームにアクセスされるかを表すパス情報が取得され、接続先情報及びパス情報を基に、対象トポロジレコードが更新されても良い。
　（ステップ１００５）トポロジ適用プログラム１２１は、トポロジ情報１１４とメタＲＣＡルール情報１１５とに基づいて、展開ＲＣＡルール情報１１６を作成する。より具体的には、このプログラム１２１が、以下の処理（ｘ）及び（ｙ）：
（ｘ）トポロジ情報１１４内のトポロジＩＤ５３１とメタＲＣＡルール情報１１５内のメタＲＣＡルールＩＤ５４１との全ての組み合わせを作成する（例えば、２つのトポロジＩＤ５３１と３つのメタＲＣＡルールＩＤ５４１がある場合、６つ（２×３＝６）の組合せを作成する）；
（ｙ）各組み合わせについて、展開ＲＣＡルールＩＤ５５１を割り振り、且つ、展開ＲＣＡルールＩＤ５５１と、組合せを構成するトポロジＩＤ及びメタＲＣＡルールＩＤとを、展開ＲＣＡレコード（展開ＲＣＡルール情報１１６内のレコード）に格納する、
を行う。なお、実際には利用されることのないストレージ装置とサーバの組み合わせを含んだトポロジのトポロジＩＤについては、上記（ｘ）の処理は行われなくて良い。同様に、他の処理によって展開ＲＣＡルール情報が作成されてもよい。より抽象化して考えた場合、例えば、トポロジ適用プログラム１２１は、以下の（ステップＡ）～（ステップＤ）：
（ステップＡ）監視対象ノードから上記の各取得情報に含まれる少なくとも一つの値をノード取得情報として取得する；
（ステップＢ）ノード取得情報に基づいて、サービス利用ノード装置情報、サービス提供ノード装置情報、又は中継ノード装置情報を更新する；
（ステップＣ）トポロジ取得情報に基づいて、所定のネットワークサービスについてのサービス提供ノード装置の識別子と、当該ノード装置を利用するサービス利用ノード装置の識別子との対応を、トポロジ情報に含める；
（ステップＤ）トポロジ情報とメタＲＣＡルール情報に基づいて、展開ＲＣＡルール情報を更新する；
を行うことができる。
　なお、上記の例によれば、展開ＲＣＡルール情報の１レコードがメタＲＣＡルール情報の１レコードから作成されるが、本発明はこれに限定されない。その一例としては多段推論がある。多段推論の場合、３段論法等を用いて複数のルールから新しいルールを導出することができる。この場合、展開ＲＣＡルール情報のメタＲＣＡルールＩＤ以外に、実際に一つ以上のメタＲＣＡルールのレコードとトポロジ情報とによって展開ＲＣＡルール情報が作成されればよい。複数のルールから新しいルールを導出する一例としては以下がある。
（第１のメタＲＣＡルール）第１のネットワークサービス（例えばＷＷＷ（World Wide Web））について、サービス利用ノード装置で発生する第１の種別のイベント（以下、イベントＡ）とサービス提供ノード装置で発生する第２の種別のイベント（以下、イベントＢ）とを検知した場合、イベントＡが発生する根本原因はイベントＢの発生である。
（第２のメタＲＣＡルール）第２のネットワークサービス(例えばＤＮＳ（Domain Name System）)について、サービス利用ノード装置で発生する第３の種別のイベント（以下、イベントＣ）と、サービス提供ノード装置で発生する第４の種別のイベント（以下、イベントＤ）とを検知した場合、イベントＣが発生する根本原因はイベントＤの発生である。
（第１のトポロジ情報）第１のネットワークサービスについて、ノード装置Ａがサービス利用ノード装置であり、ノード装置Ｂがサービス提供ノード装置である。
（第２のトポロジ情報）第２のネットワークサービスについて、ノード装置Ｂがサービス利用ノード装置であり、ノード装置Ｃがサービス提供ノード装置である。
（第３のトポロジ情報）ノード装置Ｂにおける第１のネットワークサービスは、第２のネットワークサービスを利用して提供する。
（生成される第１の展開ＲＣＡルール）ノード装置Ａで発生したイベントＡが検知され且つノード装置Ｂで発生したイベントＢが検知された場合、ノード装置Ａで発生したイベントＡの根本原因は、ノード装置ＢでのイベントＢの発生である。
（生成される第２の展開ＲＣＡルール）ノード装置Ｂで発生したイベントＣが検知され且つノード装置Ｃで発生したイベントＤが検知された場合、ノード装置Ｂで発生したイベントＣの根本原因は、ノード装置ＣでのイベントＤの発生である。
（生成される第３の展開ＲＣＡルール）ノード装置Ａで発生したイベントＡが検知され且つノード装置Ｃで発生したイベントＤが検知された場合、ノード装置Ａで発生したイベントＡの根本原因は、ノード装置ＣでのイベントＤの発生である。
　なお、多段推論が用いられる場合、物理的な装置間（例えばノード間）の依存関係以外に、ネットワークサービス又は論理的な対象間の依存関係を表す情報も、トポロジ情報に含まれても良い。上記第３のトポロジ情報がその一例である。
　また、図９の展開ＲＣＡルール情報では、メタＲＣＡルールＩＤ５５２及びトポロジＩＤ５５３に基づいて、メタＲＣＡルール情報１１５が表すメタＲＣＡルールとトポロジ情報が表すトポロジとを参照しつつ、根本原因の特定が行われる。しかし、代替の処理として、メタＲＣＡルール及びトポロジを基に展開されたルールを表す情報が、展開ＲＣＡルール情報に含まれても良い。この方式によれば、管理サーバ１０のメモリ１１０の消費量は増加するものの、根本原因を特定する速度はより高速となる。ただし、展開ＲＣＡルールからメタＲＣＡルールを特定する必要があるため、いずれにしても展開ＲＣＡルール情報にはメタＲＣＡルールＩＤ５５２は必要である。
　＜１－４：イベント検知処理＞。
　図１４は、イベントの検知からイベントの根本原因の特定までのフローを示す。本フローは一定時間毎（例えば１０分毎）または単なる繰り返しで実行される。
　（ステップ１０１１）プログラム１２２は、全ての監視対象ノード３０に対して、イベントタイプ、対象ノードタイプ、対象ノードＩＤ、イベント内容、発生日時を含む情報であるイベントエントリを要求する。なお、イベントエントリに含まれる各情報要素は、以下の通りである：
（イベントタイプ）イベントエントリの属するイベントの種類（例えば、Ｃｒｉｔｉｃａｌ、Ｗａｒｎｉｎｇ、Ｉｎｆｏｒｍａｔｉｏｎ）を示す；
（対象ノードタイプ）発生したイベントの対象である監視対象ノード３０のノードの種類（例えば、サーバ、スイッチもしくはストレージ装置）を示す；
（対象ノードＩＤ）イベントが発生した監視対象ノード３０を示す識別子（サーバＩＤ５０１、スイッチＩＤ５１１又はストレージＩＤ５２１）である；
（イベント内容）発生したイベントの内容である；
（発生日時）イベントの発生日時である。
　なお、イベントエントリは、ルールマッチング解析プログラム１２２からの要求を受けること無しに監視対象ノード３０から送信されても良い。また、発生日時を表す情報は必ずしも含まれていなくても良い。その場合、発生日時に代えて、管理サーバ１０が、イベントエントリを受信した日時を採用することができる。
　（ステップ１０１２）ルールマッチング解析プログラム１２２は、ステップ１０１１で監視対象ノード３０からイベントエントリを受信した場合、ステップ１０１３を行う。監視対象ノード３０からイベントエントリを受信しなかった場合、ステップ１０１１が行われる。
　（ステップ１０１３）ルールマッチング解析プログラム１２２は、イベントエントリに基づいてイベント情報１１７に情報を追加する。具体的には、例えば、プログラム１２２は、以下の処理（Ａ）～（Ｃ）：
（Ａ）新規のイベントＩＤ５６１を取得し、イベント情報１１７内のブランクのレコード（以下、ステップ１０１３の説明において「対象レコード」と言う）に、そのＩＤ５６１を格納する；
（Ｂ）対象レコードに、イベントエントリ内のイベントタイプ、対象ノードタイプ、対象ノードＩＤ、イベント内容及び発生日時を格納する；
（Ｃ）対象レコードに、状態５６７として、「未解決」という値を格納する、
を行う。
　なお、イベントエントリは、イベント情報１１７のイベントレコード（イベント情報１１７内のレコード）を追加又は更新できるのであれば、他の値を含んでも良い。
　（ステップ１０１４）ルールマッチング解析プログラム１２２は、「未解決」を表す状態５６７を含んだイベントレコードと、トポロジ情報１１４と、展開ＲＣＡルール情報１１６とを基に、「未解決」を表す状態５６７を含んだイベントレコードと関連する展開ＲＣＡレコード（展開ＲＣＡルール情報１１６内のレコード）を特定する。具体的には、例えば、ルールマッチング解析プログラム１２２は、以下の処理（Ａ）～（Ｈ）：
（Ａ）状態５５６が「未解決」のイベントレコードのうち、発生日時５６５が最も遅いイベントレコード（第１のイベントレコード）を特定する；
（Ｂ）直前のステップで特定された第１のイベントレコードを基に、一つ以上の第２のイベントレコードを特定する（第１のイベントレコード内の発生日時５６５と、第２のイベントレコード内の発生日時５６５との差は、所定の時間（例えば１０分前後）以内である）；
（Ｃ）上記（Ｂ）で得られた全ての第２のイベントレコード内の対象ノードタイプ５６３を参照し、それら第２のイベントレコード内の全ての対象ノードＩＤを基に、対象ノードタイプの異なる対象ノードＩＤで構成された全ての組み合わせ（以下、ノードＩＤセット）を作成する（例えば、４つのイベントレコードがあり、そのうちの２つがサーバＡ及びＢに関するレコードであり、残りの２つがスイッチＡ及びＢに関するレコードである場合、サーバＡのＩＤ－スイッチＡのＩＤ、サーバＡのＩＤ－スイッチＢのＩＤ、サーバＢのＩＤ－スイッチＡのＩＤ、及びサーバＢのＩＤ－スイッチＢのＩＤという４つのノードＩＤセットを作成する）；
（Ｄ－１）上記（Ｃ）で得られたいずれのＩＤセットにも含まれない対象ノードＩＤを含んだ第２のイベントレコード（「未解決」を表す状態５５６を含んだイベントレコード）がある場合、その中で発生日時５６５が最も遅い第２のイベントエントリを特定し、その第２のイベントエントリを上記第１のイベントエントリとして上記（Ｂ）を実施する；
（Ｄ－２）上記（Ｃ）で得られたいずれのＩＤセットにも含まれない対象ノードＩＤを含んだ第２のイベントレコード（「未解決」を表す状態５５６を含んだイベントレコード）がない場合、次の処理（Ｅ）を実施する；
（Ｅ）上記（Ｄ－１）及び（Ｄ－２）までに得られた各ノードＩＤセットについて、以下の（条件Ｅ１）～（条件Ｅ３）の全てに適合するトポロジレコード（トポロジ情報１１４のレコード）：
（条件Ｅ１）ノードＩＤセット内のサーバの対象ノードＩＤと一致するサーバＩＤ５３２を有する；
（条件Ｅ２）そのノードＩＤセット内のスイッチの対象ノードＩＤと一致するスイッチＩＤ５３３を有する；
（条件Ｅ３）そのノードＩＤセット内のストレージ装置の対象ノードＩＤと一致するストレージＩＤ５３４を有する、
を探し、そのようなトポロジレコードが見つかれば、そのトポロジレコードが有するトポロジＩＤ５３１を抽出し、そのＩＤ５３１を、そのトポロジレコードに対応するノードＩＤセットに対応づける；
（Ｆ）上記（Ｅ）で得られた各ノードＩＤセット（条件Ｅ１～Ｅ３に適合するトポロジレコードが特定されたノードＩＤセット）について、以下の（条件Ｆ１）～（条件Ｆ３）の全てに適合するメタＲＣＡレコード（メタＲＣＡルール情報１１５のレコード）：
（条件Ｆ１）イベントＩＤセット内のサーバの対象ノードＩＤを有するイベントレコード内のイベント内容５６４と一致するサーバイベント５４２を有する；
（条件Ｆ２）そのイベントＩＤセット内のスイッチの対象ノードＩＤを有するイベントレコード内のイベント内容５６４と一致するスイッチイベント５４３を有する；
（条件Ｆ３）そのイベントＩＤセット内のストレージ装置の対象ノードＩＤを有するイベントレコード内のイベント内容５６４と一致するストレージイベント５４４を有する、
を探し、そのようなメタＲＣＡレコードが見つかれば、そのメタＲＣＡレコードが有するメタＲＣＡルールＩＤ５４１を抽出し、そのＩＤ５４１を、対応するノードＩＤセットに対応づける；
（Ｇ）上記（Ｆ）で得られた各ノードＩＤセット（メタＲＣＡルールＩＤ５４１が対応付けられたセット）について、以下の処理（ｇ１）～（ｇ４）：
（ｇ１）ノードＩＤセットに対応付けられたメタＲＣＡルールＩＤ５４１を有するメタＲＣＡレコードから原因ノード５４５を抽出する；
（ｇ２）抽出された原因ノード５４５と一致する対象ノードタイプ５６３を有するイベントレコードを特定する；
（ｇ３）特定されたイベントレコードから対象ノードＩＤ５６４を抽出する；
（ｇ４）抽出された対象ノードＩＤ５６４を、上記（ｇ１）でのノードＩＤセットに対応付ける、
を行う；
（Ｈ）下記（ｈ１）～（ｈ３）の要素を有する展開ＲＣＡレコード（展開ＲＣＡルール情報１１６のレコード）：
（ｈ１）上記（Ｅ）で得られたトポロジＩＤ５３１と一致するトポロジＩＤ５５３；
（ｈ２）上記（Ｆ）で得られたメタＲＣＡルールＩＤ５４１と一致するメタＲＣＡルールＩＤ５５２；
（ｈ３）上記（Ｇ）で得られた対象ノードＩＤ５６４と一致する原因ノードＩＤ５５４、
を抽出する。
　（ステップ１０１５）ルールマッチング解析プログラム１２２は、ステップ１０１４で得られた複数の展開ＲＣＡレコードを、メタＲＣＡルールＩＤ５５２が一致するレコード同士でまとめる。これにより、メタＲＣＡルールＩＤ５５２が同じ展開ＲＣＡレコードのグループが１又は複数個できる。
　（ステップ１０１６）プログラム１２２は、ステップ１０１５で得られたグループに属する展開ＲＣＡルールを、原因ノードＩＤ５５４が一致するレコード同士でまとめる。これにより、メタＲＣＡルールＩＤ５５２が同じ展開ＲＣＡレコードのグループにつき、原因ノードＩＤ５５４が同じ展開ＲＣＡレコードのサブグループが１又は複数個できる。原因ノードＩＤ５５４が示す監視対象ノード３０が、根本原因候補である。
　（ステップ１０１７）プログラム１２２は、ステップ１０１６で得られた根本原因候補の確からしさを確信度として算出する。確信度の算出方法として、例えば、原因ノードＩＤ５５４が一致する展開ＲＣＡルールレコードの数に基づく方法がある。例えば、各根本原因候補に対して、原因ノードＩＤ５５４が一致する展開ＲＣＡルールレコードの数に応じた確信度が割り振られる。原因ノードＩＤ５５４が一致する展開ＲＣＡルールレコードの数が多い根本原因候補に割り振られた確信度は、そのような展開ＲＣＡルールレコードの数が少ない根本原因候補に割り振られた確信度よりも高い。なお、確信度は他の算出方法でもよい。
　＜１－５：障害分析コンテキストの作成＞。
　図１５は、障害分析コンテキストの作成のフロー図である。このフローは、例えばステップ１０１７の直後に開始される。
　（ステップ１０１８）生成プログラム１２３は、障害分析コンテキスト１１８を作成する。具体的には、例えば、生成プログラム１２３は、以下の処理（Ａ）～（Ｇ）：
（Ａ）ステップ１０１５で得られたメタＲＣＡルールＩＤ５５２を障害分析コンテキストに含める；
（Ｂ）ステップ１０１４で得られた１つ以上の展開ＲＣＡルールＩＤ５５１を有する１以上の展開ＲＣＡレコードのうちの、上記（Ａ）で得られたメタＲＣＡルールＩＤ５５２と一致するＩＤ５５２を有するレコードから展開ＲＣＡルールＩＤ５５１を抽出し、抽出したＩＤ５５１を障害分析コンテキストに含める；
（Ｃ）上記（Ｂ）で得られた展開ＲＣＡルールＩＤ５５１（６０３）と一致するＩＤ５５１を有する展開ＲＣＡレコードからトポロジＩＤ５５３を抽出し、そのＩＤ５５３を障害分析コンテキストに含める；
（Ｄ）上記（Ｃ）で得られたトポロジＩＤ５５３（６０５）と一致するＩＤ５３１を有するトポロジレコードからサーバＩＤ５３２を抽出し、そのＩＤ５３２を障害分析コンテキストに含める；
（Ｅ）上記（Ｃ）で得られたトポロジＩＤ５５３（６０５）と一致するＩＤ５３１を有するトポロジレコードからスイッチＩＤ５３３を抽出し、そのＩＤ５３３を障害分析コンテキストに含める；
（Ｆ）上記（Ｃ）で得られたトポロジＩＤ５５３（６０５）と一致するＩＤ５３１を有するトポロジレコードからストレージＩＤ５３４を抽出し、そのＩＤ５３４を障害分析コンテキストに含める；
（Ｇ）生成プログラム１２３が、障害分析コンテキストＩＤ６０１を割り振り、そのＩＤ６０１を障害分析コンテキストに含める、
を行う。障害分析コンテキスト１１８は、障害分析コンテキストＩＤ６０１とメタＲＣＡルールＩＤ６０３だけ用いて作成されてもよい。
　＜１－６：根本原因の表示と選択＞。
　図１６は、根本原因を選択のためのフローを示す。本フローは、例えばステップ１０１８の直後に開始される。
　（ステップ１０１９）生成プログラム１２３は、以下の要素（ａ）～（ｃ）を含む第１の表示情報：
（ａ）ステップ１０１６での原因ノードＩＤ５５４と一致するサーバＩＤ５０１を有するサーバレコード内のサーバ名５０２、ステップ１０１６での原因ノードＩＤ５５４と一致するスイッチＩＤ５１１を有するスイッチレコード内のスイッチ名５１２、又は、ステップ１０１６での原因ノードＩＤ５５４と一致するストレージＩＤ５２１を有するストレージレコード内のストレージ名５２２；
（ｂ）上記（ａ）での原因ノードＩＤ５５４に対応した展開ＲＣＡレコード（ステップ１０１５でまとめられた展開ＲＣＡレコード）における原因詳細５５５；
（ｃ）上記（ａ）での原因ノードＩＤ５５４に対応した確信度（ステップ１０１７で得られた確信度）、
を、ネットワーク５０を通じて表示用計算機２０に送信する。
　（ステップ１０２０）画面表示プログラム２１１は、ステップ１０１９で送信された第１の表示情報を受信する。
　（ステップ１０２１）画面表示プログラム２１１は、ステップ１０２０で受信した第１の表示情報を入出力装置２６０（例えば、ディスプレイ装置）に表示する。
　図１９は、候補／確信度画面２０１０を示す。画面２０１０は、第１の表示情報の表示画面の一例である。
　候補ＩＤ２０１１は、根本原因候補の識別子である。候補ＩＤ、例えば、表示プログラム２１１によって、各根本原因候補に割り振られる。
　原因ノード名２０１２は、第１の表示情報に含まれている要素であり、根本原因候補（監視対象ノード３０）のサーバ名５０２、スイッチ名５１２、もしくはストレージ名５２２である。
　原因詳細２０１３は、第１の表示情報に含まれている原因詳細５５５である。
　確信度２０１４は、第１の表示情報に含まれている確信度である。
　再び図１６の説明に戻る。
　（ステップ１０２２）画面表示プログラム２１１は、入出力装置２６０（例えば、マウス）を用いてシステム管理者が選択した根本原因候補を同定するための情報（例えば原因ノードＩＤ）を、ネットワーク５０を通じて管理サーバに送信する。
　（ステップ１０２３）生成プログラム１２３は、ステップ１０２２で送信された情報を受信する。
　（ステップ１０２４）生成プログラム１２３は、ステップ１０２３で受信した情報と対応する障害分析コンテキスト１１８を決定する。この障害分析コンテキスト１１８は、ステップ１０１８作成された障害分析コンテキストである。
　＜１－７：障害履歴の登録＞。
　図１７は、障害の登録のフローを示す。障害履歴エントリが０件の場合、図１６のフローの後、このフローが開始される。障害履歴エントリが１件以上ある場合、図１６のフローの後、図１８Ａのフローを経た後、本フローが開始される。
　（ステップ１０４０）表示用計算機２０は、障害履歴の登録画面を表示する。
　図２１は、登録画面２０３０を示す。この画面２０３０は、障害履歴の登録画面の一例である。
　根本原因２０３１は、ステップ１０１６での原因ノードＩＤに対応した根本原因候補（監視対象ノード３０）を示すサーバ名５０２、スイッチ名５１２もしくはスイッチ名５２２である。
　障害分析コンテキストＩＤ２０３２乃至ストレージＩＤ２０３８は、ステップ１０１６での原因ノードＩＤと対応する障害分析コンテキスト（ステップ１０２４で決定されたコンテキスト）内の障害分析コンテキストＩＤ６０１乃至ストレージＩＤ６０７である。ステップ１０２４から当該ステップまでの間に、図１９に示した画面が閉じられてもよい。この場合、ステップ１０２４で得られた障害分析コンテキストを、図１９の画面を閉じる前にメモリ等の記憶装置に記録しておき、当該ステップにおいて読み込む必要がある。
　原因２０３９は、当該障害の原因の内容を、システム管理者が入出力装置２６０を用いて自然言語で登録するシステム管理者フォームである。
　復旧方法２０４０は、当該障害からの復旧方法の内容を、システム管理者が入出力装置２６０を用いて自然言語で登録するシステム管理者フォームである。
　システム管理者は、原因２０３９と復旧方法２０４０の欄を入力した後、登録ボタンを押すことで、メタＲＣＡルールＩＤ２０３３乃至ストレージＩＤ２０３８、原因２０３９、復旧方法２０４０を、障害履歴管理プログラム１２５に送信する。
　再び図１７を参照する。
　（ステップ１０４１）障害履歴管理プログラム１２５は、ステップ１０４０で送信されたメタＲＣＡルールＩＤ２０３３乃至ストレージＩＤ２０３８、原因２０３９、復旧方法２０４０を受信する。
　（ステップ１０４２）障害履歴管理プログラム１２５は、ステップ１０４１で受信したメタＲＣＡルールＩＤ２０３３乃至ストレージＩＤ２０３８と、原因２０３９と、復旧方法２０４０とを、障害履歴エントリに登録する。プログラム１２５は、このレコードに、障害履歴ＩＤ７０１を割り振る。
　（ステップ１０４３）障害履歴管理プログラム１２５は、サーバの重み情報８００に新たなレコードを作成する。そのレコードのサーバのベンダ８０２乃至サーバの連続稼働時間８０５に初期値（例えば１００）が代入され、そのレコードにサーバ重みＩＤが格納される。なお、初期値は各要素の重みを示すものであれば他の値でもよい。
　（ステップ１０４４）障害履歴管理プログラム１２５は、スイッチの重み情報８１０に新たなレコードを作成する。そのレコードのスイッチのベンダ８１２乃至スイッチの連続稼働時間８１５に初期値（例えば１００）が代入され、そのレコードにスイッチ重みＩＤが格納される。なお、初期値は各要素の重みを示すものであれば他の値でもよい。
　（ステップ１０４５）障害履歴管理プログラム１２５は、ストレージの重み情報８２０に新たなレコードを作成する。そのレコードのストレージのベンダ８２２乃至ストレージの連続稼働時間８２５に初期値（例えば１００）が代入され、そのレコードにストレージ重みＩＤが格納される。なお、初期値は各要素の重みを示すものであれば他の値でもよい。
　ステップ１０４３乃至１０４５についての説明では、監視対象ノードの組み合わせとして、ホスト＝スイッチ＝ストレージが例として採用されている。しかし、本発明は、監視対象ノードのハードウェア又はソフトウェア構成と設定内容との、任意の要素にマッチング度を評価するための値、を含んでいればよい。そうした広い観点から考えると、ステップ１０４３乃至ステップ１０４５では、障害分析コンテキストがもつ監視対象ノードのハードウェア又はソフトウェア構成と設定内容との任意の要素に、障害分析コンテキストのマッチングのための評価値を割り振る処理があればよい。
　＜１－９：障害履歴の検索＞。
　図１８Ａは、障害履歴情報から同件及び／又は類件の障害履歴エントリを取得するフローである。
　（ステップ１０２５）コンテキストマッチング解析プログラム１２４は、障害履歴エントリの件数が０件の場合、本フローを終了する。プログラム１２４は、障害履歴エントリの件数が１件以上の場合、ステップ１０２２を実行する。
　（ステップ１０２６）プログラム１２４は、障害分析コンテキストを用いて障害履歴情報を検索する。ステップ１０２６の詳細は、後に図１８Ｂを用いて説明する。
　（ステップ１０２７）プログラム１２４は、ステップ１０２６で得られた検索結果の情報を表示用計算機２０に送信する。なお、検索結果の情報には、例えば、障害履歴ＩＤ７０１、メタＲＣＡルールＩＤ７０２、展開ＲＣＡルールＩＤ７０３、トポロジＩＤ７０４、サーバＩＤ７０５、スイッチＩＤ７０６、ストレージＩＤ７０７、サーバ重みＩＤ７０８、スイッチ重みＩＤ７０９、ストレージ重みＩＤ７１０、原因７１１、復旧方法７１２及びマッチング率が含まれる。しかし、後述する図２０の表示が可能であれば、他の情報が送信されてもよい。
　（ステップ１０２８）画面表示プログラム２１１（表示用計算機２０）は、ステップ１０２７で送信された情報を受信し、入出力装置２６０（例えば、ディスプレイ装置）に表示する。その際、プログラム２１１は、マッチング率が高い情報を優先的に表示する（例えば、マッチング率の降順（高い順）に情報を表示する）。
　図２０は、ステップ１０２８で表示される検索結果画面２０２０を示す。この画面２０２０は、検索結果画面の一例である。
　履歴ＩＤは、ヒットした検索履歴に割り振られた識別子（例えば通し番号）である。
　障害履歴ＩＤ２０２２は、ヒットした障害履歴エントリがもつ障害履歴ＩＤ７０１である。
　障害履歴ノード名２０２３は、サーバレコード内のサーバ名５０２、スイッチレコード内のスイッチ名５１２、又は、ストレージレコード内のストレージ名５２２である。それらの要素５０２、５２２又は５１２を有するレコードは、原因ノードＩＤ５５４と一致するＩＤを有する。その原因ノードＩＤ５５４は、ヒットした障害履歴エントリがもつ展開ＲＣＡルールＩＤ７０３と一致する展開ＲＣＡルールＩＤ５５１を有する展開ＲＣＡレコード内にある。
　原因２０２４は、ヒットした障害履歴エントリがもつ原因７１１である。
　復旧方法２０２５は、ヒットした障害履歴エントリがもつ復旧方法７１２である。
　マッチング率２０２６は、ステップ１０２７でコンテキストマッチング解析プログラム１２４より送信されたマッチング率を示す。このマッチング率の降順に検索結果が表示される。
　検索結果画面には、図２０に示した情報要素に代えて又は加えて、障害履歴の検索結果に関する他種の情報要素が表示されても良い。
　システム管理者が、図２０に示した画面における表から任意の行（障害履歴）を選択すると、選択された障害履歴が表す障害と今回発生した障害とを比較するための画面が表示される。
　図２４Ａは、マッチング度合比較画面の第１の例を示す。
　今回発生した障害に関する情報の詳細が表示領域ｅ０１に表示される。表示領域ｅ０１には、例えば、今回の障害に対応したメタＲＣＡルールＩＤ５４１と、発生したイベントのノード名５０２、５１２もしくは５２２と、イベント内容５６５とが表示される。
　選択された障害履歴の詳細が表示領域ｅ０２に表示される。表示領域ｅ０２には、障害履歴のメタＲＣＡルールＩＤ５４１と、発生したイベントのノード名５０２、５１２もしくは５２２と、イベント内容５６５とが表示される。
　表示領域ｅ０３には、今回の障害と障害履歴とのマッチング率２０２６が表示される。
　表示領域ｅ０４には、障害履歴の復旧方法２０２５が表示される。
　図２４Ａは、マッチング度合比較画面の第２の例を示す。
　表示領域ｅ０５には、今回の障害に関して、イベント情報とトポロジ情報とノード情報に基づく図が表示される。図としては、ノード間の繋がりがどのようになっていてどのノードでどんなイベントが発生したかが表示された図である。具体的には、例えば、表示領域ｅ０５には、３つのブロックがあり、各ブロックは、いずれかのノードに対応しており、ブロック同士の繋がりは、トポロジ情報から特定されるトポロジに従っており、ブロック内に表示される文字列は、そのブロックに対応したノードのノード名と、そのノードで発生したイベント（障害）の内容とを表している。
　表示領域ｅ０６には、障害履歴に関して、イベント情報とトポロジ情報とノード情報に基づく図が表示される。具体的には、例えば、表示領域ｅ０６には、３つのブロックが表示されているが、各ブロックは、表示領域ｅ０５と同様に、いずれかのノードに対応している。
　表示領域ｅ０５に表示された情報と表示領域ｅ０６に表示された情報とのうち互いに一致する部分（メタＲＣＡルールが一致する部分）が、破線で囲む等の方法で示される。これにより、システム管理者は、システム管理者が選択した障害履歴と今回の障害との差異を視覚的に把握できる。具体的には、今回発生した障害は、選択された障害履歴と比べて、ノード名「BOTAN」のノードでのIOエラーが生じていないことがわかる。
　なお、マッチング度合比較画面には、システム管理者が今回の障害と障害履歴の比較を参照できるなら、他の値を表示してもよい。例えば、図２４Ｂの各ブロック（いずれかのノードに対応したブロック）には、ノードタイプを表す情報が表示されても良い。
　図１８Ｂは、図１８Ａのステップ１０２６の詳細を示す。
　（ステップ１０３１）コンテキストマッチング解析プログラム１２４は、ステップ１０３１の処理として、メタＲＣＡルールマッチングを行う。ステップ１０３１の詳細は、後に図１８Ｃを参照して説明する。
　以下、図１８Ｃが示すフローについて説明する。
　（ステップ１１０１）コンテキストマッチング解析プログラム１２４は、特定の障害分析コンテキストを含んだ障害履歴エントリの検索要求を、障害履歴管理プログラム１２５に送信する。ここで、「特定の障害分析コンテキスト」とは、ステップ１０２４で得た障害分析コンテキスト１１９のメタＲＣＡルールＩＤと等しいメタＲＣＡルールＩＤをもつ障害分析コンテキストである。
　（ステップ１１０２）障害履歴管理プログラム１２５は、ステップ１１０１で送信された検索要求を受信する。
　（ステップ１１０３）障害履歴管理プログラム１２５は、ステップ１１０２で受けた検索要求に応答して、上記特定の障害分析コンテキストをもつ障害履歴エントリを検索する。プログラム１２５は、その検索結果を表す情報を、コンテキストマッチング解析プログラム１２４に送信する。送信される情報は、特定の障害分析コンテキストを含んだ障害履歴エントリに登録されている情報を含んでいる。
　（ステップ１１０４）コンテキストマッチング解析プログラム１２４は、ステップ１１０３で送信された情報を受信する。
　再び図１８Ｂの説明に戻る。
　（ステップ１０３３）コンテキストマッチング解析プログラム１２４は、ステップ１０３１で得た障害履歴エントリの数が第１の閾値（例えば１０）を下回る場合、ステップ１０３４を実行する。一方、プログラム１２４は、ステップ１０３１で得られた障害履歴エントリの数が第２の閾値（例えば５０）を上回る場合、ステップ１０３５を実行する。第２の閾値は、第１の閾値と同じかそれより大きい値である。ステップ１０３１で得られた障害履歴エントリが適切な数（例えば第１の閾値以上第２の閾値以下）の場合、本フローを終了する。
　なお、前述した第１及び第２の閾値のうちの少なくとも一つは、システム管理者が任意に設定可能である。
　（ステップ１０３４）プログラム１２４は、検索の条件を緩めることでステップ１０３１より多くの障害履歴エントリを得るための処理を行う。具体的には、図１８Ｄに示す処理が行われる。検索クエリである障害分析コンテキストが複数のメタＲＣＡルールをもつ場合（すなわち、展開ＲＣＡルールが、メタＲＣＡルールの多段推論で成り立っている場合）、検索クエリと同じメタＲＣＡルールを一つ以上持つ障害履歴エントリを全て得るようにする。
　以下、図１８Ｄが示すフローについて説明する。
　（ステップ１１１１）コンテキストマッチング解析プログラム１２４は、検索元の障害分析コンテキスト（検索のキーとなる障害分析コンテキスト）１１９がもつ複数のメタＲＣＡルールＩＤ６０２と等しいメタＲＣＡルールＩＤ７０２をｋ個（ｋは自然数）以上もつ障害履歴エントリの検索要求を、障害履歴管理プログラム１２５に送信する。なお、ｋの値は、システム管理者が任意に設定できる。
　（ステップ１１１２）障害履歴管理プログラム１２５は、ステップ１１１１で送信された検索要求を受信する。
　（ステップ１１１３）プログラム１２５は、ステップ１１１２で受けた検索要求に応答して、検索を行なう。つまり、プログラム１２５は、検索元の障害分析コンテキスト１１９のメタＲＣＡルールＩＤ６０２と等しいメタＲＣＡルールＩＤ７０２をｋ個以上もつ障害履歴エントリに記録されている情報を送信する。例えば、ｋ＝２であり、且つ、図１８Ｅに例示するように、互いに２つのメタＲＣＡルールＩＤが一致している場合、図示の障害履歴エントリに記録されている情報が送信される。なお、検索元の障害分析コンテキスト１１９内のメタＲＣＡルールＩＤ６０２と一致するメタＲＣＡルールＩＤの数が多い障害履歴エントリから順に高いマッチング率が割り当てられ、その割り当てられたマッチング率を表す情報が、送信される情報に含まれてよい。つまり、この例では、検索元の障害分析コンテキスト１１９内のメタＲＣＡルールＩＤ６０２と一致するメタＲＣＡルールＩＤの数に基づいて、マッチング率が算出される。なお、マッチング率は、他の算出方式でもよい。
　（ステップ１１１４）コンテキストマッチング解析プログラム１２４は、ステップ１１１３で送信された情報を受信する。なお、送信される情報の件数（検索ヒットとする障害履歴エントリの件数）は、適切な数（例えば後述の第１の数及び／又は第２の数）以下に抑えられても良い。
　以上が、図１８Ｂのステップ１０３４での検索についての説明である。なお、検索の方法としては、上述した方法に限らず、他の方法が採用されても良い。例えば、検索元の障害分析コンテキストもいずれの障害履歴エントリも一つのメタＲＣＡルールＩＤを有している場合、検索元の障害分析コンテキスト内のメタＲＣＡルールＩＤから同定されるメタＲＣＡルール（以下、第１のメタＲＣＡルール）と、障害履歴エントリ内のメタＲＣＡルールＩＤから同定されるメタＲＣＡルール（以下、第２のメタＲＣＡルール）とが異なっていても、障害履歴管理プログラム１２５は、第１のメタＲＣＡルールとのマッチング率がＸ％以上（Ｘは自然数）の第２のメタＲＣＡルールのＩＤを有する障害履歴エントリを、検索ヒットの対象としても良い。ここでのマッチング率は、第１のメタＲＣＡルールに属するイベント群と第２のメタＲＣＡルールに属するイベント群との重複度合いに基づく。具体的には、例えば、第１のメタＲＣＡルールに属するイベントの総数に対する重複したイベントの数の第１の割合と、第２のメタＲＣＡルールに属するイベントの総数に対する重複したイベントの数の第２の割合とのうちの少なくとも一方を基に、マッチング率が算出される。図２４Ｂの例によれば、表示領域ｅ０５に表示されている第１のメタＲＣＡルールと、表示領域ｅ０６に表示されている第２のメタＲＣＡルールは部分的に一致している。第１の割合は２／２（＝１）であり、第２の割合は２／３である。これらのうちの少なくとも一つの割合を基に算出されるマッチング率が、上記Ｘ％以上であれば、表示領域ｅ０６に表示されている第２のメタＲＣＡルールは検索ヒットとなる。なお、各メタＲＣＡルールに属するイベントが何であるかは、メタＲＣＡルール情報１１５を参照することにより、特定することができる。
　再び、図１８Ｂの説明に戻る。
　（ステップ１０３５）コンテキストマッチング解析プログラム１２４は、図１８Ｆに示す処理を行う。この処理では、ステップ１０３１で得られた検索結果に対して、マッチング率を評価することで、検索ヒットした複数の障害履歴エントリから、検索元の障害分析コンテキストと条件の近い障害履歴エントリを素早く得ることができるようにする。マッチング評価は、例えば、以下の（Ａ）及び（Ｂ）：
（Ａ）検索元の障害分析コンテキストから特定される監視対象ノードハードウェア又はソフトウェア構成、及び設定内容の要素；
（Ｂ）障害履歴エントリから特定される監視対象ノードのハードウェア又はソフトウェア構成、及び設定内容の要素、
の互いの一致度を基に行われる。
　以下、図１８Ｆが示すフローを説明する。
　（ステップ１１２１）コンテキストマッチング解析プログラム１２４は、ステップ１０２４で得た障害分析コンテキスト１１９のメタＲＣＡルールＩＤ（第１のメタＲＣＡルールのＩＤ）を含んだ検索要求を、障害履歴管理プログラム１２５に送信する。
　（ステップ１１２２）プログラム１２５は、ステップ１１０１で送信された検索要求を受信する。
　（ステップ１１２３）プログラム１２５は、ステップ１１０２で受けた検索要求に応答して検索を行い、コンテキストマッチング解析プログラム１２４に、第１のメタＲＣＡルールＩＤと等しいメタＲＣＡルールＩＤをもつ障害履歴エントリに記録されている情報を送信する。
　（ステップ１１２４）コンテキストマッチング解析プログラム１２４は、ステップ１１０３で送信された情報を受信する。
　（ステップ１１２５）プログラム１２４が、以下の処理（Ａ）～（Ｄ）：
（Ａ）検索元の障害分析コンテキスト内のＩＤから同定されるサーバレコード、スイッチレコード及びストレージレコードのうちの少なくとも一つのレコードと、ステップ１１２４で得た障害履歴エントリ内のＩＤから同定されるサーバレコード、スイッチレコード及びストレージレコードのうちの少なくとも一つのレコードとから、互いに一致する又は近似する値を抽出する（例えば、連続稼働時間については、誤差が３０００以内であれば、互いに近似する値となる）；
（Ｂ）上記（Ａ）で得た各値に対応した各項目の重みを、障害履歴情報が有するサーバ重み情報８００、スイッチ重み情報８１０及びストレージ重み情報８２０から抽出する；
（Ｃ）ステップ１１２４で得た障害履歴エントリ毎に、上記（Ｂ）で得た重みの累計値を算出する；
（Ｄ）ステップ１１２４で得た各障害履歴エントリに、重みの累計値に応じたマッチング率を割り当てる（例えば、重みの累計値が高い障害履歴エントリには高いマッチング率が割り当てられ、重みの累計値が低い障害履歴エントリには低いマッチング率が割り当てられる）、
を行う。なお、マッチング率の算出には、重みの累計値に代えて又は加えて、他の要素が参酌されてもよい。
　（ステップ１１２６）プログラム１２４は、ステップ１１２５で得たマッチング率の降順に障害履歴エントリを並べ替える。この処理を行うことで、システム管理者は、今回発生した障害とマッチング率の高い障害履歴から順に参照することができる。
　（ステップ１１２７）プログラム１２４は、ステップ１１２５の比較処理において、障害履歴情報がもつ情報８００、８１０及び８２０のうち、ステップ１１２５で抽出された値の項目（以下、図１８Ｆ及び図１８Ｇの説明において「対象項目」と言う）に対応した重みを相対的に増加する。「相対的に増加する」とは、対象項目に対応した重みを増加することであっても良いし、非対象項目に対応した重みを減少することであっても良い。
　（ステップ１１２８）プログラム１２４は、重みが変更された項目の識別情報（例えば名称）と更新後の重み（及び／又は変化量）とを含んだ更新要求を、障害履歴管理プログラム１２５に送信する。
　（ステップ１１２９）障害履歴管理プログラム１２５は、上記更新要求に応じて、障害履歴情報内の情報８００、８１０及び８２０のうちの少なくとも一つを更新する。つまり、ステップ１１２７で計算された重みを、障害履歴情報内の情報８００、８１０及び８２０における対応するレコードに反映する。
　図１８Ｇを参照して、図１８Ｆを参照して説明したフローの概要を説明する。
　検索元の障害分析コンテキスト（又は検索クエリ）が、そのコンテキストから特定される展開ＲＣＡルール（又はトポロジ）に属する各ノード装置について、ノード装置のタイプ以外の各属性の重みを表す値を含んでいる。
　そのコンテキストと第１の障害履歴エントリとの比較によれば、複数種類の属性のうち、ベンダとＯＳが一致している。このため、第１の障害履歴エントリについての累計値は、ベンダについての重み「５０」とＯＳについての重み「８０」との合計「１３０」となる。
　一方、そのコンテキストと第２の障害履歴エントリとの比較によれば、複数種類の属性のうち、ＩＰアドレスと連続稼働時間が一致している。このため、第２の障害履歴エントリについての累計値は、ＩＰアドレスについての重み「２０」と連続稼働時間「１０」との合計「３０」となる。
　この結果、第１の障害履歴エントリの方が第２の障害履歴エントリよりも検索元の障害分析コンテキストとの類似度が高いということになる。
　ステップ１１２５で、ベンダ、ＩＰアドレス、ＯＳ及び連続稼働時間のいずれも抽出された場合、ステップ１１２７で、それらの属性の重みはより高い値とされる。なお、ステップ１１２５で抽出された値に対応した属性に代えて又は加えて、システム管理者から選択された復旧方法を表す情報を含んだ障害分析レコードが有する各値に対応した属性の重みがより高い値とされても良い。
　システム管理者が、以上のようにして、今回発生した障害の復旧方法を、障害履歴情報から特定する。システム管理者は、今回発生した障害の復旧を終えた後、この事象を障害履歴として図１７のフローを実施する。これにより、今回発生した障害に対応する障害分析コンテキストと、今回発生した障害の根本原因を表す情報と、今回採った復旧方法を表す情報とが対応付けられる。
　図１８Ｂのステップ１０３１で得られた情報を基に、ステップ１１２４以降が行われても良い。
　以上が、実施例１についての説明である。
　実施例１によれば、障害履歴エントリが、発生した障害の根本原因を表す情報と、その根本原因に応じた復旧方法を表す情報との他に、その発生した障害に対応する障害分析コンテキストを含む。障害分析コンテキストは、複数の原因／結果ルールのうちの、障害の根本原因の根拠となった原因／結果ルールを特定するための情報（以下、ルール特定情報）を含んだ情報である。原因／結果ルールは、以下の（ｘ）及び（ｙ）：
（ｘ）根本原因としての、ノード装置のタイプと発生したイベントの内容；
（ｙ）結果としての、ノード装置のタイプと発生したイベントの内容（どのタイプのノード装置でどんなイベントが発生したか）、
の対応関係を表す。発生した障害に対応した障害分析コンテキストを含んだ検索クエリが、システム管理者から管理サーバに入力される。管理サーバは、その検索クエリに応答して、検索クエリが有する障害分析コンテキスト（第１の障害分析コンテキスト）と、障害履歴情報が有する各障害履歴エントリ内の障害分析コンテキスト（第２の障害分析コンテキスト）とを比較し、それにより、検索元の障害分析コンテキストと類似性の高い障害分析コンテキストを含んだ障害履歴エントリを特定する。管理サーバは、特定された第２の障害履歴エントリに登録されている情報（復旧方法を表す情報を含んだ情報）を表示する。これにより、システム管理者は、迅速に、発生した障害からの復旧方法を特定することができる。
　また、発生した障害に対応した第１の障害分析コンテキストと、特定された復旧方法を表す情報とを含んだ新たな障害履歴エントリを登録することができる。この登録作業は、システム管理者が手動で行っても良いし、管理サーバが自動で行っても良い。後者の場合、例えば、管理サーバは、検索の際に使用された第１の障害分析コンテキストと、特定された根本原因を表す情報と、特定された復旧方法を表す情報とを含んだ障害履歴エントリを登録することができる。
　また、第１の障害分析コンテキストと類似する第２の障害分析コンテキストを含んだ障害履歴エントリの検索の際、第１及び第２の障害分析コンテキスト内のルール特定情報を基に、どのタイプのノード装置でどんなイベントが発生したかを表す情報が特定される。つまり、ノード装置のタイプが互いに比較される。このため、同じ内容のイベントが発生したノード装置が違っていても、ノード装置のタイプが同じであれば、当該第２の障害分析コンテキストが第１の障害分析コンテキストに類似するということになる。従って、例えば、前回或るイベントがサーバＡで発生し、今回は同イベントがサーバＢで発生した場合、その前回の障害に対応する第２の障害分析コンテキストを含んだ障害履歴エントリが、検索ヒットの対象となる可能性がある。つまり、類件をヒットさせることができる。
　また、実施例１の説明によれば、原則、第１の障害分析コンテキストから特定される原因／結果ルールと完全に一致する原因／結果ルールが関連付けられた第２の障害分析コンテキストを含んだ障害履歴エントリが、検索ヒットの対象となる。しかし、ヒットした障害履歴エントリの数が、第１の数よりも少ない場合、条件を緩和して再検索が行われる。具体的には、例えば、原因／結果ルール同士が所定の類似度（但し１００％未満）以上に類似していれば、検索履歴レコードがヒットとなる。一方、ヒットした障害履歴エントリの数が、第１の数又は第１の数よりも大きい第２の数よりも多い場合、条件を厳しくして再検索が行われる。具体的には、例えば、ノード装置のタイプ以外の複数の属性のうちの或る程度の属性が一致している場合に（ノード装置同士が或る程度類似している場合に）、検索履歴レコードがヒットとなる。
　＜２－０：実施例２の概要＞。
　本発明の実施例２に係る管理システムは、復旧方法の手順をメタ化してメタ復旧方法として登録することを補助する機能と、メタ復旧方法をメタＲＣＡルールに対応づける機能と、根本原因参照時にメタ復旧方法を併せて表示する機能とを有する。
　実施例１では、管理システムが、過去に障害が発生したノードのＩＰアドレス等の識別子を表示し、システム管理者は、表示された復旧方法の情報を、今回障害が発生したノードに置き換えて作業を行う。
　実施例２では、メタ復旧方法を用いることで、管理システムが、今回障害が発生したノードの識別子を用いた復旧方法を表示する。これにより、システム管理者は、根本原因参照時に、採り得る復旧方法の候補を特定することができる。
　＜２－１：実施例２における実施例１との構成の差異＞
　実施例１のメタＲＣＡルール情報１１５（メタＲＣＡレコード）に、メタ復旧方法（後述）を表す情報が対応づけられる。
　実施例１のステップ１０４０において、障害履歴の登録画面（図２１）に、メタ復旧方法登録画面（図２２Ａ）が追加され、メタ復旧方法を登録するステップが追加される。
　実施例１のステップ１０２０において、根本原因候補リストと確信度画面（図１９）に、メタ復旧方法を表す情報が追加される（図２３）。
　＜２－２：用語定義＞。
　「メタ復旧方法」とは、管理システムが提供する有限の要素（オブジェクト）の組み合わせで定義される復旧方法である。メタ復旧方法は、特定のノードに依存しない方法であり、メタＲＣＡルールと対応づけて登録することができる。復旧方法を定義できるなら情報の形式は問わない。本実施例では、一例として、メタ復旧方法を、一つ以上のＡｒｃ、Ｂｒａｎｃｈ及びＣｏｍｍａｎｄの３つの要素の組み合わせから定義されるとする。ちなみに、「Ａｒｃ」は、ＢｒａｎｃｈまたはＣｏｍｍａｎｄ間の遷移を示す。「Ｂｒａｎｃｈ」は、条件分岐を示す。「Ｃｏｍｍａｎｄ」は、処理を示す。
　＜２－３：メタ復旧方法の登録＞。
　メタ復旧方法の登録は、例えば、実施例１におけるステップ１０４０において障害履歴の登録情報を送信する直前のタイミングで行う。
　図２２Ａは、メタ復旧方法登録画面の一例を示す。
　表示領域ｅ１１には、Ａｒｃ、Ｂｒａｎｃｈ及びＣｏｍｍａｎｄのアイコンが設置されている。システム管理者は、いずれかのアイコンを表示領域ｅ１２にドラッグアンドドロップすることで、表示領域ｅ１２にアイコンを設置することができる。
　図２２Ａｅ０２は、メタ復旧方法を定義するための編集画面である。表示領域ｅ０１のアイコンを配置することで、メタ復旧方法の構成が定義できる。
　表示領域ｅ１３は、表示領域ｅ１２に設置した各アイコンの詳細設定を実施するウィンドウである。本図ではBranchの設定画面の一例を示す。
　表示領域ｅ１４は、当該アイコンの識別子を示す。
　表示領域ｅ１５は、条件分岐における条件の対象を選択するフォームである。選択項目はシステム側が提供する有限の要素である。
　表示領域ｅ１６は、条件分岐における条件の内容を選択するフォームである。選択項目はシステム側が提供する有限の要素である。
　表示領域ｅ１７は、表示領域ｅ１６で定義した条件が真の場合の遷移先と、偽の場合の遷移先を定義する。
　表示領域ｅ１８は、表示領域ｅ１６だけでは表現しきれない分岐の内容の詳細を入力するフォームである。該情報は、システム管理者による自然言語で登録される。
　システム管理者は、当該画面にてメタ復旧方法の定義を終えたら表示領域ｅ１９の登録ボタンを押すことで登録が完了し、実施例１のステップ１１４０において登録するメタＲＣＡルール情報に本メタ復旧方法を対応づける。
　図２３Ｂに示す表示領域ｅ１３は、表示領域ｅ１３がＣｏｍｍａｎｄの設定画面であった場合の一例を示す。
　図２３Ｂに示す表示領域ｅ１４は、当該アイコンの識別子を示す。
　図２３Ｂに示す表示領域ｅ１５は、処理の対象を選択するフォームである。選択項目はシステム側が提供する有限の要素である。
　図２３Ｂに示す表示領域ｅ１６は、処理の内容を選択するフォームである。選択項目はシステム側が提供する有限の要素である。
　図２３Ｂに示す表示領域ｅ１７は、表示領域ｅ１６だけでは表現しきれない処理の内容の詳細を入力するフォームである。該情報は、システム管理者による自然言語で登録される。
　要するに、メタ復旧方法の定義では、復旧の開始から終了までにおけるオブジェクトの遷移の流れが定義される。具体的には、どのオブジェクト（条件分岐又は処理）からどのオブジェクトに遷移するかが定義される。
　＜２－４：メタ復旧方法の取得＞。
　メタ復旧方法の取得は、例えば、実施例１におけるステップ１０１５のメタＲＣＡルールを抽出する直後に実施される。メタ復旧方法登録時にメタＲＣＡルールに対応づけて登録したため、メタＲＣＡルールが決定すれば、メタ復旧方法も決定されることになる。
　実施例１におけるステップ１０１９で、メタ復旧方法も一緒に送信される。
　実施例１におけるステップ１０２０で、根本原因と確信度の他に、メタ復旧方法も表示される。
　図２３は、実施例２で表示される候補／確信度画面の一例である。
　実施例１の図１９と比較して、得られた全てのメタ復旧方法の内、Ｃｏｍｍａｎｄの処理内容の累計を示した表である表示領域ｅ２１と、メタ復旧方法のＣｏｍｍａｎｄの処理一覧をリストアップした列である列ｅ２２が追加されている。
　表示領域ｅ２１によれば、「サーバリブート７件、サーバリプレース２件、バックアップからのリカバリ２件」と表示されている。これにより、システム管理者は、採り得る復旧における処理のバリエーションを特定し易い。
　列ｅ２２には、各根本原因に対応する復旧方法の概要が記載されている。これにより、システム管理者は、各根本原因に対応する復旧方法の概要を迅速に特定することができる。
　以上、本発明の実施例２によれば、条件分岐（Ｂｒａｎｃｈ）及び処置（Ｃｏｍｍａｎｄ）といった共通パーツを用いた一連のフローで定義されたメタ復旧方法が用意される。そして、イベント群と根本原因との組み合わせのメタＲＣＡルールに、メタ復旧方法が関連付けられる。これにより、発生した障害の検出から復旧方法までを一つのルールとして定義できる。
　＜３－０：実施例３の概要＞。
　既存の一般的なルールベースシステムを用いた場合のデータ構造について具体例を示す。以下の記述は、実施例１に記載の各種情報の抽象化した場合の一つの具体例であるが、ルールベースシステムの場合は、時間的な条件など二つ以上の物理的又は論理的な対象間の関係以外の記述も可能である。
　本実施例は、前述した非特許文献１の汎用的ルールベースシステムが適用された本発明の一実施例である。
　非特許文献１によれば、ルールメモリとファクトメモリをルールベースシステム上にもつ汎用的ルールベースシステムが開示されている。ルールメモリは、特定の個体に依存せず記述された汎用ルールが格納されている。ファクトメモリは、特定の個体の具体的な情報が格納されている。
　該ルールベースシステムは、該ルールと該情報を用いて、新しい事実を導出するシステムである。
　＜３－１：実施例３の具体的データ構造＞。
　非特許文献１を基に、ルールとして、Ｃａｕｓａｌｉｔｙ　ＲｕｌｅとＴｏｐｏｌｏｇｙ　Ｒｕｌｅを定義する。
　Ｃａｕｓａｌｉｔｙ　Ｒｕｌｅとは、イベントとその原因の関係を、特定トポロジに依存せず記述したルールである。具体的なＣａｕｓａｌｉｔｙ　Ｒｕｌｅの例は以下の通りである。
　Ｃ－ＲＵＬＥ－１００：
ＩＦ　Ｓｅｒｖｅｒ（Ｘ）　＆　Ｓｔｏｒａｇｅ（Ｙ）　＆　ＦＣ－Ｃｏｎｎｅｃｔｅｄ（ｘ，ｙ）　＆　ＥｖｅｎｔＨａｐｐｅｎｓＯｎ（ＩＯ＿ＥＲＲＯＲ，　ｘ，　ｙ，　ｔ１）　＆　ＥｖｅｎｔＨａｐｐｅｎｓＯｎ（ＣＴＲＬ＿ＦＡＩＬ，　ｙ，　ｔ２）　＆　ＷｉｔｈｉｎＴｉｍｅＷｉｎｄｏｗ（ｔ１，　ｔ２，　“１０　ｍｉｎｕｔｅｓ”）
ＴＨＥＮ　ＩｄｅｎｔｉｆｙＲｏｏｔＣａｕｓｅ（ＣＴＲＬ＿ＦＡＩＬ，　ｙ）
　Ｔｏｐｏｌｏｇｙ　Ｒｕｌｅとは、ノードの接続状態を、特定トポロジに依存せず記述したルールである。具体的なＴｏｐｏｌｏｇｙ　Ｒｕｌｅの例は以下の通りである。
　Ｔ－ＲＵＬＥ－２００：
ＩＦ　ＦＣ－ｃｏｎｎｅｃｔｅｄ（ｘ，ｙ）＆　ＦＣ－ｃｏｎｎｅｃｔ（ｚ，ｙ）
ＴＨＥＮ　ＦＣ－ｃｏｎｎｅｃｔｅｄ（ｘ、ｚ）。
　ｘ、ｙなどの小文字のアルファベットは変数を示す。ＩＯ＿ＥＲＲＯＲ、“ＳｅｒｖｅｒＡ”は定数（特定のインスタンス）を示すリテラルとする。
　トポロジ適用プログラム１２１は、Ｃａｕｓａｌｉｔｙ　ＲｕｌｅとＴｏｐｏｌｏｇｙ　Ｒｕｌｅをルールベースシステム上のルールメモリに格納する。
　トポロジ適用プログラム１２１は、Ｔｏｐｌｏｇｙルールを監視対象ノード３０に適用することで、下記トポロジファクトを検出し、ルールベースシステム上のファクトメモリに格納する。
ＴＦ１：　Ｓｅｒｅｒ（“ＳｅｒｖｅｒＡ”）
ＴＦ２：　Ｓｔｏｒａｇｅ（“ＳｔｏｒａｇｅＡ”）
ＴＦ３：　Ｓｗｉｔｃｈ（“ＳｗｉｔｃｈＡ”）
ＴＦ４：　ＦＣ－Ｃｏｎｎｅｃｔｅｄ（“ＳｅｒｖｅｒＡ”，　“ＡＢＣ”）
ＴＦ５：　ＦＣ－Ｃｏｎｎｅｃｔｅｄ（“ＡＭＳ１０００”，　“ＡＢＣ”）。
　ルールベースシステムは、Ｃａｕｓａｌｉｔｙ　Ｒｕｌｅとトポロジファクトを組み合わせて、以下の例のようなインスタンスを作成する。
　Ｃ－ＲＵＬＥ－１００－ＩＮＳＴＡＮＣＥ－１：
ＩＦ　ＥｖｅｎｔＨａｐｐｅｎｓＯｎ（ＩＯ＿ＥＲＲＯＲ，　“ＳｅｒｖｅｒＡ”，ｔ１）　＆　ＥｖｅｎｔＨａｐｐｅｎｓＯｎ（ＣＴＲＬ＿ＦＡＩＬ，　“ＳｔｏｒａｇｅＡ”，ｔ２）　＆　ＷｉｔｈｉｎＴｉｍｅＷｉｎｄｏｗ（ｔ１，　ｔ２，　“１０　ｍｉｎｕｔｅｓ”）
ＴＨＥＮ　ＩｄｅｎｔｉｆｙＲｏｏｔＣａｕｓｅ（ＣＴＲＬ＿ＦＡＩＬ，　“ＳｔｏｒａｇｅＡ”）。
　Ｃ－ＲＵＬＥ－１００－ＩＮＳＴＡＮＣＥ－１もメモリ上に格納される。
　トポロジ適用プログラム１２１が監視対象ノード３０を監視しており，"ＳｅｒｖｅｒＡ"でＩＯ＿ＥＲＲＯＲイベントと、“ＳｔｏｒａｇｅＡ”でＣＴＲＬ＿ＦＡＩＬイベントが、イベント相関処理の時間幅内で発生したことを観測した場合、トポロジ適用プログラム１２１は，ルールベースシステムに対して、次のイベントファクトをメモリに格納する。
EF1:
EventHappensOn(IO_ERROR,  "ServerA", "12:32:12 22009/03/10")
EF2:
EventHappensOn(CTRL_FAIL, "AMS1000", "12:32:10 22009/03/10")
EF3:
WithinTimeWindow("12:32:10 22009/03/10", "12:32:12
22009/03/10", "10 minutes")。
　ルールベースシステムは、Ｃ－ＲＵＬＥ－１００－ＩＮＳＴＡＮＣＥ－１とイベントファクトから、ＩｄｅｎｔｉｆｙＲｏｏｔＣａｕｓｅ（ＣＴＲＬ＿ＦＡＩＬ，　“ＳｔｏｒａｇｅＡ”）を導出し、これにより根本原因が特定できる。
　上記の枠組みでは、
Ｃ－ＲＵＬＥ－１００－ＩＮＳＴＡＮＣＥ－１という中間形式が展開ＲＣＡルールであり、
Ｃ－ＲＵＬＥ－１００（Ｃａｕｓａｌｉｔｙ　Ｒｕｌｅ）がメタＲＣＡルールに対応し、"Ｃ－ＲＵＬＥ－１００"がメタＲＣＡルールＩＤ５４１となる。
　複数のＣａｕｓａｌｉｔｙ　Ｒｕｌｅを用いて多段推論が行われる場合もあり，メタＲＣＡルールは複数あってよい。
　本実施例では、メモリの中を参照し、根本原因の導出に利用されたメタＲＣＡルールと対応したＣａｕｓａｌｉｔｙ　Ｒｕｌｅや、展開ＲＣＡルールと対応したインスタンスを取得し、障害分析コンテキストとして扱うことで、本発明の効果を得ることができる。
　以上のように、一般的なルールベースシステムを適用することができる。なお、展開ＲＣＡルール情報のデータ構造として、以下のような格納形式が採用されてもよい。
（Ａ）監視対象ノードで発生して管理システムが管理対象とする発生部位（含むノード装置）及びイベント内容を区別するイベントについて、全ての組み合わせパターンを格納する。
（Ｂ）（Ａ）の組み合わせの中で根本原因を特定可能な組み合わせについては、根本原因とする発生部位（ノード装置を含む）及びイベント内容を対応させて格納する。
　なお、対応する根本原因がない（Ａ）の組み合わせの格納が省略されてもよい。
　以上の説明により、本発明の一つの観点である、複数のノード装置と通信するインターフェースと、前記インターフェースを介して、前記複数のノード装置で発生するイベントを検知するプロセッサと、イベント情報と、メタルール情報と、障害履歴情報と、を格納する記憶資源と、前記複数のノード装置についての情報を表示する表示装置と、入力装置と、を備える管理システムについて：
＊前記イベント情報は、前記発生したイベントの発生元ノード装置を特定する情報と、前記発生したイベントの種別と、を示すイベントエントリを含む。
＊前記メタルール情報は、ノード装置で潜在的に発生する可能性のある潜在イベントの種別と、前記潜在イベントの種別に対応するイベントが発生した場合に根本原因と特定可能なイベントの種別とを示すメタルール、を含む。
＊前記障害履歴情報は、復旧方法を示す情報及び前記復旧方法が対応する前記メタルールを識別する情報を含む障害履歴エントリ、を含む。
　＊前記プロセッサは：
（Ａ）前記メタルール情報に基づき、前記イベント情報に格納した前記イベントエントリで特定される第一のイベントの根本原因である第一の原因イベントを特定し、前記第一の原因イベントの特定に用いた第一のメタルールを特定し；
（Ｂ）前記第一の原因イベントから復旧する方法である第一の復旧方法を、前記入力装置を介して受信し、前記第一の復旧方法に基づいて、前記障害履歴情報に前記第一のメタルールに対応する第一の障害履歴エントリを追加し；
（Ｃ）前記メタルール情報に基づき、前記イベント情報に格納した前記イベントエントリで特定される第二のイベントの根本原因である第二の原因イベントを特定し、第二の原因イベントの特定に用いた第二のメタルールを特定し；
（Ｄ）前記障害履歴情報に基づき、前記第二のメタルールに対応する所定の障害履歴エントリを特定する。
　＊前記表示装置は：
（Ｘ）前記第二の原因イベントに関する情報を、前記第二のイベントの根本原因として表示し；
（Ｙ）前記所定の障害履歴エントリに基づき、前記第二の原因イベントからの復旧方法を表示する、
ことを特徴とした管理システムについて説明した。
　なお、管理システムは、前記障害履歴エントリは復旧方法を適用したノード装置の識別子を含み、前記表示装置は：
（Ｚ）前記所定の障害履歴エントリが示すノード装置の識別子を、前記（Ｙ）の前記所定の障害履歴エントリが示す復旧方法を適用したノード装置の識別子として表示してもよい。
　また、管理システムは、前記第一の原因イベントの発生元ノード装置と前記第二の原因イベントの発生元ノード装置は異なるノード装置の場合、前記表示装置は：
（ａ）前記（Ｘ）の前記第二の原因イベントに関する情報の表示として、前記第二の原因イベントの発生元ノード装置の識別子を含む情報を表示し、
（ｂ）前記（Ｚ）の前記所定の障害履歴エントリが示すノード装置の識別子の表示として、前記第一の原因イベントの発生元ノード装置の識別子を表示してもよい。
　また、前記（Ｄ）の特定は：
（Ｄ１）前記第二のメタルールと同一のメタルールのを示す前記障害履歴エントリを選択し、
（Ｄ２）前記（Ｄ１）により選択された障害履歴エントリの数が第一の閾値未満の場合は、前記障害履歴エントリが対応するメタルールと、前記第二のメタルールとのマッチング率に基づいて前記所定の障害履歴エントリを特定し、
（Ｄ３）前記（Ｄ１）により選択された障害履歴エントリを前記所定の障害履歴エントリと特定してもよい。
　また、前記記憶資源は、前記複数のノード装置の構成設定情報を格納し、前記障害履歴エントリは、前記複数のノード装置の当該エントリ作成時点に対応する過去の構成設定情報を含み、前記（Ｄ）の特定は：
　（Ｄ４）前記（Ｄ１）により選択された障害履歴エントリの数が第二の閾値以上の場合は、前記障害履歴エントリに含まれる前記過去の構成設定情報と、前記構成設定情報とのマッチング率に基づいて、前記所定の障害履歴エントリを特定してもよい。
　なお、上記（Ｄ４）は（Ｄ２）及び（Ｄ３）を前提としなくてもよい。また、前記記憶資源は、構成設定情報の項目についての重み値を示す、重み情報を格納し、前記（Ｄ４）の特定は、前記重み情報に基づいて行われてもよい。
　また、前記（Ｂ）の第一の復旧方法は、前記第一の原因イベントの発生元ノード装置の識別子を含まない復旧方法であるメタ復旧方法であり、前記（Ｙ）の前記第二の原因イベントからの復旧方法の表示は、前記メタ復旧方法と前記第二の原因イベントの発生元ノード装置の識別子との表示であってもよい。
　記憶資源は、管理システムの中にあっても良いし外にあっても良い。中にある場合、記憶資源は、例えば、メモリである。外にある場合、記憶資源は、例えば、ストレージ装置（例えばディスクアレイ装置）である。
　以上、本発明の幾つかの実施例を説明したが、これらは本発明の説明のための例示であって、本発明の範囲をこれらの実施例にのみ限定する趣旨ではない。本発明は、他の種々の形態でも実施することが可能である。
１０：管理サーバ

Claims (15)

  1. 　複数のノード装置と、
    　前記複数のノード装置で発生するイベントを検知する管理システムと、
    　を備える計算機システムであって、
    　前記管理システムは、イベント情報と、メタルール情報と、障害履歴情報と、を格納し、
    　前記イベント情報は、前記発生したイベントの発生元ノード装置を特定する情報と、前記発生したイベントの種別と、を示すイベントエントリを含み、
    　前記メタルール情報は、ノード装置で潜在的に発生する可能性のある潜在イベントの種別と、前記潜在イベントの種別に対応するイベントが発生した場合に根本原因と特定可能なイベントの種別とを示すメタルール、を含み、
    　前記障害履歴情報は、復旧方法を示す情報及び前記復旧方法が対応する前記メタルールを識別する情報を含む障害履歴エントリ、を含み、
    　前記管理システムは：
    　（Ａ）前記メタルール情報に基づき、前記イベント情報に格納した前記イベントエントリで特定される第一のイベントの根本原因である第一の原因イベントを特定し、前記第一の原因イベントの特定に用いた第一のメタルールを特定し；
    　（Ｂ）前記第一の原因イベントから復旧する方法である第一の復旧方法を、前記入力装置を介して受信し、前記第一の復旧方法に基づいて、前記障害履歴情報に前記第一のメタルールに対応する第一の障害履歴エントリを追加し；
    　（Ｃ）前記メタルール情報に基づき、前記イベント情報に格納した前記イベントエントリで特定される第二のイベントの根本原因である第二の原因イベントを特定し、第二の原因イベントの特定に用いた第二のメタルールを特定し；
    　（Ｄ）前記障害履歴情報に基づき、前記第二のメタルールに対応する所定の障害履歴エントリを特定し、
    　（Ｘ）前記第二の原因イベントに関する情報を、前記第二のイベントの根本原因として表示し；
    　（Ｙ）前記所定の障害履歴エントリに基づき、前記第二の原因イベントからの復旧方法を表示する、
    　ことを特徴とした計算機システム。
  2. 　請求項１記載の計算機システムであって、
    　前記障害履歴エントリは、復旧方法を適用したノード装置の識別子を含み、
    　前記管理システムは：
    　（Ｚ）前記所定の障害履歴エントリが示すノード装置の識別子を、前記（Ｙ）の前記所定の障害履歴エントリが示す復旧方法を適用したノード装置の識別子として表示する、
    　ことを特徴とした計算機システム。
  3. 　請求項２記載の計算機システムであって、
    　前記第一のメタルールと前記第二のメタルールが同一の場合、前記（Ｙ）の前記所定の障害履歴エントリが示す復旧方法は、前記第一の障害履歴エントリが示す第一の復旧方法であり、
    　前記第一の原因イベントの発生元ノード装置と前記第二の原因イベントの発生元ノード装置は異なるノード装置の場合、前記管理システムは：
    　（ａ）前記（Ｘ）の前記第二の原因イベントに関する情報の表示として、前記第二の原因イベントの発生元ノード装置の識別子を含む情報を表示し、
    　（ｂ）前記（Ｚ）の前記所定の障害履歴エントリが示すノード装置の識別子の表示として、前記第一の原因イベントの発生元ノード装置の識別子を表示する、
    　ことを特徴とした計算機システム。
  4. 　請求項２記載の計算機システムであって、
    　前記（Ｄ）の特定は：
    　（Ｄ１）前記第二のメタルールと同一のメタルールを示す前記障害履歴エントリを選択し、
    　（Ｄ２）前記（Ｄ１）により選択された障害履歴エントリの数が第一の閾値未満の場合は、前記障害履歴エントリが対応するメタルールと、前記第二のメタルールとのマッチング率に基づいて前記所定の障害履歴エントリを特定し、
    　（Ｄ３）前記（Ｄ１）により選択された障害履歴エントリを前記所定の障害履歴エントリと特定する、
    　ことを特徴とした計算機システム。
  5. 　請求項４記載の計算機システムであって、
    　前記記憶資源は、前記複数のノード装置の構成設定情報を格納し、
    　前記障害履歴エントリは、前記複数のノード装置の当該エントリ作成時点に対応する過去の構成設定情報を含み、
    　前記（Ｄ）の特定は：
    　（Ｄ４）前記（Ｄ１）により選択された障害履歴エントリの数が第二の閾値以上の場合は、前記障害履歴エントリに含まれる前記過去の構成設定情報と、前記構成設定情報とのマッチング率に基づいて、前記所定の障害履歴エントリを特定する、
    　ことを特徴とした計算機システム。
  6. 　請求項５記載の計算機システムであって、
    　前記記憶資源は、構成設定情報の項目についての重み値を示す重み情報を格納し、
    　前記（Ｄ４）の特定は、前記重み情報に基づいて行われる、
    　ことを特徴とした計算機システム。
  7. 　請求項１記載の計算機システムであって、
    　前記（Ｂ）の第一の復旧方法は、前記第一の原因イベントの発生元ノード装置の識別子を含まない復旧方法であるメタ復旧方法であり、
    　前記（Ｙ）の前記第二の原因イベントからの復旧方法の表示は、前記メタ復旧方法と前記第二の原因イベントの発生元ノード装置の識別子との表示である、
    　ことを特徴とした計算機システム。
  8. 　複数のノード装置と通信するインターフェースと、
    　前記インターフェースを介して、前記複数のノード装置で発生するイベントを検知するプロセッサと、
    　イベント情報と、メタルール情報と、障害履歴情報と、を格納する記憶資源と、
    　前記複数のノード装置についての情報を表示する表示装置と、
    　入力装置と、
    　を備え、
    　前記イベント情報は、前記発生したイベントの発生元ノード装置を特定する情報と、前記発生したイベントの種別と、を示すイベントエントリを含み、
    　前記メタルール情報は、ノード装置で潜在的に発生する可能性のある潜在イベントの種別と、前記潜在イベントの種別に対応するイベントが発生した場合に根本原因と特定可能なイベントの種別とを示すメタルール、を含み、
    　前記障害履歴情報は、復旧方法を示す情報及び前記復旧方法が対応する前記メタルールを識別する情報を含む障害履歴エントリ、を含み、
    　前記プロセッサは：
    　（Ａ）前記メタルール情報に基づき、前記イベント情報に格納した前記イベントエントリで特定される第一のイベントの根本原因である第一の原因イベントを特定し、前記第一の原因イベントの特定に用いた第一のメタルールを特定し；
    　（Ｂ）前記第一の原因イベントから復旧する方法である第一の復旧方法を、前記入力装置を介して受信し、前記第一の復旧方法に基づいて、前記障害履歴情報に前記第一のメタルールに対応する第一の障害履歴エントリを追加し；
    　（Ｃ）前記メタルール情報に基づき、前記イベント情報に格納した前記イベントエントリで特定される第二のイベントの根本原因である第二の原因イベントを特定し、第二の原因イベントの特定に用いた第二のメタルールを特定し；
    　（Ｄ）前記障害履歴情報に基づき、前記第二のメタルールに対応する所定の障害履歴エントリを特定し、
    　前記表示装置は：
    　（Ｘ）前記第二の原因イベントに関する情報を、前記第二のイベントの根本原因として表示し；
    　（Ｙ）前記所定の障害履歴エントリに基づき、前記第二の原因イベントからの復旧方法を表示する、
    　ことを特徴とした管理システム。
  9. 　請求項８記載の管理システムであって、
    　前記障害履歴エントリは復旧方法を適用したノード装置の識別子を含み、
    　前記表示装置は：
    　（Ｚ）前記所定の障害履歴エントリが示すノード装置の識別子を、前記（Ｙ）の前記所定の障害履歴エントリが示す復旧方法を適用したノード装置の識別子として表示する、
    　ことを特徴とした管理システム。
  10. 　請求項９記載の管理システムであって、
    　前記第一の原因イベントの発生元ノード装置と前記第二の原因イベントの発生元ノード装置は異なるノード装置の場合、前記表示装置は：
    　（ａ）前記（Ｘ）の前記第二の原因イベントに関する情報の表示として、前記第二の原因イベントの発生元ノード装置の識別子を含む情報を表示し、
    　（ｂ）前記（Ｚ）の前記所定の障害履歴エントリが示すノード装置の識別子の表示として、前記第一の原因イベントの発生元ノード装置の識別子を表示する、
    　ことを特徴とした管理システム。
  11. 　請求項９記載の管理システムであって、
    　前記（Ｄ）の特定は：
    　（Ｄ１）前記第二のメタルールと同一のメタルールのを示す前記障害履歴エントリを選択し、
    　（Ｄ２）前記（Ｄ１）により選択された障害履歴エントリの数が第一の閾値未満の場合は、前記障害履歴エントリが対応するメタルールと、前記第二のメタルールとのマッチング率に基づいて前記所定の障害履歴エントリを特定し、
    　（Ｄ３）前記（Ｄ１）により選択された障害履歴エントリを前記所定の障害履歴エントリと特定する、
    　ことを特徴とした管理システム。
  12. 　請求項１１記載の管理システムであって、
    　前記記憶資源は、前記複数のノード装置の構成設定情報を格納し、
    　前記障害履歴エントリは、前記複数のノード装置の当該エントリ作成時点に対応する過去の構成設定情報を含み、
    　前記（Ｄ）の特定は：
    　（Ｄ４）前記（Ｄ１）により選択された障害履歴エントリの数が第二の閾値以上の場合は、前記障害履歴エントリに含まれる前記過去の構成設定情報と、前記構成設定情報とのマッチング率に基づいて、前記所定の障害履歴エントリを特定する、
    　ことを特徴とした管理システム。
  13. 　請求項１２記載の管理システムであって、
    　前記記憶資源は、構成設定情報の項目についての重み値を示す、重み情報を格納し、
    　前記（Ｄ４）の特定は、前記重み情報に基づいて行われる、
    　ことを特徴とした管理システム。
  14. 　請求項８記載の管理システムであって、
    　前記（Ｂ）の第一の復旧方法は、前記第一の原因イベントの発生元ノード装置の識別子を含まない復旧方法であるメタ復旧方法であり、
    　前記（Ｙ）の前記第二の原因イベントからの復旧方法の表示は、前記メタ復旧方法と前記第二の原因イベントの発生元ノード装置の識別子との表示である、
    　ことを特徴とした管理システム。
  15. 　複数のノード装置を管理する管理システムの管理方法であって、
    　前記管理システムは、複数のノード装置で発生しうるイベントについて、根本原因となる事象を特定するメタルールと、メタルールに対応させた障害復旧方法と、を有し、
    前記管理システムは、管理サーバが検知したイベントの根本原因となる原因イベントと、前記原因イベントからの復旧方法と、を表示する。
    　ことを特徴とした管理システムの管理方法。
PCT/JP2009/003358 2009-07-16 2009-07-16 障害の根本原因に対応した復旧方法を表す情報を出力する管理システム WO2011007394A1 (ja)

Priority Applications (6)

Application Number Priority Date Filing Date Title
JP2011522628A JP5385982B2 (ja) 2009-07-16 2009-07-16 障害の根本原因に対応した復旧方法を表す情報を出力する管理システム
PCT/JP2009/003358 WO2011007394A1 (ja) 2009-07-16 2009-07-16 障害の根本原因に対応した復旧方法を表す情報を出力する管理システム
US12/529,522 US8429453B2 (en) 2009-07-16 2009-07-16 Management system for outputting information denoting recovery method corresponding to root cause of failure
EP09847293A EP2455863A4 (en) 2009-07-16 2009-07-16 MANAGEMENT SYSTEM FOR PROVIDING INFORMATION DESCRIBING A RECOVERY METHOD CORRESPONDING TO A FUNDAMENTAL CAUSE OF FAILURE
CN200980160965.4A CN102473129B (zh) 2009-07-16 2009-07-16 输出表示与故障的根本原因对应的恢复方法的信息的管理系统
US13/845,992 US9189319B2 (en) 2009-07-16 2013-03-18 Management system for outputting information denoting recovery method corresponding to root cause of failure

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2009/003358 WO2011007394A1 (ja) 2009-07-16 2009-07-16 障害の根本原因に対応した復旧方法を表す情報を出力する管理システム

Related Child Applications (2)

Application Number Title Priority Date Filing Date
US12/529,522 A-371-Of-International US8429453B2 (en) 2009-07-16 2009-07-16 Management system for outputting information denoting recovery method corresponding to root cause of failure
US13/845,992 Continuation US9189319B2 (en) 2009-07-16 2013-03-18 Management system for outputting information denoting recovery method corresponding to root cause of failure

Publications (1)

Publication Number Publication Date
WO2011007394A1 true WO2011007394A1 (ja) 2011-01-20

Family

ID=43449016

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2009/003358 WO2011007394A1 (ja) 2009-07-16 2009-07-16 障害の根本原因に対応した復旧方法を表す情報を出力する管理システム

Country Status (5)

Country Link
US (2) US8429453B2 (ja)
EP (1) EP2455863A4 (ja)
JP (1) JP5385982B2 (ja)
CN (1) CN102473129B (ja)
WO (1) WO2011007394A1 (ja)

Cited By (8)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012174232A (ja) * 2011-02-24 2012-09-10 Fujitsu Ltd 監視装置、監視システムおよび監視方法
WO2014141460A1 (ja) * 2013-03-15 2014-09-18 株式会社日立製作所 管理システム
WO2014162595A1 (ja) 2013-04-05 2014-10-09 株式会社日立製作所 管理システム及び管理プログラム
JP5719974B2 (ja) * 2012-09-03 2015-05-20 株式会社日立製作所 複数の監視対象デバイスを有する計算機システムの管理を行う管理システム
JP2015156225A (ja) * 2015-03-23 2015-08-27 株式会社日立製作所 複数の監視対象デバイスを有する計算機システムの管理を行う管理システム
EP2674865A4 (en) * 2011-09-26 2016-06-01 Hitachi Ltd ADMINISTRATIVE COMPUTERS AND METHODS OF BASIC ANALYSIS
JPWO2014068659A1 (ja) * 2012-10-30 2016-09-08 株式会社日立製作所 管理計算機およびルール生成方法
JPWO2015079564A1 (ja) * 2013-11-29 2017-03-16 株式会社日立製作所 イベントの根本原因の解析を支援する管理システム及び方法

Families Citing this family (40)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2455863A4 (en) * 2009-07-16 2013-03-27 Hitachi Ltd MANAGEMENT SYSTEM FOR PROVIDING INFORMATION DESCRIBING A RECOVERY METHOD CORRESPONDING TO A FUNDAMENTAL CAUSE OF FAILURE
JP5419746B2 (ja) * 2010-02-23 2014-02-19 株式会社日立製作所 管理装置及び管理プログラム
US8451739B2 (en) 2010-04-15 2013-05-28 Silver Spring Networks, Inc. Method and system for detecting failures of network nodes
US8943364B2 (en) * 2010-04-30 2015-01-27 International Business Machines Corporation Appliance for storing, managing and analyzing problem determination artifacts
US8429455B2 (en) * 2010-07-16 2013-04-23 Hitachi, Ltd. Computer system management method and management system
US8572434B2 (en) 2010-09-29 2013-10-29 Sepaton, Inc. System health monitor
US8386850B2 (en) * 2010-09-29 2013-02-26 Sepaton, Inc. System health monitor
WO2013057790A1 (ja) * 2011-10-18 2013-04-25 富士通株式会社 情報処理装置、時刻補正値決定方法、およびプログラム
CN103176873A (zh) * 2011-12-23 2013-06-26 鸿富锦精密工业（深圳）有限公司 计数卡
US8977886B2 (en) * 2012-02-14 2015-03-10 Alcatel Lucent Method and apparatus for rapid disaster recovery preparation in a cloud network
JP5684946B2 (ja) * 2012-03-23 2015-03-18 株式会社日立製作所 イベントの根本原因の解析を支援する方法及びシステム
US8996532B2 (en) 2012-05-21 2015-03-31 International Business Machines Corporation Determining a cause of an incident based on text analytics of documents
WO2014001841A1 (en) * 2012-06-25 2014-01-03 Kni Műszaki Tanácsadó Kft. Methods of implementing a dynamic service-event management system
US9576318B2 (en) * 2012-09-25 2017-02-21 Mx Technologies, Inc. Automatic payment and deposit migration
JP5839133B2 (ja) * 2012-12-12 2016-01-06 三菱電機株式会社 監視制御装置及び監視制御方法
US10169122B2 (en) * 2013-04-29 2019-01-01 Moogsoft, Inc. Methods for decomposing events from managed infrastructures
CN103440174B (zh) * 2013-08-02 2016-05-25 杭州华为数字技术有限公司 一种错误信息处理方法、装置及应用该装置的电子设备
JP6190468B2 (ja) * 2013-10-30 2017-08-30 株式会社日立製作所 管理システム、プラン生成方法、およびプラン生成プログラム
CN104035849B (zh) * 2014-06-19 2017-02-15 浪潮电子信息产业股份有限公司 一种防止Rack机柜风扇管理失效的方法
DE112015006084T5 (de) * 2015-01-30 2017-10-12 Hitachi, Ltd. Systemverwaltungsvorrichtung und systemverwaltungssystem
US9692815B2 (en) 2015-11-12 2017-06-27 Mx Technologies, Inc. Distributed, decentralized data aggregation
US9830150B2 (en) 2015-12-04 2017-11-28 Google Llc Multi-functional execution lane for image processor
US10180869B2 (en) * 2016-02-16 2019-01-15 Microsoft Technology Licensing, Llc Automated ordering of computer system repair
CN105786635B (zh) * 2016-03-01 2018-10-12 国网江苏省电力公司电力科学研究院 一种面向故障敏感点动态检测的复杂事件处理系统及方法
US9922539B1 (en) * 2016-08-05 2018-03-20 Sprint Communications Company L.P. System and method of telecommunication network infrastructure alarms queuing and multi-threading
JP6885193B2 (ja) * 2017-05-12 2021-06-09 富士通株式会社 並列処理装置、ジョブ管理方法、およびジョブ管理プログラム
US10977154B2 (en) * 2018-08-03 2021-04-13 Dynatrace Llc Method and system for automatic real-time causality analysis of end user impacting system anomalies using causality rules and topological understanding of the system to effectively filter relevant monitoring data
US10282248B1 (en) * 2018-11-27 2019-05-07 Capital One Services, Llc Technology system auto-recovery and optimality engine and techniques
US10824528B2 (en) 2018-11-27 2020-11-03 Capital One Services, Llc Techniques and system for optimization driven by dynamic resilience
US11093319B2 (en) * 2019-05-29 2021-08-17 Microsoft Technology Licensing, Llc Automated recovery of webpage functionality
US11907087B2 (en) 2019-07-10 2024-02-20 International Business Machines Corporation Remote health monitoring in data replication environments
US11281694B2 (en) 2019-07-10 2022-03-22 International Business Machines Cormoration Remote data capture in data replication environments
US10686645B1 (en) 2019-10-09 2020-06-16 Capital One Services, Llc Scalable subscriptions for virtual collaborative workspaces
EP3823215A1 (en) * 2019-11-18 2021-05-19 Juniper Networks, Inc. Network model aware diagnosis of a network
CN113206749B (zh) 2020-01-31 2023-11-17 瞻博网络公司 网络事件的相关性的可编程诊断模型
CN113328872B (zh) * 2020-02-29 2023-03-28 华为技术有限公司 故障修复方法、装置和存储介质
US11765015B2 (en) * 2020-03-19 2023-09-19 Nippon Telegraph And Telephone Corporation Network management apparatus, method, and program
US11269711B2 (en) 2020-07-14 2022-03-08 Juniper Networks, Inc. Failure impact analysis of network events
US20220182278A1 (en) * 2020-12-07 2022-06-09 Citrix Systems, Inc. Systems and methods to determine root cause of connection failures
JP2022115316A (ja) * 2021-01-28 2022-08-09 株式会社日立製作所 ログ検索支援装置、及びログ検索支援方法

Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004061681A1 (ja) * 2002-12-26 2004-07-22 Fujitsu Limited 運用管理方法および運用管理サーバ
JP2006526842A (ja) 2003-03-31 2006-11-24 システム マネージメント アーツ，インク． 兆候除外付きコードブック相関を使用するシステム管理のための方法および装置
JP2006338305A (ja) * 2005-06-01 2006-12-14 Toshiba Corp 監視装置及び監視プログラム
US7478404B1 (en) 2004-03-30 2009-01-13 Emc Corporation System and methods for event impact analysis
JP2009043029A (ja) 2007-08-09 2009-02-26 Hitachi Ltd 関連ｄｂ作成装置
JP2009064101A (ja) * 2007-09-04 2009-03-26 Toshiba Corp 遠隔監視システム及び遠隔監視方法

Family Cites Families (68)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US4779208A (en) * 1983-09-28 1988-10-18 Hitachi, Ltd. Information processing system and method for use in computer systems suitable for production system
US5261086A (en) * 1987-10-26 1993-11-09 Nec Corporation Performance analyzing and diagnosing system for computer systems
US5214653A (en) * 1990-10-22 1993-05-25 Harris Corporation Fault finder expert system
US5572670A (en) * 1994-01-10 1996-11-05 Storage Technology Corporation Bi-directional translator for diagnostic sensor data
US5557765A (en) * 1994-08-11 1996-09-17 Trusted Information Systems, Inc. System and method for data recovery
US6072777A (en) * 1996-06-28 2000-06-06 Mci Communications Corporation System and method for unreported root cause analysis
US6226659B1 (en) * 1996-09-16 2001-05-01 Oracle Corporation Method and apparatus for processing reports
EP1021804A4 (en) * 1997-05-06 2002-03-20 Speechworks Int Inc SYSTEM AND METHOD FOR DEVELOPING INTERACTIVE LANGUAGE APPLICATIONS
US7500143B2 (en) * 2000-05-05 2009-03-03 Computer Associates Think, Inc. Systems and methods for managing and analyzing faults in computer networks
US7752024B2 (en) * 2000-05-05 2010-07-06 Computer Associates Think, Inc. Systems and methods for constructing multi-layer topological models of computer networks
WO2002087152A1 (en) * 2001-04-18 2002-10-31 Caveo Technology, Llc Universal, customizable security system for computers and other devices
EP1405187B1 (en) 2001-07-06 2019-04-10 CA, Inc. Method and system for correlating and determining root causes of system and enterprise events
US6792393B1 (en) * 2001-12-03 2004-09-14 At&T Corp. System and method for diagnosing computer system operational behavior
US20040153692A1 (en) * 2001-12-28 2004-08-05 O'brien Michael Method for managing faults it a computer system enviroment
US7194445B2 (en) * 2002-09-20 2007-03-20 Lenovo (Singapore) Pte. Ltd. Adaptive problem determination and recovery in a computer system
US7254515B1 (en) * 2003-03-31 2007-08-07 Emc Corporation Method and apparatus for system management using codebook correlation with symptom exclusion
US20050091356A1 (en) * 2003-10-24 2005-04-28 Matthew Izzo Method and machine-readable medium for using matrices to automatically analyze network events and objects
JP2005165847A (ja) * 2003-12-04 2005-06-23 Fujitsu Ltd ポリシールールシナリオ制御装置及び制御方法
US7965620B2 (en) * 2004-05-25 2011-06-21 Telcordia Licensing Company, Llc Method, computer product and system for correlating events in a network
JP3826940B2 (ja) * 2004-06-02 2006-09-27 日本電気株式会社 障害復旧装置および障害復旧方法、マネージャ装置並びにプログラム
US7536370B2 (en) * 2004-06-24 2009-05-19 Sun Microsystems, Inc. Inferential diagnosing engines for grid-based computing systems
US20060112061A1 (en) * 2004-06-24 2006-05-25 Masurkar Vijay B Rule based engines for diagnosing grid-based computing systems
US7631222B2 (en) * 2004-08-23 2009-12-08 Cisco Technology, Inc. Method and apparatus for correlating events in a network
US7373552B2 (en) * 2004-09-30 2008-05-13 Siemens Aktiengesellschaft Model based diagnosis and repair for event logs
US7275017B2 (en) 2004-10-13 2007-09-25 Cisco Technology, Inc. Method and apparatus for generating diagnoses of network problems
US7954090B1 (en) * 2004-12-21 2011-05-31 Zenprise, Inc. Systems and methods for detecting behavioral features of software application deployments for automated deployment management
DE112005003530T5 (de) * 2005-04-08 2008-03-27 Hewlett-Packard Development Company, L.P., Houston Fehlercodesystem
US7426654B2 (en) * 2005-04-14 2008-09-16 Verizon Business Global Llc Method and system for providing customer controlled notifications in a managed network services system
US7571150B2 (en) * 2005-04-15 2009-08-04 Microsoft Corporation Requesting, obtaining, and processing operational event feedback from customer data centers
JP4672722B2 (ja) * 2005-04-25 2011-04-20 富士通株式会社 ネットワーク設計処理装置，方法およびそのプログラム
US7949904B2 (en) * 2005-05-04 2011-05-24 Microsoft Corporation System and method for hardware error reporting and recovery
US8392236B2 (en) * 2005-05-13 2013-03-05 The Boeing Company Mobile network dynamic workflow exception handling system
JP4701148B2 (ja) * 2006-03-02 2011-06-15 アラクサラネットワークス株式会社 障害回復システム及びサーバ
US8326969B1 (en) * 2006-06-28 2012-12-04 Emc Corporation Method and apparatus for providing scalability in resource management and analysis system- three way split architecture
US8284675B2 (en) * 2006-06-28 2012-10-09 Rockstar Bidco, L.P. Method and system for automated call troubleshooting and resolution
JP4859558B2 (ja) * 2006-06-30 2012-01-25 株式会社日立製作所 コンピュータシステムの制御方法及びコンピュータシステム
US7924733B2 (en) * 2006-09-28 2011-04-12 Avaya Inc. Root cause analysis of network performance based on exculpation or inculpation sets
JP2008084242A (ja) * 2006-09-29 2008-04-10 Omron Corp データベース作成装置およびデータベース活用支援装置
US7872982B2 (en) * 2006-10-02 2011-01-18 International Business Machines Corporation Implementing an error log analysis model to facilitate faster problem isolation and repair
US20080140817A1 (en) * 2006-12-06 2008-06-12 Agarwal Manoj K System and method for performance problem localization
US7757117B2 (en) * 2007-04-17 2010-07-13 International Business Machines Corporation Method and apparatus for testing of enterprise systems
US8421614B2 (en) * 2007-09-19 2013-04-16 International Business Machines Corporation Reliable redundant data communication through alternating current power distribution system
US7941707B2 (en) * 2007-10-19 2011-05-10 Oracle International Corporation Gathering information for use in diagnostic data dumping upon failure occurrence
US7788534B2 (en) * 2007-12-11 2010-08-31 International Business Machines Corporation Method for monitoring and managing a client device in a distributed autonomic computing environment
US8826077B2 (en) * 2007-12-28 2014-09-02 International Business Machines Corporation Defining a computer recovery process that matches the scope of outage including determining a root cause and performing escalated recovery operations
US8341014B2 (en) * 2007-12-28 2012-12-25 International Business Machines Corporation Recovery segments for computer business applications
US20090172674A1 (en) * 2007-12-28 2009-07-02 International Business Machines Corporation Managing the computer collection of information in an information technology environment
US20090210745A1 (en) * 2008-02-14 2009-08-20 Becker Sherilyn M Runtime Error Correlation Learning and Guided Automatic Recovery
US7835307B2 (en) * 2008-03-14 2010-11-16 International Business Machines Corporation Network discovery tool
US7870441B2 (en) * 2008-03-18 2011-01-11 International Business Machines Corporation Determining an underlying cause for errors detected in a data processing system
US8086905B2 (en) * 2008-05-27 2011-12-27 Hitachi, Ltd. Method of collecting information in system network
US7814369B2 (en) * 2008-06-12 2010-10-12 Honeywell International Inc. System and method for detecting combinations of perfomance indicators associated with a root cause
US8112378B2 (en) * 2008-06-17 2012-02-07 Hitachi, Ltd. Methods and systems for performing root cause analysis
US20110125544A1 (en) * 2008-07-08 2011-05-26 Technion-Research & Development Foundation Ltd Decision support system for project managers and associated method
US8310931B2 (en) * 2008-07-18 2012-11-13 International Business Machines Corporation Discovering network topology from routing information
US8370466B2 (en) * 2008-07-23 2013-02-05 International Business Machines Corporation Method and system for providing operator guidance in network and systems management
US7877636B2 (en) * 2008-08-28 2011-01-25 Honeywell International Inc. System and method for detecting temporal relationships uniquely associated with an underlying root cause
US7962472B2 (en) * 2008-09-29 2011-06-14 International Business Machines Corporation Self-optimizing algorithm for real-time problem resolution using historical data
JP5237034B2 (ja) * 2008-09-30 2013-07-17 株式会社日立製作所 イベント情報取得外のｉｔ装置を対象とする根本原因解析方法、装置、プログラム。
US8166351B2 (en) * 2008-10-21 2012-04-24 At&T Intellectual Property I, L.P. Filtering redundant events based on a statistical correlation between events
US7877642B2 (en) * 2008-10-22 2011-01-25 International Business Machines Corporation Automatic software fault diagnosis by exploiting application signatures
US7954010B2 (en) * 2008-12-12 2011-05-31 At&T Intellectual Property I, L.P. Methods and apparatus to detect an error condition in a communication network
US8055945B2 (en) * 2009-02-02 2011-11-08 International Business Machines Corporation Systems, methods and computer program products for remote error resolution reporting
US7979747B2 (en) * 2009-02-20 2011-07-12 International Business Machines Corporation Interactive problem resolution presented within the context of major observable application behaviors
WO2010112960A1 (en) 2009-03-30 2010-10-07 Hitachi, Ltd. Method and apparatus for cause analysis involving configuration changes
US8527328B2 (en) * 2009-04-22 2013-09-03 Bank Of America Corporation Operational reliability index for the knowledge management system
JP5325981B2 (ja) * 2009-05-26 2013-10-23 株式会社日立製作所 管理サーバ及び管理システム
EP2455863A4 (en) * 2009-07-16 2013-03-27 Hitachi Ltd MANAGEMENT SYSTEM FOR PROVIDING INFORMATION DESCRIBING A RECOVERY METHOD CORRESPONDING TO A FUNDAMENTAL CAUSE OF FAILURE

Patent Citations (6)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2004061681A1 (ja) * 2002-12-26 2004-07-22 Fujitsu Limited 運用管理方法および運用管理サーバ
JP2006526842A (ja) 2003-03-31 2006-11-24 システム マネージメント アーツ，インク． 兆候除外付きコードブック相関を使用するシステム管理のための方法および装置
US7478404B1 (en) 2004-03-30 2009-01-13 Emc Corporation System and methods for event impact analysis
JP2006338305A (ja) * 2005-06-01 2006-12-14 Toshiba Corp 監視装置及び監視プログラム
JP2009043029A (ja) 2007-08-09 2009-02-26 Hitachi Ltd 関連ｄｂ作成装置
JP2009064101A (ja) * 2007-09-04 2009-03-26 Toshiba Corp 遠隔監視システム及び遠隔監視方法

Non-Patent Citations (2)

* Cited by examiner, † Cited by third party
Title
COMMUNICATIONS OF THE ACM, September 1985 (1985-09-01), pages 921 - 932
See also references of EP2455863A4 *

Cited By (12)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2012174232A (ja) * 2011-02-24 2012-09-10 Fujitsu Ltd 監視装置、監視システムおよび監視方法
US8996924B2 (en) 2011-02-24 2015-03-31 Fujitsu Limited Monitoring device, monitoring system and monitoring method
EP2674865A4 (en) * 2011-09-26 2016-06-01 Hitachi Ltd ADMINISTRATIVE COMPUTERS AND METHODS OF BASIC ANALYSIS
JP5719974B2 (ja) * 2012-09-03 2015-05-20 株式会社日立製作所 複数の監視対象デバイスを有する計算機システムの管理を行う管理システム
JPWO2014068659A1 (ja) * 2012-10-30 2016-09-08 株式会社日立製作所 管理計算機およびルール生成方法
WO2014141460A1 (ja) * 2013-03-15 2014-09-18 株式会社日立製作所 管理システム
JP5946583B2 (ja) * 2013-03-15 2016-07-06 株式会社日立製作所 管理システム
US9628360B2 (en) 2013-03-15 2017-04-18 Hitachi, Ltd. Computer management system based on meta-rules
WO2014162595A1 (ja) 2013-04-05 2014-10-09 株式会社日立製作所 管理システム及び管理プログラム
US9619314B2 (en) 2013-04-05 2017-04-11 Hitachi, Ltd. Management system and management program
JPWO2015079564A1 (ja) * 2013-11-29 2017-03-16 株式会社日立製作所 イベントの根本原因の解析を支援する管理システム及び方法
JP2015156225A (ja) * 2015-03-23 2015-08-27 株式会社日立製作所 複数の監視対象デバイスを有する計算機システムの管理を行う管理システム

Also Published As

Publication number Publication date
US9189319B2 (en) 2015-11-17
JP5385982B2 (ja) 2014-01-08
US20130219225A1 (en) 2013-08-22
JPWO2011007394A1 (ja) 2012-12-20
CN102473129A (zh) 2012-05-23
US20110264956A1 (en) 2011-10-27
CN102473129B (zh) 2015-12-02
EP2455863A1 (en) 2012-05-23
EP2455863A4 (en) 2013-03-27
US8429453B2 (en) 2013-04-23

Similar Documents

Publication Publication Date Title
JP5385982B2 (ja) 障害の根本原因に対応した復旧方法を表す情報を出力する管理システム
US11614990B2 (en) Automatic correlation of dynamic system events within computing devices
US10467084B2 (en) Knowledge-based system for diagnosing errors in the execution of an operation
US8782039B2 (en) Generating a semantic graph relating information assets using feedback re-enforced search and navigation
US7536370B2 (en) Inferential diagnosing engines for grid-based computing systems
US9071535B2 (en) Comparing node states to detect anomalies
US8892705B2 (en) Information processing system, operation management method for computer systems, and program in a distributed network environment
WO2015079564A1 (ja) イベントの根本原因の解析を支援する管理システム及び方法
US8751856B2 (en) Determining recovery time for interdependent resources in heterogeneous computing environment
US20120030346A1 (en) Method for inferring extent of impact of configuration change event on system failure
US20120221898A1 (en) System and method for determination of the root cause of an overall failure of a business application service
US20120284262A1 (en) Managing information assets using feedback re-enforced search and navigation
US20120221558A1 (en) Identifying information assets within an enterprise using a semantic graph created using feedback re-enforced search and navigation
JP2011076292A (ja) 取得可能な機器情報に応じた障害原因解析ルールの設計方法及び計算機
JP2014199579A (ja) 検出方法、検出プログラム、および検出装置
JP6988304B2 (ja) 運用管理システム、監視サーバ、方法およびプログラム
US20150032776A1 (en) Cross-cutting event correlation
WO2006117833A1 (ja) 監視シミュレーション装置，方法およびそのプログラム
US20200073781A1 (en) Systems and methods of injecting fault tree analysis data into distributed tracing visualizations
JP5514643B2 (ja) 障害原因判定ルール変化検知装置及びプログラム
JP6280862B2 (ja) イベント分析システムおよび方法
WO2014068705A1 (ja) 監視システム及び監視プログラム
US20150242416A1 (en) Management computer and rule generation method
US20230325294A1 (en) Models for detecting and managing excessive log patterns
Kobayashi et al. amulog: A general log analysis framework for comparison and combination of diverse template generation methods

Legal Events

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

Ref document number: 200980160965.4

Country of ref document: CN

WWE Wipo information: entry into national phase

Ref document number: 12529522

Country of ref document: US

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

Ref document number: 09847293

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2011522628

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

WWE Wipo information: entry into national phase

Ref document number: 2009847293

Country of ref document: EP