WO2015177840A1 - 監視方法、監視装置及び記憶媒体 - Google Patents

監視方法、監視装置及び記憶媒体 Download PDF

Info

Publication number
WO2015177840A1
WO2015177840A1 PCT/JP2014/063239 JP2014063239W WO2015177840A1 WO 2015177840 A1 WO2015177840 A1 WO 2015177840A1 JP 2014063239 W JP2014063239 W JP 2014063239W WO 2015177840 A1 WO2015177840 A1 WO 2015177840A1
Authority
WO
WIPO (PCT)
Prior art keywords
model
monitoring
application
index
information
Prior art date
Application number
PCT/JP2014/063239
Other languages
English (en)
French (fr)
Inventor
健太郎 角井
英男 高橋
高弘 野澤
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to PCT/JP2014/063239 priority Critical patent/WO2015177840A1/ja
Publication of WO2015177840A1 publication Critical patent/WO2015177840A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment

Definitions

  • the present invention relates to a monitoring method, a monitoring apparatus, and a storage medium, and more particularly to a monitoring apparatus that monitors the operating status of a monitored system, detects a sign of a failure in the system by probabilistic inference, and notifies the inference result. It is suitable for application.
  • SLA Service Level Agreement
  • SLO Service Level Objective
  • Patent Document 1 discloses a hybrid prediction system that can predict the occurrence of an important event in a computer cluster by inputting information such as an event log and a system parameter log into a prediction model.
  • a failure sign is detected using a Bayesian network which is a kind of probability model.
  • Prediction using Bayesian networks is generally called probabilistic reasoning. This is an operation for obtaining a peripheral posterior probability of a random variable from an acyclic directed graph that expresses a dependency relationship between a plurality of random variables and a conditional probability table.
  • the Bayesian network and the probability inference are disclosed in Non-Patent Document 1, for example.
  • Non-Patent Document 1 the calculation of probability inference is known as an NP difficulty problem (see Non-Patent Document 1), and the amount of calculation generally increases exponentially with respect to the number of nodes included in the Bayesian network.
  • a large number of monitoring points can be set in information processing systems that have become more sophisticated and complex in recent years.
  • monitoring data collected from them is modeled by a Bayesian network, it is inevitably a large-scale configuration composed of a large number of nodes. It is assumed to be a model. In order to detect a failure sign using such a model, some countermeasure must be taken against an increase in the amount of calculation.
  • failure sign detection is provided as a service, it is possible to secure a time delay for performing computations by performing probability inference batchwise at regular intervals and presenting the results. it can.
  • such an advanced information processing system has a plurality of logically separate application programs deployed over a unit of a physically independent computing resource such as a server, and these are resources such as a database management server. May be shared. Each individual operation manager will be responsible for operation management for each of the plurality of application programs.
  • the operation manager who is the user of the failure sign detection service arbitrarily sets the preconditions for failure sign detection within the range of each interest However, it is conceivable to obtain a prediction result based on the condition. In such an aspect in which probability inference is executed interactively, there is no time delay as in batch execution.
  • the probability inference is accelerated. is required.
  • the method must also be achieved by reducing the number of nodes in the Bayesian network that performs probabilistic reasoning. This is because stochastic reasoning is NP-hard for both exact and approximate solutions.
  • the present invention has been made in consideration of the above points, and intends to propose a monitoring method, a monitoring apparatus, and a storage medium that can quickly provide the processing result of the failure sign detection processing.
  • a monitoring method that is executed in a monitoring device that monitors the operating status of a monitoring target system including one or a plurality of computers and detects a sign of a failure occurrence in the monitoring target system.
  • the monitoring device includes a storage device that stores information necessary for various processes, and a processing unit that performs processing with reference to the information stored in the storage device, and the processing unit includes: A first step of acquiring measurement values for a plurality of indicators including a reference indicator and a target indicator in the monitored system; and the processing unit is configured to determine future values of the reference indicator based on the measurement values of the plurality of indicators.
  • information necessary for various processes is stored in a monitoring device that monitors the operating status of a monitoring target system including one or a plurality of computers and detects a sign of failure occurrence in the monitoring target system.
  • a storage device and a processing unit that executes processing with reference to the information stored in the storage device, and the processing unit includes a plurality of indicators including a reference indicator and a target indicator in the monitoring target system.
  • a data acquisition unit that acquires the measurement value of the first, a prediction unit that predicts a prediction value that is a future value of the reference index based on the measurement values of the plurality of indicators, and a system model of the monitoring target system
  • the model generation unit that generates a submodel that is a part of the system model, the predicted value of the reference index, and the generated submodel Measured value of said target indicia is acceptable to provide a probability inference unit for inferring a probability of a range of a predetermined value or a predetermined value.
  • the monitoring program monitors the operating status of the monitoring target system composed of one or a plurality of computers, and detects a sign of failure occurrence in the monitoring target system.
  • a second step of predicting a predicted value consisting of a value, a system model of the monitored system and a submodel which is a part of the system model are generated, and based on the predicted value of the reference index and the generated submodel And inferring a probability that the measured value of the target index is a predetermined value or a range of the predetermined value, And so as to execute the obtaining process.
  • the calculation amount of the target index is much smaller than that inferring the probability that the measurement value of the target index is a predetermined value or a range of the predetermined value using the system model. Such inference can be made.
  • the processing result of the failure sign detection processing can be quickly provided.
  • FIG. 1 shows a configuration example of an information processing device.
  • the information processing apparatus 1 includes, for example, a rack mount server, a blade server, or a personal computer, and includes a processor 2, a memory 3, a storage 4, a network interface 5, and a console 6.
  • the processor 2 is connected to the memory 3, the storage 4, the network interface 5 and the console 6.
  • the processor 2 is hardware such as a CPU (Central Processing Unit).
  • the memory 3 is composed of, for example, a volatile semiconductor memory, and is used for temporarily storing programs and data.
  • the storage 4 is composed of, for example, a hard disk drive (HDD: Hard Disk Drive), a solid state drive (SSD: Solid State Drive), or a storage device in which a plurality of these are combined, in order to retain programs and data for a long period of time. Used.
  • An operating system (OS: Operating System) 7 and a user process 8 stored in the storage 4 are read out to the memory 3 when the information processing apparatus 1 is started up or executed, and the operating system 7 and the information read out to the memory 3 are read out.
  • OS Operating System
  • various processes as described below are performed as the information processing apparatus 1 as a whole.
  • the network interface 5 is composed of, for example, a NIC (Network Interface Card) or the like, and is connected to the network 10 via the network switch 9.
  • the network interface 5 performs protocol control when communicating with other information processing apparatuses via the network 10.
  • the network 10 for example, a wireless network based on Ethernet (registered trademark), IEEE (Institute of Electrical and Electronics Electronics) 802.11 standard, a wide area network based on SDH / SONET (Synchronous Optical Network / Synchronous Digital Hierarchy) standard, Alternatively, a network in which these plurality of network technologies are combined can be applied.
  • the console 6 includes an input device such as a keyboard and a mouse, and a display device such as a liquid crystal panel.
  • the console 6 receives operation signals according to various operation inputs given from the input device and notifies the processor 2 of the operation input contents. Or text or images based on text information or graphical information given from the processor 2 is displayed on the display device.
  • the information processing apparatus 1 may include a plurality of some or all of the processor 2, the memory 3, the storage 4, the network interface 5, and the console 6. Further, the relationship between the information processing apparatus 1 and the operating system 7 is not limited to one-to-one, and one information processing apparatus 1 may be equipped with a plurality of operating systems 7 based on the virtualization technology.
  • FIG. 2 shows a schematic configuration of the information processing system 20 according to this embodiment.
  • the information processing system 20 is provided in a customer side system 22 provided in the customer site 21 and a service site 23 of a service provider that provides a system monitoring service for monitoring the customer side system 22.
  • the service provider side system 24 Each of the customer side system 22 and the service provider side system 24 includes one or more information processing apparatuses 1 described above with reference to FIG. 1, and these information processing apparatuses 1 are mutually connected via the network 10 and one or more network switches 9. It is connected to the.
  • the customer site 21 and the service site 23 are typically located in geographically remote locations and are connected by a wide area network, but other aspects such as the customer site 21 and the service site 23 exist in the same data center. However, they may be connected by a network in the data center.
  • the information processing device 1 existing in the customer site 21 and the information processing device 1 existing in the service site 23 can communicate with each other via a network connecting the customer site 21 and the service site 23. it can.
  • Such communication between the customer site 21 and the service site 23 may be limited by the setting of a network router or a firewall device for the purpose of maintaining information security, but the communication required in the present embodiment Is set to be possible.
  • the customer-side system 22 includes one or more business servers 30 each including the information processing apparatus 1 described above with reference to FIG. 1, a log collection device 31, a monitoring control client 32, and one or more business clients 33. .
  • the business server 30 is provided with an application program 34 as the user process 8 (FIG. 1), and the processor 2 (FIG. 1) executes the process according to the request from the business client 33.
  • the log collection device 31 receives information representing the operational status of the business server 30 from each business server 30 such as a measured value such as a CPU operation rate, memory consumption, the number of simultaneously connected users, and an average response time (hereinafter referred to as system statistics). (Referred to as information) 35 is periodically collected. This processing is performed by the processor 2 (FIG. 1) executing the program stored in the storage 4 (FIG. 1) of the log collection device 31.
  • the target for collecting the system statistical information 35 is typically the business server 30, but is not limited to this, and other information processing apparatuses 1, business clients 33, or the network switch 9 (FIG. 1), etc. are involved. Can be included in the subject.
  • a Web browser 36 is installed as the user process 8.
  • the Web browser 36 receives information (in this case) from the console 6 (FIG. 1) with respect to the portal server 42 of the service provider side system 24 to be described later when receiving an instruction from the person in charge of operation management of the customer side system 22. (Presentation result of failure prediction detection process) is requested, and information transmitted from the portal server 42 in response to this request is displayed on the console 6.
  • the web browser 36 may be configured to request the portal server 42 to present information at an arbitrary interval determined in advance.
  • the method of presenting information to the person in charge of operation management of the customer-side system 22 Any means suitable for the person in charge of operation management, such as sending an e-mail, can be adopted.
  • a business client program 37 corresponding to the business content of the customer is installed as the user process 8.
  • the business client program 37 executes necessary processing while communicating with the application program 34 executed on the business server 30.
  • a method of configuring an application program so as to achieve a specific business purpose by mutual communication between such programs is called a client-server method, and is typically known to those skilled in the art in the form of a Web application. It is.
  • the business client 33 may exist away from the customer site 21. Such business clients 33 communicate with the business server 30 via the network 10 (FIG. 1) to which the business clients 33 are connected.
  • the service provider side system 24 provides a system monitoring service that monitors the operating status of the customer side system 22, detects a sign of a failure in the customer side system 22 by probabilistic inference, and notifies the inference result.
  • the system includes a storage server 40, a sign server 41, and a portal server 42, each of which includes the information processing apparatus 1 described above with reference to FIG.
  • the accumulation server 40 periodically receives the system statistical information 35 of each business server 30 collected by the log collection device 31, and accumulates the received system statistical information 35.
  • the communication for receiving the system statistical information 35 may be selected from either the method in which the log collection device 31 starts the communication that triggers the communication or the method in which the storage server 40 starts the communication that triggers the communication. good.
  • the predictive server 41 receives the system statistical information 35 stored by the storage server 40, monitors the operating status of the customer side system 22 based on the received system statistical information 35, and predicts that a failure will occur in the customer side system 22. Is detected by probabilistic inference (hereinafter referred to as failure sign detection processing).
  • the portal server 42 stores the system statistical information 35 accumulated in the accumulation server 40 and the processing result of the failure sign detection process performed by the sign server 41 on the monitoring control client 32 (more precisely, the monitoring control client 32 of the customer side system 22).
  • the monitoring control client 32 is notified in response to a request from the Web browser 36) operating above.
  • the log collection device 31 and the monitoring control client 32 of the customer-side system 22 and the storage server 40, the predictive server 41, and the portal server 42 of the service provider-side system 24 are partly or entirely distributed in processing load and improved in availability.
  • a plurality of units may be provided, or a single information processing apparatus 1 may be used for the roles of a plurality of types of servers described above.
  • FIG. 2 is an example of many combinations thereof.
  • the customer side system 22 is not installed at the customer site 21. It is possible to detect a failure sign.
  • the storage server 40, the sign server 41 and the portal server 42 require hardware resources such as a large-capacity storage and a high-speed processor for the purpose of storing and processing data. This has the effect of eliminating the need for hardware.
  • FIG. 2 illustrates the case where there is one customer side system 22 and one service provider side system 24.
  • an individual service provider side system 24 is prepared for each customer side system 22. It does not mean what should be done.
  • One service provider side system 24 can also detect failure signs of a plurality of customer side systems 22.
  • the service provider side system 24 is provided for a system monitoring service for a plurality of customer side systems 22.
  • the accumulation server 40 accumulates system statistical information 35 transmitted from each log collection device 31 of the plurality of customer-side systems 22, and the portal server 42 transmits each monitoring control client 32 of the plurality of customer-side systems 22.
  • the sign server 41 detects a sign of a failure in each customer-side system 22 based on the system statistical information 35 collected from a plurality of customer-side systems 22.
  • FIG. 3 shows a configuration example of the monitoring target system 50 in the customer side system 22 that is to be monitored by the service provider side system 24.
  • the monitoring target in the system monitoring service is often the business server 30 in the customer side system 22 as a unit, but is not limited thereto.
  • the business server 30 implements the application program 34 (FIG. 2) as the user process 8 (FIG. 1).
  • Such an application program 34 is not always executed by the business server 30 alone. Rather, a plurality of business servers 30 are installed with programs such as application programs 34 having different roles and middleware that supports the execution thereof. It is the normal customer-side system 22 aspect that is being implemented to achieve the objective.
  • a function in which a large number of programs distributed and implemented in a plurality of information processing apparatuses operate in cooperation (hereinafter, a function realized by an application program is called an application) is called a distributed application, and such a system is distributed. Called a processing system.
  • a group of devices related to the execution of the distributed application is referred to as a monitoring target system 50.
  • the monitoring target system 50 constitutes a unit for demarcating and distinguishing the device groups constituting the customer side system 22.
  • the business server 30 implements the application program 34 as the user process 8.
  • the business client 33 implements a business client program 37 as the user process 8.
  • the business server 30 implements the application program 34, but there may be a plurality of application programs 34 having different functions and business purposes. Further, the business server 30 may be provided with middleware 51 such as a database management system (DBMS).
  • middleware 51 such as a database management system (DBMS).
  • a certain application 52 includes a business server 30 “AP1” and a business server 30 “DB1”, and another application 52B. Shows a state in which the business server 30 called “AP2” and the business server 30 called “DB1” are set to achieve their business purposes while communicating with each other.
  • the other application 52C achieves the business purpose while the business server 30 “AP3” and the business server 30 “DB2” that do not overlap with both the application 52A and the application 52B communicate with each other.
  • the monitoring target system 50 may include a plurality of applications 52 (52A to 52C). Such a plurality of applications 52 may share the same business server 30.
  • the operation status of the entire customer-side system 22 or the entire application 52 to be monitored is not limited to grasping the individual operation status of the information processing apparatus 1 existing in the customer site 21. Need to figure out.
  • FIG. 4 shows a logical configuration of the predictive server 41 of the service provider side system 24.
  • the sign server 41 is provided with a sign engine 60 as the user process 8.
  • the sign engine 60 reads a sign engine program (not shown) stored in the storage 4 (FIG. 1) into the memory 3 (FIG. 1), and the processor 2 (FIG. 1) executes the read sign engine program. Embodied.
  • the sign engine 60 includes a data acquisition unit 61, a data storage unit 62, a model generation unit 63, a prediction unit 64, and an inference unit 65.
  • the memory 3 (FIG. 1) of the sign server 41 stores a system profile 66, a system model repository 67, a prediction profile 68, and a prediction model repository 69. These pieces of information may be stored in the storage 4 (FIG. 1) instead of the memory 3, or may be stored in another server and acquired by communication as necessary.
  • the data acquisition unit 61, the data storage unit 62, the model generation unit 63, the prediction unit 64, and the inference unit 65 of the sign engine 60 will be described.
  • These entities may be program functions, program modules, libraries, class instances, etc., or a combination of these, or other entities.
  • each unit does not have to be clearly distinguished as a program or a user process, and each unit in cooperation with the precursor engine program alone or another program such as an OS. If the process provided by can be done, there is no problem.
  • the data acquisition unit 61 of the sign engine 60 requests the storage server 40 to transmit the system statistical information 35, receives the system statistical information 35 transmitted from the storage server 40 in response to the request, and receives the data statistical unit 62. Further, the model generation unit 63 generates and generates a system model of the monitoring target system 50 based on the system statistical information 35 stored in the data storage unit 62 and the predicted value given from the prediction unit 64 as described later. The system model is stored in the system model repository 67.
  • the prediction unit 64 performs a time series prediction process described later based on the system statistical information 35 stored in the data storage unit 62, the information stored in the prediction profile 68, and the information stored in the prediction model repository 69. Then, the prediction value obtained by the time series prediction process is notified to the inference unit 65 and the model generation unit 63.
  • the inference unit 65 executes probability inference processing based on the received prediction value, the system model stored in the system model repository 67, and information stored in the prediction profile 68, and the obtained probability value or probability distribution Is transmitted to the portal server 42. A series of processes beyond those executed by the prediction unit 64 and the inference unit 65 are the failure sign detection process.
  • the predictor engine 60 transmits the probability value or probability distribution to the portal server 42, it is not always necessary to synchronize with the failure predictor detection process, and the probability value or probability distribution obtained by the probability inference process is stored in the memory 3 (FIG. 1) or in the storage 4 (FIG. 1), and may be transmitted to the portal server 42 in response to a presentation request for information from the portal server 42.
  • the configuration of the system profile 66 and the system model repository 67 which is the core of the failure sign detection process executed by the sign server 41, and the model generation unit 63, the prediction unit 64, and the inference unit 65 of the sign engine 60 are executed. Each process will be specifically described.
  • the system profile 66 includes at least a system profile table 70 shown in FIG.
  • the system profile table 70 is a table used by the sign engine 60 (FIG. 4) to manage the monitoring target system 50 described above with reference to FIG. 3, and as shown in FIG. 5, a system ID field 70A and a system name field 70B. And an arbitrary number of measurement value fields 70C.
  • One record (row) in the system profile table 70 corresponds to one monitoring target system 50.
  • system ID field 70A an identifier (system ID) unique to the monitoring target system 50 assigned to the monitoring target system 50 is stored, and in the system name field 70B, the corresponding monitoring target system 50 is stored in the customer side system.
  • the name (system name) of the monitoring target system 50 assigned so that the 22 person in charge of operation management can be specified is stored.
  • Each measurement value field 70C stores the name of each measurement value included in the system statistical information 35 collected by the log collection device 31 from each business server 30 constituting the corresponding monitoring target system 50. Therefore, the number of measurement value fields 70C to be used varies depending on the record (monitored system 50).
  • the measurement value names (“AP1.cpu”, “DB2.mem”,...), The business server 30 names (“AP1”, “AP2”, etc, And the measurement value type. (“Cpu”, “mem”,%) are generated and assigned based on the above, but a naming method that can ensure uniqueness so as not to hinder the smooth execution of each process executed in the predictive server 41 If so, the method of assigning the name of the measurement value is not limited to this.
  • the performance index of the distributed application related to the execution of the monitoring target system 50 is also stored in the measurement value field 70C.
  • this performance index is indicated by numerical values such as the number of simultaneously connected users per unit time (“CU1”, “CU2”, etc. And the average response time (“ART3”, etc. It is an indicator.
  • these performance indicators are given names that can be distinguished from each other.
  • the system profile table 70 is typically stored in the memory 3 (FIG. 1) of the predictive server 41, but may be stored in the storage 4 (FIG. 1) or stored in another server. If necessary, the sign server 41 may acquire it from the server by communication.
  • a table format is adopted as a management format of data to be stored in the system profile table 70.
  • other formats such as a key / value format and a document-oriented database are used.
  • a data management format may be adopted.
  • each record of the system profile table 70 is created using information input by a person in charge of operation management of the customer side system 22, for example.
  • FIG. 6 shows an example of a system model based on a Bayesian network stored in the system model repository 67 (FIG. 4).
  • the system model regards the measured value or performance index related to the monitoring target system 50 recorded in the system profile table 70 as time series data of the measured value or performance index as a random variable, and the mutual relationship between them. It is a probabilistic model to describe.
  • a Bayesian network is used as such a model.
  • the Bayesian network is composed of an acyclic directed graph having a plurality of random variables as nodes, and a conditional probability table or conditional probability density function of each variable based on the dependency relationship between the nodes represented by the graph.
  • FIG. 6 shows the number of users (CU: Concurrent Users) and average response time (ART: Average ⁇ Response Time) of an application 52 (FIG. 3) and the business server 30 (FIG. 3) involved in the execution of the application 52.
  • CPU utilization rate (AP.cpu) and memory consumption (AP.mem) of the business server 30 functioning as an application server, and a database of the business server 30 (FIG. 3) involved in the execution of the application 52 This is an example in which six items of the CPU usage rate (DB.cpu) and the memory consumption (DB.mem) of the business server 30 functioning as a server are modeled into a Bayesian network having nodes 71A to 71F, respectively.
  • the eye of the system model 71 by this Bayesian network is to express the dependency relationship between the number of simultaneously connected users CU and the average response time ART, and the number of simultaneously connected users CU is referred to as a reference index, and the average response time ART is referred to as a target index.
  • the target index refers to a node for which a posterior probability distribution is obtained in the Bayesian network probability inference.
  • a typical process of probability inference in this embodiment is to set a certain value as evidence for the number of simultaneously connected users CU, which is the reference index of the system model 71, and estimate the posterior probability distribution of the target index.
  • time series prediction is a technology that builds a model from data (time series data) obtained by observing changes in a variable over time, and predicts future values of variables based on the built model. is there.
  • a model construction method applied to such a technique for example, linear single regression, exponential smoothing method, ARIMA model and the like are known.
  • Bayesian network model can be constructed by statistical learning.
  • it uses structure learning to determine the structure of an acyclic directed graph using observation values of each random variable, and parameter learning to generate a conditional probability table or conditional probability density function parameter for each node in the graph. Call it.
  • FIG. 7 shows an example in which the monitoring target system 50 including the two applications 52A and 52B shown in FIG. 3 is modeled as a Bayesian network model.
  • the system model 72 shown in FIG. 7 includes nodes 72A and 72B corresponding to the number of simultaneously connected users (CU1) and average response time (ART1) of an application 52A called “application # 01”, and an application 52B called “application # 02”.
  • Nodes 72C and 72D respectively corresponding to the number of simultaneously connected users (CU2) and the average response time (ART2).
  • the two applications 52A and 52B are executed on separate business servers 30. That is, the application 52A “application # 01” is executed by the business server 30 “AP1”, and the application 52B “application # 02” is executed by the business server 30 “AP2”. On the other hand, these two applications 52A and 52B share a business server 30 called “DB1” that functions as a database server.
  • DB1 business server 30
  • the system model 72 has a measured value related to the application 52A called “application # 01”, and the CPU usage rate (AP1.cpu) and memory consumption (AP1.mem) of the business server 30 called “AP1”.
  • nodes 72I and 72J respectively corresponding to the CPU usage rate (DB1.cpu) and the memory consumption (DB1.mem) of the business server 30 called “DB1” are included.
  • Information necessary for classifying the nodes 72A to 72J included in the system model 72 (Bayesian network) with the applications 52A and 52B as units is an application profile that constitutes a system profile 66.
  • the application profiles 73 to 75 are a kind of system configuration information, and are tables that store the correspondence between the application 52 and the business server 30.
  • the application profile shown in FIG. 8 is called an application business server correspondence table 73
  • the application profile shown in FIG. 9 is called an application index table 74
  • the application profile shown in FIG. 10 is called an application node table 75. .
  • the application business server correspondence table 73 is a table used for the sign engine 60 (FIG. 4) to manage the correspondence between the application 52 and the business server 30 involved in the execution of the application 52, and is shown in FIG. As described above, it is composed of an ID field 73A, an application name field 73B, and a business server name field 73C.
  • the ID field 73A stores an identifier (application ID) unique to each application 52 assigned to the application 52 in the monitoring target system 50, and the application name field 73B assigns the corresponding application 52.
  • the name (application name) of the application 52 is stored.
  • the business server name field 73C is divided into a plurality of individual business server name fields 73CA provided corresponding to each business server 30 in the monitoring target system 50, and corresponds to each individual business server name field 73CA.
  • Information indicating whether to use the corresponding business server 30 in the application 52 (“Y” when used, “N” when not used) is stored.
  • each record of the application business server correspondence table 73 is created using information input by a person in charge of operation management of the customer side system 22, for example.
  • the application index table 74 is a table used by the predictive engine 60 (FIG. 4) to manage the performance index (here, the reference index and the target index) of each application 52. As shown in FIG. 74A, an application name field 74B, a reference index field 74C, and a target index field 74D.
  • the ID field 74A and the application name field 74B store the same information as the information stored in the ID field 73A and the application name field 73B of the application business server correspondence table 73, respectively.
  • the reference index field 74C stores the reference index for the corresponding application 52
  • the target index field 74D stores the target index for the corresponding application 52.
  • the application node table 75 is a table used by the predictive engine 60 (FIG. 4) to manage the matching result. As shown in FIG. 10, an ID field 75A, an application name field 75B, and a plurality of node fields 75C.
  • Each node field 75C stores the node name of the node involved in the execution of the corresponding application 52.
  • FIG. 11 shows an example in which application boundaries are set in the system model 72.
  • This is based on the application profiles (application business server correspondence table 73, application index table 74, and application node table 75) shown in FIGS. 8 to 10 for the system model including the two applications 52A and 52B shown in FIG. Based on the information, each node is classified according to which application 52 is involved, and the application boundary is set based on the result.
  • This system model 72 includes nodes 72A, 72B, 72E, and 72F that belong only to the application 52A called “application # 01”, nodes 72C, 72D, 72G, and 72H that belong only to the application 52B called “application # 02”, and both applications. Nodes 72I and 72J shared by 52A and 52B are included.
  • Arc a is a node “DB1.mem” (hereinafter referred to as a shared node) 72J shared by two applications 52A and 52B, “application # 01” and “application # 02”, and the node The node 72C called “CU2” which is the parent node of 72J is directly connected.
  • the arc a can be deleted from the evidence set in the node 72C “CU2” by updating the conditional probability table of the node 72J “DB1.mem” which is the direct child node.
  • the arc b first updates the conditional probability table of the node 72G “AP2.cpu” and the node 72H “AP2.mem” in the same manner as the arc a, and then uses the variable elimination algorithm (Non-Patent Document 1).
  • the node 72G “AP2.cpu” and the node 72H “AP2.mem” are deleted from the graph by updating the conditional probability table of the shared node 72I “DB1.cpu”. it can.
  • Arc c is directly connected between shared node 72J “DB1.mem” and node 72D “ART2”, and node 72D “ART2” is node 72J “DB1.mem”. Is a child node of In the case of such a terminal node, unless the evidence is set for the node 72D “ART2”, the probability distribution of the node 72B “ART1” is not affected. Therefore, the arc c can be deleted without performing any operation.
  • the partial graph 76 as shown in FIG. 12 including only the nodes 72A, 72B, 72E, 72F, 72I and 72J related to the application 52A called “application # 01”.
  • the subgraph 76 thus extracted and the conditional probability table corresponding thereto, probability inference can be performed only by the nodes 72A, 72B, 72E, 72F, 72I, 72J related to the application 52A called “application # 01”.
  • the Bayesian network model based on this partial graph 76 is called a sub model.
  • FIG. 13 shows a configuration example of the system model repository 67 (see FIG. 4).
  • the system model repository 67 records the system model generated by the model generation unit 63 of the sign engine 60 as described above.
  • the system model repository 67 has a table structure including an ID field 67A, a model name field 67B, a graph structure field 76C, and a parameter field 67D.
  • the ID field 67A an identifier (system model ID) unique to each system model assigned to each system model is stored.
  • the model name field 67B stores the model name assigned to the corresponding system model. This model name can be given by the person in charge of operation management so that it is easy to distinguish each system model.
  • the graph structure field 67C stores a graph structure generated by structure learning
  • the parameter field 67D stores a conditional probability table or a conditional probability density function parameter generated by parameter learning.
  • the system model includes the graph structure generated by the structure learning and the conditional probability table or the parameter group of the conditional probability density function generated by the parameter learning. Accordingly, the entity of the corresponding system model is stored in the graph structure field 67C and the parameter field 67D.
  • these graph structures and parameters may exist on the memory 3 (FIG. 1) in a form that is not suitable for direct storage in the table.
  • a pointer to each may be stored in the table.
  • the table format is adopted as the structure of the system model repository 67 for easy explanation, but other data structures such as an object database and a graph database are adopted as the structure of the system model repository 67. May be.
  • functions such as a separately prepared content repository and configuration management tool may be used, or simply stored in a file system. In any aspect, it is desirable that the system model graph structure be acquired independently of the parameters.
  • FIG. 14 shows a configuration example of the prediction model repository 69 (FIG. 4).
  • the prediction model repository 69 stores a prediction model (time series prediction model) used in the time series prediction process executed by the prediction unit 64 (FIG. 4).
  • the prediction model repository 69 of the present embodiment has a table structure including at least an ID field 69A, an algorithm field 69B, and a past data period field 69C.
  • the ID field 69A an identifier (prediction model ID) unique to each prediction model assigned to each prediction model is stored.
  • the algorithm field 69B stores the algorithm name of the algorithm used to construct the corresponding prediction model, and the past data period field 69C stores the temporal range of past data used in the time series prediction process.
  • the prediction model repository 69 parameters necessary for the construction of a prediction model (time series prediction model) can be recorded.
  • FIG. The prediction profile 68 stores a definition of a failure sign detection process that the sign engine 60 should execute in a batch. Each record (row) of the prediction profile 68 corresponds to one failure sign detection process.
  • the prediction profile 68 includes at least an ID field 68A, a system name field 68B, a system model ID field 68C, a prediction model ID field 68D, a default lead time field 68E, a reference index field 68F, and a target index field 68G. It has a table structure provided with.
  • the ID field 68A stores an identifier (failure sign detection process ID) assigned to each failure sign detection process, and the system name field 68B corresponds to the corresponding one recorded in the system profile table 70 (FIG. 5). Stores the system name of the monitoring target system 50 (FIG. 3) to be subjected to the failure sign detection process. However, the system ID of the corresponding monitoring target system 50 may be stored in the system name field 68B.
  • system model ID field 68C a system model (created by the model generation unit 63 for the monitoring target system 50 and used in the system model repository 67 (FIG. 13) is stored, and the prediction model ID field 68D stores the prediction model ID of the prediction model used in the time series prediction process of failure sign detection executed for the corresponding monitoring target system 50. Is stored.
  • the default lead time field 68E stores a default lead time value used in the time series prediction process.
  • the predetermined lead time is a value indicating how many seconds later the predicted value obtained by the time series prediction process is set to a value after the last point of the past data. Further, in the reference index field 68F and the target index field 68G, the value of the reference index or the target index used in the probability inference process is stored.
  • Each record of the prediction profile 68 is created using information input by the person in charge of operation management of the customer side system 22, for example.
  • FIG. 16 shows an example of a processing procedure of failure sign detection processing executed in the sign engine 60 (FIG. 4).
  • the failure sign detection processing according to the present embodiment is performed by a procedure of acquiring a future value of a certain performance index (reference index) by time series prediction, and then performing probability inference by a Bayesian network using the value as evidence.
  • the prediction unit 64 (FIG. 4) first obtains the measured value of the reference index stored in the prediction profile 68 from the data storage unit 62 (FIG. 4). (S1) The measured value of the acquired reference index is stored in the memory 3 (FIG. 1) (S2). Then, the prediction unit 64 thereafter performs a time series prediction process for predicting a future value of the reference index in time series according to the prediction model ID and the predetermined lead time recorded in the prediction profile 68 (S3).
  • the inference unit 65 performs probability inference according to the prediction value after the predetermined lead time of the reference index obtained by the time series prediction process, the system model ID and the target index stored in the prediction profile 68 (S4), Thereafter, the inference unit 65 outputs the probability distribution of the target index after the predetermined lead time obtained by the probability inference (S5).
  • the failure sign detection process in the sign engine 60 ends.
  • FIG. 17 shows specific processing contents of the time-series prediction process executed by the prediction unit 64 in step S3 of the failure sign detection process described above with reference to FIG.
  • the prediction unit 64 When the prediction unit 64 proceeds to step S3 of the failure sign detection process, the prediction unit 64 starts the time-series prediction process shown in FIG. 17, first acquires the corresponding prediction model ID recorded in the prediction profile 68, and acquires the acquired prediction. In accordance with the model ID, the corresponding algorithm and parameters necessary for time series prediction processing are read from the prediction model repository 69 (S10).
  • the prediction unit 64 acquires the past data period from the prediction model repository 69 (S11), acquires the measurement value of the reference index for the acquired past data period (S12), and further reads the predetermined read from the prediction profile 68. Time is acquired (S13).
  • the prediction unit 64 executes a time series prediction process using the time series prediction algorithm and parameters, the measured value, and the default lead time obtained as described above (S14). Then, the prediction unit 64 stores the predicted value of the reference index after the predetermined lead time obtained as a result of the time series prediction process in the memory 3 (FIG. 1) (S15), and thereafter ends the time series prediction process. To do.
  • FIG. 18 shows the specific processing contents of the inference unit 65 in step S4 of the failure sign detection processing described above with reference to FIG.
  • the inference unit 65 proceeds to step S4 of the failure sign detection process, the inference unit 65 starts the probability inference process shown in FIG. 18, and first, the reference index after the predetermined lead time stored in the memory 3 (FIG.) As described above. Is obtained (step S20).
  • the inference unit 65 acquires the system model ID of the corresponding system model stored in the prediction profile 68, and acquires the system model to which the acquired system model ID is assigned from the system model repository 67 (S21). .
  • the inference unit 65 acquires a target index from the prediction profile 68 (S22).
  • the inference unit 65 executes a probability distribution estimation process (hereinafter referred to as a probability distribution estimation process) using the predicted value, system model, and target index obtained in steps S20 to S22. Then, the probability distribution of the target index after the predetermined lead time is calculated (S23), and then the probability inference process is terminated.
  • a probability distribution estimation process hereinafter referred to as a probability distribution estimation process
  • FIG. 19 shows a procedure of processing for generating a submodel (hereinafter referred to as submodel generation processing) executed by the predictive engine 60 (FIG. 4).
  • submodel generation processing indicates that the sign server 41 has received an information provision request for the submodel transmitted by the monitoring control client 32 (FIG. 4) via the portal server 42 (FIG. 4). As an opportunity, it is executed by the model generation unit 63 (FIG. 4) of the sign engine 60.
  • the monitoring control client 32 specifies the model name of the system model from which the submodel is extracted and the application name of the application 52 to be extracted in accordance with the operation of the operation manager in charge of the customer side system 22.
  • the provision request is transmitted to the portal server 42 (FIG. 4).
  • the portal server 42 receives this information provision request, the portal server 42 transfers a submodel generation request designating the model name and application name designated in the information provision request to the sign server 41.
  • the model generating unit 63 of the predictive engine 60 of the predictive server 41 starts the submodel generating process shown in FIG. 19 and is first specified in the received submodel generation request.
  • the obtained system model is acquired from the system model repository 67 (FIG. 4) (S30).
  • the model generation unit 63 searches information stored in the application profiles 73 to 75 (FIGS. 8 to 10) based on the application name of the application 52 to be extracted, and relates to the execution of the application 52. Nodes are extracted (S31). At this time, nodes shared with other applications 52 are also extracted (S32).
  • the model generation unit 63 acquires a predicted value as evidence for the reference index of the application 52 other than the extraction target from the prediction unit 64 (S33), and thereafter, based on the information acquired in this manner,
  • the partial graph 76 (FIG. 12) is extracted by deleting unnecessary arcs by the method described above for S11 (S34).
  • model generation unit 63 generates a submodel based on the subgraph 76 extracted as described above, and stores the obtained submodel in the system model repository 67 (FIG. 4) (S35), and then the submodel. The generation process ends.
  • the failure sign detection process described above with reference to FIGS. 16 to 18 is executed.
  • the failure sign detection process in step S21 of the probability inference process described above with reference to FIG. 18, the submodel generated by the above-described submodel generation process is acquired instead of the system model, and the step of the probability inference process is performed.
  • the probability distribution of the target index after the predetermined lead time is calculated by executing the probability distribution estimation process using this submodel.
  • FIG. 20 shows information (failure sign detection processing) transmitted from the portal server 42 (FIG. 2) to the monitoring control client 32 in response to a request from the monitoring control client 32 (FIG. 2).
  • the client screen 80 includes a function menu 81, a service list 82, a reference index area 83, and a network area 84.
  • the function menu 81 includes a plurality of buttons 81A to 81D, and a “graphical monitoring” button 81B is provided as one of these buttons 81A to 81D.
  • the service list 82 typically displays a list of monitored systems 50 (FIG. 3) and applications 52 (FIG. 3) in the customer-side system 22 in a hierarchical structure.
  • An item can be selected by performing a mouse click operation on the item to be selected.
  • the service list 82 when one item is selected in this way, the item is displayed in a state (hereinafter referred to as a selected state) indicating that the item is selected.
  • a selected state As a method for indicating that an item is in a selected state, it is possible to use means such as underlining the item or making the font or background color different from the surroundings.
  • FIG. 20 is a display example when one of the monitoring target systems (“system # 01” in FIG. 20) is selected from each item displayed in the service list 82.
  • the reference index area 83 information on the reference index that is the collection target in the monitoring target system 50 corresponding to the selected item is displayed. Specifically, in the reference index area 83, a lead time display 85, a reference index node 86, and a predicted value display 87 are displayed.
  • the lead time display 85 displays the default lead time stored in the prediction profile 68.
  • the time series prediction process in the failure sign detection process for the corresponding monitoring target system 50 indicates the predicted value after how many seconds. Indicates whether it is obtained and used for probability inference processing.
  • the reference index node 86 represents a reference index in the monitoring target system 50 and is displayed like a node in the network graph diagram.
  • the predicted value display 87 represents the predicted value of the reference index after the predetermined lead time obtained by the time series prediction process, and is displayed so that the correspondence with each of the reference index nodes is clear.
  • a network graph structure that models the monitoring target system 50 as shown in FIG. 11, a target index node 88, a probability value display 89, and a probability distribution display 90 are displayed.
  • the target index node 88 represents a target index included in the corresponding monitoring target system 50 and is displayed like a node in the network graph diagram.
  • the reference index node 86 and the target index node 88 are displayed so as to be connected.
  • the probability distribution display 90 based on the probability distribution of the target index after the predetermined lead time obtained by the probability inference process, a histogram of the probability distribution is displayed so that the correspondence with each of the target indices is clear.
  • the probability distribution may be displayed by an orthogonal coordinate plot or other methods. Further, the probability of occurrence of a certain event can be obtained from the probability distribution and displayed on the probability value display 89. It is desirable that the probability distribution or the display mode of the probability can be arbitrarily changed according to the intention of the operation manager.
  • the reference index area 83 and the network area 84 information is displayed or the display content is updated when any of the monitoring target systems 50 is selected in the service list 82 of the client screen 80.
  • the monitoring control client 32 (FIG. 4) provides system model information for the selected monitoring target system 50.
  • the request is transmitted to the sign server 41 (FIG. 4).
  • the sign engine 60 (FIG. 4) executes failure sign detection processing (FIGS. 16 to 18) for the selected monitoring target system 50 in response to the reception of the information provision request.
  • the processing result of the failure sign detection processing is given to the monitoring control client 32 via the portal server 42, and information based on the processing result of the failure sign detection processing is displayed in the reference index area 83 and the network area 84, or The display content is updated.
  • the information processing system 10 may be configured so that any timing or interval can be set for updating the display contents of the reference index area 83 and the network area 84. Further, it is not necessary to update the display content of the client screen 80 in synchronization with the entire screen, and it may be partially updated as appropriate.
  • FIG. 21 shows a display example when one of the applications 52 (“application # 01” in FIG. 21) is selected from the items displayed in the service list 82 on the client screen 80 described above.
  • the system model of the selected entire monitoring target system 50 is displayed on the client screen 80 as a network graph diagram as described above with reference to FIG.
  • a sub-model of the selected application hereinafter referred to as a selected application
  • the monitoring control client 32 sends a submodel information provision request for the selected application 52 to the portal server 42 ( 4). Further, upon receiving this information provision request, the portal server 42 transmits a submodel generation request for the designated submodel to the sign server 41 (FIG. 4).
  • the sign engine 60 executes the sub model generation process and the failure sign detection process for the selected application 52 in response to the reception of the sub model generation request. Then, the processing results of the sub model generation processing and failure sign detection processing are given to the monitoring control client 32 via the portal server 42, and information based on the processing results of the sub model generation processing and failure sign detection processing is displayed on the client screen 80. Is displayed.
  • the reference index included in the selection application 52 is displayed as the reference index node 86 in the reference index area 83, and the selection application 52 is displayed as the target index node 88 in the network area 84. Only the target metrics included in are displayed.
  • the predicted value control area 100 is also displayed in the reference index area 83.
  • the predicted value control area 100 is provided with a pull-down button 101. By performing a mouse click operation on the pull-down button 101, a pull-down list on which a list of predicted models is posted can be displayed.
  • the predicted value control area 100 is also provided with a text box 102 and a recalculation button 103 in which a person in charge of operation management can input a predicted value.
  • the monitoring control client 32 transmits an information provision request corresponding to this to the portal server 42. Further, when the portal server 42 receives this information provision request, the portal server 42 transmits a submodel generation request designating the submodel and prediction model designated in the information provision request to the sign server 41.
  • the sign engine 60 (FIG. 4) of the sign server 41 that has received this submodel generation request uses the prediction model specified in the submodel generation request instead of the current prediction model (FIG. 4). 16 to FIG. 18), and the result is transmitted to the monitoring control client 32 via the portal server 42.
  • the result of the failure sign detection process is displayed on the client screen 80.
  • the monitoring control client 32 transmits an information provision request corresponding to this to the portal server 42. Further, when the portal server 42 receives this information provision request, the portal server 42 transmits a submodel generation request designating the predicted value designated in the information provision request to the sign server 41.
  • the predictive engine 60 of the predictive server 41 that has received this submodel generation request sets the submodel and predicted value specified in the submodel generation request as evidence without executing the time series prediction processing, and performs probability inference processing. And the result is transmitted to the monitoring control client 32 via the portal server 42. As a result, the processing result of the probability inference processing (FIG. 18) is displayed on the client screen 80.
  • the information processing system 10 of the present embodiment uses the system model of the monitoring target system 50 generated in advance in the sign server 41 of the service provider side system 24. Then, a sub model consisting only of nodes involved in the execution of the application designated by the operation manager of the customer side system 22 is generated, and the future value of the target index is calculated by probability inference based on the generated sub model. To do.
  • such a submodel has a smaller number of nodes than the system model. Therefore, the probability inference processing using the submodel is processed with a much smaller amount of calculation than the probability inference processing using the system model. It can be performed.
  • the future value of the target index for each application can be quickly obtained, and the processing result of the failure sign detection processing is quickly provided to the operation manager in charge of the customer side system. can do.
  • the application profile stores information sufficient to determine the application boundary for the business server name and index name of the business server 30 (FIG. 2) related to the application 52 (FIG. 3). It is assumed that However, in actual system operation, it may not be sufficient.
  • Meta information of time-series data is, for example, information about the time when data collection is started or information about a period during which data collection has been temporarily suspended, but is not limited thereto. .
  • the meta information of a node whose correspondence with the application 52 is unknown is acquired.
  • the system operation management method of this embodiment will be described.
  • reference numeral 110 denotes an information processing system according to the second embodiment as a whole.
  • This information processing system 110 is different in that the processing contents of the sub-model generation process executed by the model generation unit 114 of the sign engine 113 of the sign server 112 shown in FIG. 4 in the service provider side system 111 (FIG. 2) are different.
  • the configuration is the same as that of the information processing system 10 according to the first embodiment.
  • FIG. 22 shows a specific processing procedure of the submodel generation processing of the present embodiment executed by the model generation unit 114.
  • the predictor server 112 receives the submodel generation request transmitted from the portal server 42 (FIG. 4) in response to the information presentation request from the monitoring control client 32 (FIG. 4)
  • the model generation unit 114 is shown in FIG.
  • the submodel generation process is started, and first, a system model having the model name specified in the received submodel generation request is acquired from the system model repository 67 (FIG. 4) (S40).
  • the model generation unit 114 extracts nodes related to the execution of the application 52 based on the information stored in the application profile (S41). Thereafter, all the nodes of the monitoring target system 50 are identified as the application 52. It is determined whether they are associated (S42).
  • the model generation unit 114 When the model generation unit 114 obtains a positive result in this determination, it performs steps S44 to S47 in the same manner as steps S3 to S6 of the submodel generation processing according to the first embodiment described above with reference to FIG. Thereafter, the submodel generation process is terminated.
  • the model generation unit 114 acquires meta information of the measurement value corresponding to the node. Typically, it is information relating to a period during which the measurement values are collected. Then, the model generation unit 114 compares the meta information of the node whose correspondence with the application 52 is known and the meta information of the node which is not known, and determines that the nodes are related to the same application 52 if they are similar. (S43). As a comparison method, for example, a statistical classification method such as a k-nearest neighbor method can be used.
  • the model generation unit 114 performs steps S44 to S47 in the same manner as steps S3 to S6 of the submodel generation processing according to the first embodiment described above with reference to FIG. The generation process ends.
  • the model generation unit 114 A sub-model consisting only of nodes relevant to the execution of the requested application 52 can be generated. Therefore, according to the information processing system 110, in addition to the effects obtained by the first embodiment, an information processing system with higher flexibility can be realized.
  • a failure sign detection method configured to determine the correspondence between nodes and applications using the graph structure of the system model. That is, on the assumption that the corresponding application 52 is known for the reference index and the target index, all paths connecting the two are derived, and those on the path are regarded as related to the application 52.
  • the failure sign detection method of this embodiment will be described.
  • reference numeral 120 denotes an information processing system according to the third embodiment as a whole.
  • This information processing system 120 is the second except that the processing contents of the submodel generation processing executed by the model generation unit 124 of the indication engine 123 of the indication server 122 shown in FIG.
  • the configuration is the same as the information processing system 110 according to the embodiment.
  • FIG. 23 shows a specific processing procedure of the sub-model generation processing of the present embodiment executed by the model generation unit 124.
  • the predictor server 112 receives the submodel generation request transmitted from the portal server 42 (FIG. 4) in response to the information presentation request from the monitoring control client 32 (FIG. 4), the model generation unit 124 is shown in FIG.
  • the submodel generation process is started, and steps S50 to S52 are processed in the same manner as steps S40 to S42 of the submodel generation process according to the second embodiment described above with reference to FIG.
  • the model generation unit 124 When the model generation unit 124 obtains a positive result in the determination at step S52, it performs steps S54 to S57 in the same manner as steps S3 to S6 of the submodel generation process according to the first embodiment described above with reference to FIG. Thereafter, the submodel generation process is terminated.
  • the model generation unit 124 when the model generation unit 124 obtains a negative result in the determination at step S52, the model generation unit 124 extracts information on the reference index and the target index stored in the application index table 74 (FIG. 9). Then, the model generation unit 124 searches for all paths connecting the reference index and the target index for each application 52 in the graph structure of the system model of the monitoring target system 50. For the route search, for example, a back tracking method can be used. Then, the model generation unit 124 determines that a node on the path obtained between the reference index and the target index of a certain application 52 is related to the application 52 (S53).
  • the model generation unit 124 processes steps S54 to S57 in the same manner as steps S3 to S6 of the submodel generation process according to the first embodiment described above with reference to FIG. The generation process ends.
  • the information processing system 120 of the present embodiment it is possible to extract the correspondence relationship between the application 52 and each node with higher reliability than in the second embodiment. Therefore, according to the information processing system 120, an information processing system with higher flexibility and reliability can be realized.
  • the present invention is not limited to the above-described embodiments, and includes various modifications.
  • the first to third embodiments described above have been described in detail for easy understanding of the present invention, and are not necessarily limited to those having all the configurations described.
  • a part of the configuration of one embodiment can be replaced with the configuration of another embodiment, and the configuration of another embodiment can be added to the configuration of one embodiment. .
  • each of the configurations, functions, processing units, processing units, and the like of the first to third embodiments described above may be realized by hardware by designing a part or all of them, for example, by an integrated circuit.
  • each configuration, function, and the like of the first to third embodiments may be realized by software by interpreting and executing a program that realizes each function by the processor.
  • Information such as programs, tables, and files that realize each function should be stored in a memory, a storage device such as HDD or SSD, or a storage medium such as an SD card or DVD-ROM (Digital Versatile Disk-Read Only Memory). Can do.
  • the present invention can be widely applied to various information processing systems.
  • System profile 67... System model repository, 68... Prediction profile, 69... Prediction model repository, 70... System profile table, 71 and 72 ... System model, 71A to 71F, 72A to 72J. ... nodes, 73 ... application business server correspondence table, 74 ... application index table, 75 ... application node table, 76 ... subgraph, 80 ... client screen, 81 ... service list, 83 ...

Landscapes

  • Engineering & Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • Computer Hardware Design (AREA)
  • Quality & Reliability (AREA)
  • Physics & Mathematics (AREA)
  • General Physics & Mathematics (AREA)
  • Debugging And Monitoring (AREA)

Abstract

【課題】　障害予兆検知処理の処理結果を迅速に提供し得る監視方法、監視装置及び記憶媒体を提案する。 【解決手段】　監視対象システムにおける基準指標及びターゲット指標を含む複数の指標についての計測値を取得し、複数の指標の計測値に基づいて、基準指標の将来の値でなる予測値を予測し、監視対象システムのシステムモデル及び当該システムモデルの一部であるサブモデルを生成し、基準指標の予測値及び生成したサブモデルに基づいて、ターゲット指標の計測値が所定値又は所定値の範囲となる確率を推論するようにした。

Description

監視方法、監視装置及び記憶媒体
　本発明は、監視方法、監視装置及び記憶媒体に関し、特に監視対象システムの稼働状況を監視し、システムに障害が発生する予兆を確率的な推論により検知し、推論の結果を通知する監視装置に適用して好適なものである。
　情報処理システムが企業活動や社会インフラの基盤としてますます重要な位置を占めるようになるにつれ、情報処理システムが提供するサービスの内容や品質についてＳＬＡ（Service Level Agreement）／ＳＬＯ（Service Level Objective）という形で具体的な数値目標を設定することが広く行われるようになった。
　その帰結として、こうした情報処理システムにおける障害の発生を早期に検知し、又は発生した障害の根本原因を分析して迅速な対処を図ることを目的とした様々な技術が開発され、システムの運用管理業務に適用されている。さらに近年では、こうした障害の発生に先立って、その予兆を検知しようとする障害予兆検知技術の重要性が注目されている。
　例えば特許文献１には、イベントログ及びシステムパラメタログといった情報を予測モデルに入力することで、コンピュータクラスタにおける重要イベントの発生を予測可能なハイブリッド予測システムが開示されている。このハイブリッド予測システムでは、確率モデルの一種であるベイジアンネットワークを用いて障害予兆検知を行う。
　ベイジアンネットワークを用いた予測は一般に確率推論と呼ばれる。これは、複数の確率変数の依存関係を表現する非循環有向グラフと条件付き確率表から、確率変数の周辺事後確率を求める演算である。ベイジアンネットワーク及び確率推論については、例えば非特許文献１に開示されている。
米国特許第７，８９５，３２３号明細書
Daphne Koller and Nir Friedman. 2009. Probabilistic Graphical Models: Principles and Techniques - Adaptive Computation and Machine Learning. The MIT Press
　ところで、確率推論の演算はＮＰ困難問題として知られており（非特許文献１を参照）、一般的にその計算量は、ベイジアンネットワークが含むノード数に対して指数関数的に増加する。
　近年の高度化、複雑化した情報処理システムには大量の監視ポイントが設定可能であり、それらから収集した監視データをベイジアンネットワークによりモデル化すると、必然的に多数のノードにより構成される大規模なモデルになることが想定される。こうしたモデルによる障害予兆検知は、計算量の増大に対してなんらかの対策を取らねばならない。
　仮に、障害予兆検知をサービスとして提供するのであれば、一定のインターバルを置いて確率推論をバッチ的に実行し、その結果を提示するといった運用により、演算を行う時間的な猶予を確保することができる。
　一方で、こうした高度な情報処理システムは、サーバのような物理的に独立した計算資源の単位を超えて、論理的に別個の複数のアプリケーションプログラムがデプロイメントされ、それらがデータベース管理サーバのような資源を共有するといった態様があり得る。そして、複数のアプリケーションプログラムについてそれぞれ個別の運用管理担当者が運用管理を担当するであろう。
　こうした態様では、障害予兆検知サービスが一律に提供する予測結果ではなく、当該障害予兆検知サービスの利用者である運用管理担当者が、障害予兆検知の前提条件を各々の関心の範囲で任意に設定し、その条件に基づいた予測結果を得ようとすることが考えられる。このようなインタラクティブに確率推論を実行する態様においては、バッチ実行のような時間的猶予はない。
　以上述べたような、ベイジアンネットワークでモデル化する情報処理システムの大規模化、計算資源の論理的な分割と関心範囲の多層化、インタラクティブ実行の必要性といった条件を鑑みるに、確率推論の高速化が必要である。またその方法は、確率推論を行うベイジアンネットワークのノード数の削減によって達成せねばならない。確率推論は厳密解法も近似解法もＮＰ困難であるためである。
　本発明は以上の点を考慮してなされたものであり、障害予兆検知処理の処理結果を迅速に提供し得る監視方法、監視装置及び記憶媒体を提案しようとするものである。
　かかる課題を解決するため本発明においては、１又は複数の計算機から構成される監視対象システムの稼働状況を監視し、当該監視対象システムにおける障害発生の予兆検知を行う監視装置において実行される監視方法において、前記監視装置は、各種処理に必要な情報が格納された記憶装置と、前記記憶装置に格納された前記情報を参照して処理を実行する処理部とを有し、前記処理部が、前記監視対象システムにおける基準指標及びターゲット指標を含む複数の指標についての計測値を取得する第１のステップと、前記処理部が、複数の前記指標の計測値に基づいて、前記基準指標の将来の値でなる予測値を予測する第２のステップと、前記処理部が、前記監視対象システムのシステムモデル及び当該システムモデルの一部であるサブモデルを生成し、前記基準指標の予測値及び生成した前記サブモデルに基づいて、前記ターゲット指標の計測値が所定値又は所定値の範囲となる確率を推論する第３のステップとを設けるようにした。
　また本発明においては、１又は複数の計算機から構成される監視対象システムの稼働状況を監視し、当該監視対象システムにおける障害発生の予兆検知を行う監視装置において、各種処理に必要な情報が格納された記憶装置と、前記記憶装置に格納された前記情報を参照して処理を実行する処理部とを有し、前記処理部は、前記監視対象システムにおける基準指標及びターゲット指標を含む複数の指標についての計測値を取得するデータ取得部と、複数の前記指標の計測値に基づいて、前記基準指標の将来の値でなる予測値を予測する予測部と、前記監視対象システムのシステムモデルを生成する一方、当該システムモデルの一部であるサブモデルを生成するモデル生成部と、前記基準指標の予測値及び生成した前記サブモデルに基づいて、前記ターゲット指標の計測値が所定値又は所定値の範囲となる確率を推論する確率推論部とを設けるようにした。
　さらに本発明においては、監視プログラムが格納された記憶媒体において、監視プログラムは、１又は複数の計算機から構成される監視対象システムの稼働状況を監視し、当該監視対象システムにおける障害発生の予兆検知を行う監視装置に、前記監視対象システムにおける基準指標及びターゲット指標を含む複数の指標についての計測値を取得する第１のステップと、複数の前記指標の計測値に基づいて、前記基準指標の将来の値でなる予測値を予測する第２のステップと、前記監視対象システムのシステムモデル及び当該システムモデルの一部であるサブモデルを生成し、前記基準指標の予測値及び生成した前記サブモデルに基づいて、前記ターゲット指標の計測値が所定値又は所定値の範囲となる確率を推論する第３のステップとを備える処理を実行させるようにした。
　本監視方法、監視装置及び監視プログラムによれば、システムモデルを用いてターゲット指標の計測値が所定値又は所定値の範囲となる確率を推論する場合と比して、格段的に少ない計算量でかかる推論を行うことができる。
　本発明によれば、障害予兆検知処理の処理結果を迅速に提供することができる。
情報処理装置の構成例を示すブロック図である。 第１～第３の実施の形態による情報処理システムの構成例を示すブロック図である。 監視対象システムの構成例を示すブロック図である。 予兆サーバの構成例を示すブロック図である。 システムプロファイルテーブルの構成例を示す概念図である。 ベイジアンネットワークのグラフ構造の一例を示す図である。 ベイジアンネットワークのグラフ構造の別の一例を示す図である。 アプリケーション業務サーバ対応テーブルの構成例を示す概念図である。 アプリケーション指標テーブルの構成例を示す概念図である。 アプリケーションノードテーブルの構成例を示す概念図である。 アプリケーション境界を明示したベイジアンネットワークのグラフ構造の一例を示す図である。 アプリケーション境界に従って部分グラフを抽出したベイジアンネットワークのグラフ構造の一例を示す図である。 システムモデルリポジトリの構成例を示す概念図である。 予測モデルリポジトリの構成例を示す概念図である。 予測プロファイルの構成例を示す概念図である。 障害予兆検知処理の処理手順を示すフローチャートである。 時系列予測処理の処理手順を示すフローチャートである。 確率推論処理の処理手順を示すフローチャートである。 第１の実施の形態によるサブモデル生成処理の処理手順を示すフローチャートである。 クライアント画面における情報表示例を示すレイアウト図である。 クライアント画面における他の情報表示例を示すレイアウト図である。 第２の実施の形態によるサブモデル生成処理の処理手順を示すフローチャートである。 第３の実施の形態によるサブモデル生成処理の処理手順を示すフローチャートである。
　以下図面について、本発明の一実施の形態を詳述する。
（１）第１の実施の形態
（１－１）情報処理装置の構成
　図１は、情報処理装置の構成例を示す。情報処理装置１は、例えばラックマウントサーバ、ブレードサーバ又はパーソナルコンピュータなどから構成され、プロセッサ２、メモリ３、ストレージ４、ネットワークインタフェース５及びコンソール６を備える。プロセッサ２は、メモリ３、ストレージ４、ネットワークインタフェース５及びコンソール６と接続される。
　プロセッサ２は、ＣＰＵ（Central Processing Unit）等のハードウェアである。メモリ３は、例えば揮発性の半導体メモリから構成され、プログラムやデータを一時的に保持するために利用される。またストレージ４は、例えばハードディスクドライブ（ＨＤＤ：Hard Disk Drive）、ソリッドステートドライブ（ＳＳＤ：Solid State Drive）、又はこれらを複数台組み合わせた記憶装置から構成され、プログラムやデータを長期間保持するために利用される。
　ストレージ４に格納されたオペレーティングシステム（ＯＳ：Operating System）７やユーザプロセス８が情報処理装置１の起動時やその実行時にメモリ３に読み出され、メモリ３に読み出されたこれらオペレーティングシステム７及びユーザプロセス８をプロセッサ２が実行することにより、情報処理装置１全体として後述のような各種処理が行われる。
　ネットワークインタフェース５は、例えばＮＩＣ（Network Interface Card）などから構成され、ネットワークスイッチ９を経由してネットワーク１０と接続される。ネットワークインタフェース５は、ネットワーク１０を介した他の情報処理装置との通信時におけるプロトコル制御を行う。なおネットワーク１０としては、例えばイーサネット（登録商標）や、ＩＥＥＥ（Institute of Electrical and Electronics Engineers）８０２．１１規格に基づく無線ネットワーク、ＳＤＨ／ＳＯＮＥＴ（Synchronous Optical Network/Synchronous Digital Hierarchy）規格に基づく広域ネットワーク、又は、これら複数のネットワーク技術を組み合わせたネットワークを適用することができる。
　コンソール６は、例えばキーボード及びマウス等の入力装置と、液晶パネル等のディスプレイ装置とから構成され、入力装置から与えられる各種操作入力に応じた操作信号を受信して操作入力内容をプロセッサ２に通知したり、プロセッサ２から与えられるテキスト情報やグラフィカル情報に基づくテキストや画像等をディスプレイ装置に表示する。
　なお情報処理装置１は、プロセッサ２、メモリ３、ストレージ４、ネットワークインタフェース５及びコンソール６の一部又は全部を複数備えることがある。また、情報処理装置１及びオペレーティングシステム７の関係は１対１に限定されず、仮想化技術に基づき１つの情報処理装置１が複数のオペレーティングシステム７を実装することもあり得る。
（１－２）本実施の形態による監視サービスシステムの構成
　図２は、本実施の形態による情報処理システム２０の概略構成を示す。この図２に示すように、本情報処理システム２０は、顧客サイト２１に設けられた顧客側システム２２と、顧客側システム２２を監視するシステム監視サービスを提供するサービス提供者のサービスサイト２３に設けられたサービス提供者側システム２４とから構成される。顧客側システム２２及びサービス提供者側システム２４は、いずれも図１について上述した情報処理装置１を１つ以上含み、これら情報処理装置１がネットワーク１０及び１つ以上のネットワークスイッチ９を介して相互に接続されている。
　顧客サイト２１及びサービスサイト２３は、典型的には地理的な遠隔地にあり、広域ネットワークにより接続されるが、これ以外の態様、例えば顧客サイト２１及びサービスサイト２３が同一のデータセンタ内に存在し、データセンタ内のネットワークにより接続されていても良い。いずれの態様によっても、顧客サイト２１に存する情報処理装置１と、サービスサイト２３に存する情報処理装置１は、顧客サイト２１及びサービスサイト２３間を接続するネットワークを経由して相互に通信することができる。
　こうした顧客サイト２１及びサービスサイト２３間の通信は、情報セキュリティの維持を理由として、ネットワークルータやファイアウォール装置の設定により制限されることもあり得るが、本実施の形態において必要となる通信は、それらを可能ならしめるよう設定されているものとする。
　顧客側システム２２は、それぞれ図１について上述した情報処理装置１から構成される１又は複数の業務サーバ３０と、ログ収集装置３１及び監視制御クライアント３２と、１又は複数の業務クライアント３３とを備える。
　業務サーバ３０は、ユーザプロセス８（図１）としてアプリケーションプログラム３４が実装されており、プロセッサ２（図１）がこれを実行することにより業務クライアント３３からの要求に応じた処理を実行する。
　ログ収集装置３１は、各業務サーバ３０から、ＣＰＵ稼働率、メモリ消費量、同時接続ユーザ数及び平均応答時間などの計測値といったその業務サーバ３０の稼働状況を表す情報（以下、これをシステム統計情報と呼ぶ）３５を定期的に収集する。この処理は、ログ収集装置３１のストレージ４（図１）に記憶されたプログラムをプロセッサ２（図１）が実行することにより行われる。システム統計情報３５を収集する対象は典型的には業務サーバ３０であるが、これに限定するものではなく、その他の情報処理装置１、業務クライアント３３及び又はネットワークスイッチ９（図１）等をかかる対象に含めることができる。
　監視制御クライアント３２には、ユーザプロセス８としてＷｅｂブラウザ３６が実装される。Ｗｅｂブラウザ３６は、コンソール６（図１）から顧客側システム２２の運用管理担当者の指示を受信することを契機として、後述するサービス提供者側システム２４のポータルサーバ４２に対して情報（ここでは障害予知検知処理の処理結果）の提示を要求し、この要求に応じてポータルサーバ４２から送信されてきた情報をコンソール６に表示する。ただし、Ｗｅｂブラウザ３６が事前に決められた任意の間隔で情報の提示をポータルサーバ４２に要求するよう構成しても良い。また顧客側システム２２の運用管理担当者への情報提示方法としては、監視制御クライアント３２のコンソール６に情報を表示する方法以外にも、監視制御クライアント３２の外部にある情報処理装置への転送や電子メールの送信等、運用管理担当者にとって適切な任意の手段を採用することができる。
　業務クライアント３３には、顧客の業務内容に応じた業務クライアントプログラム３７がユーザプロセス８として実装される。業務クライアントプログラム３７は、業務サーバ３０で実行されているアプリケーションプログラム３４と通信を行いながら必要な処理を実行する。こうしたプログラム間の相互通信により、特定の業務上の目的を達成するようアプリケーションプログラムを構成する方法はクライアント・サーバ方式と呼ばれ、典型的にはＷｅｂアプリケーションという態様にて当業者には周知のものである。なお業務クライアント３３は、顧客サイト２１から離れて存在しても良い。こうした業務クライアント３３は、それぞれが接続されたネットワーク１０（図１）を経由して業務サーバ３０と通信を行う。
　サービス提供者側システム２４は、顧客側システム２２の稼働状況を監視し、顧客側システム２２に障害が発生する予兆を確率的な推論により検知し、推論の結果を通知するシステム監視サービスを提供するシステムであり、それぞれ図１について上述した情報処理装置１から構成される蓄積サーバ４０、予兆サーバ４１及びポータルサーバ４２を備える。
　蓄積サーバ４０は、ログ収集装置３１が収集した各業務サーバ３０のシステム統計情報３５を定期的に受信し、受信したシステム統計情報３５を蓄積する。システム統計情報３５を受信するための通信は、ログ収集装置３１がその契機となる通信を開始する方法や、逆に蓄積サーバ４０がその契機となる通信を開始する方法のいずれを選択しても良い。
　予兆サーバ４１は、蓄積サーバ４０が蓄積するシステム統計情報３５を受信し、受信したシステム統計情報３５に基づいて、顧客側システム２２の稼働状況を監視し、顧客側システム２２に障害が発生する予兆を確率的な推論により検知する処理（以下、これを障害予兆検知処理と呼ぶ）を実行する。
　ポータルサーバ４２は、蓄積サーバ４０が蓄積するシステム統計情報３５や、予兆サーバ４１により行われた障害予兆検知処理の処理結果を顧客側システム２２の監視制御クライアント３２（正確には、監視制御クライアント３２上で稼働するＷｅｂブラウザ３６）からの要求に応じてその監視制御クライアント３２に通知する。
　なお顧客側システム２２のログ収集装置３１及び監視制御クライアント３２や、サービス提供者側システム２４の蓄積サーバ４０、予兆サーバ４１及びポータルサーバ４２の一部又は全部を、処理負荷の分散や可用性の向上等を目的として、複数台設けるようにしても、また１台の情報処理装置１に上述した複数種類のサーバの役割を兼用させるようにしても良い。物理的な情報処理装置１と、そのサーバとしての役割の対応関係には自由度があり、図２はその多数の組み合わせの中の一例であることは留意されたい。
　以上のようにサービス提供者側システム２４の蓄積サーバ４０、予兆サーバ４１及びポータルサーバ４２をサービスサイト２３に設置することで、顧客サイト２１にこれらのサーバ群を設置することなく、顧客側システム２２に対する障害予兆検知を行うことができる。これら蓄積サーバ４０、予兆サーバ４１及びポータルサーバ４２は、データの蓄積や処理を目的として、大容量のストレージや高速なプロセッサ等のハードウェア資源を必要とするため、顧客にとってはそうした高性能かつ高価なハードウェアの導入が不要になる効果がある。
　また、図２は、顧客側システム２２及びサービス提供者側システム２４がそれぞれ１つである場合を例示しているが、これは顧客側システム２２ごとに個別のサービス提供者側システム２４を用意すべきことを意味するものではない。１つのサービス提供者側システム２４によって、複数の顧客側システム２２の障害予兆検知を行うこともできる。
　この場合、サービス提供者側システム２４は、複数の顧客側システム２２に対するシステム監視サービスに供される。例えば蓄積サーバ４０は、複数の顧客側システム２２の各ログ収集装置３１からそれぞれ送信されるシステム統計情報３５を蓄積し、ポータルサーバ４２は、複数の顧客側システム２２の各監視制御クライアント３２に対してそれぞれ情報の提供を行う。同様に、予兆サーバ４１は、複数の顧客側システム２２から収集したシステム統計情報３５に基づいて、個々の顧客側システム２２の障害予兆検知を行う。
　サービス提供者側システム２４が複数の顧客側システム２２に対する障害予兆検知処理を実行する場合、サービス提供者側システム２４内において、各顧客側システム２２からそれぞれ収集したシステム統計情報３５を区別して取り扱うために、個々の顧客側システム２２の区別に供するためのコードを共有する。こうしたコードの付与によりデータの区別やセキュリティ保護を行う方法は当業者には周知のことであるため、以下の説明ではこのコードについては言及しないものとする。また、以下においては、各テーブルにそれぞれ記憶された情報や、コンソール６（図１）が表示する情報に関しても、当該コードの説明は省略するものとする。
（１－３）監視対象システム
　図３は、サービス提供者側システム２４の監視対象となる、顧客側システム２２内の監視対象システム５０の構成例を示す。
　システム監視サービスにおける監視対象は、顧客側システム２２内の業務サーバ３０を単位とすることが多いが、これに限るものではない。上述のように、業務サーバ３０はユーザプロセス８（図１）としてアプリケーションプログラム３４（図２）を実装する。こうしたアプリケーションプログラム３４は、業務サーバ３０が単独で実行するとは限らない。むしろ、複数の業務サーバ３０に、それぞれ別個の役割を持つアプリケーションプログラム３４や、その実行を支援するミドルウェアといったプログラムが実装されており、これら複数のプログラムが相互に通信を行いつつ、ある業務上の目的を達成すべく実行されているのが通常の顧客側システム２２の態様である。
　一般に、こうした複数の情報処理装置に分散して実装された多数のプログラムが協調して動作する機能（以下、アプリケーションプログラムにより実現される機能をアプリケーションと呼ぶ）を分散アプリケーションと呼び、こうしたシステムを分散処理システムと呼ぶ。システム監視サービスにおいて、分散アプリケーションの実行に係る装置の一群を監視対象システム５０と呼ぶ。監視対象システム５０は、顧客側システム２２を構成する装置群を分界し区別する単位を成す。
　典型的には、業務サーバ３０は、ユーザプロセス８としてアプリケーションプログラム３４を実装する。業務クライアント３３は、ユーザプロセス８として業務クライアントプログラム３７を実装する。業務サーバ３０及び業務クライアント３３はいずれも複数が存在し、ネットワーク１０がこれらを相互に接続する。
　業務サーバ３０はアプリケーションプログラム３４を実装するが、その具備する機能や業務上の目的が異なる複数のアプリケーションプログラム３４が存在することがあり得る。また業務サーバ３０は、データベース管理システム（ＤＢＭＳ）といったミドルウェア５１を実装することもあり得る。
　こうした複数のアプリケーションプログラム３４及びミドルウェア５１が協調して動作する態様として、例えば図３では、あるアプリケーション５２は、「ＡＰ１」という業務サーバ３０及び「ＤＢ１」という業務サーバ３０が、また別のアプリケーション５２Ｂは、「ＡＰ２」という業務サーバ３０及び「ＤＢ１」という業務サーバ３０が、それぞれ相互に通信を行いつつ、それぞれ業務上の目的を達成するべく設定されている状態を示している。また別のアプリケーション５２Ｃは、アプリケーション５２Ａ及びアプリケーション５２Ｂのいずれとも重複しない「ＡＰ３」という業務サーバ３０と、「ＤＢ２」という業務サーバ３０とが相互に通信を行いつつ業務上の目的を達成する。
　このように、監視対象システム５０は複数のアプリケーション５２（５２Ａ～５２Ｃ）を含むことがある。そして、こうした複数のアプリケーション５２は同一の業務サーバ３０を共有することがある。
　一般に顧客側システム２２の運用管理業務では、顧客サイト２１に存する情報処理装置１の個別の稼働状況を把握するのに留まらず、監視対象となる顧客側システム２２全体又はアプリケーション５２全体としての稼働状況を把握する必要がある。
（１－４）予兆サーバの論理構成
（１－４－１）予兆サーバの概要
　図４は、サービス提供者側システム２４の予兆サーバ４１の論理構成を示す。予兆サーバ４１には、ユーザプロセス８として予兆エンジン６０が実装される。予兆エンジン６０は、ストレージ４（図１）に記憶された予兆エンジンプログラム（図示せず）をメモリ３（図１）に読み出し、読み出した予兆エンジンプログラムをプロセッサ２（図１）が実行することにより具現化される。
　予兆エンジン６０は、データ取得部６１、データ記憶部６２、モデル生成部６３、予測部６４及び推論部６５を備えて構成される。また予兆サーバ４１のメモリ３（図１）には、システムプロファイル６６、システムモデルリポジトリ６７、予測プロファイル６８及び予測モデルリポジトリ６９が格納されている。なお、これら情報は、メモリ３に代えてストレージ４（図１）に記憶しても良いし、他のサーバに格納しておき必要に応じて通信により取得するように構成しても良い。
　以下、予兆エンジン６０のデータ取得部６１、データ記憶部６２、モデル生成部６３、予測部６４及び推論部６５について説明する。なお、これらの実体はプログラム関数、プログラムモジュール、ライブラリ又はクラスインスタンス等であっても、これらを複合したものでも、また他の実体であっても良い。さらには、これらの各部が提供する処理を達成できるのであれば、各部はプログラム又はユーザプロセスとして明確に区別できる存在である必要はなく、予兆エンジンプログラム単体又はＯＳ等の他のプログラムと共同で各部が提供する処理を行えれば問題ない。
　予兆エンジン６０のデータ取得部６１は、蓄積サーバ４０に対してシステム統計情報３５を送信するよう要求し、当該要求に応じて蓄積サーバ４０から送信されるシステム統計情報３５を受信してデータ記憶部６２に格納する。またモデル生成部６３は、データ記憶部６２に記憶されたシステム統計情報３５と、後述のように予測部６４から与えられる予測値とに基づいて監視対象システム５０のシステムモデルを生成し、生成したシステムモデルをシステムモデルリポジトリ６７に格納する。
　予測部６４は、データ記憶部６２に記憶されたシステム統計情報３５と、予測プロファイル６８に格納された情報と、予測モデルリポジトリ６９に格納された情報とに基づいて後述する時系列予測処理を実行し、当該時系列予測処理により得られた予測値を推論部６５及びモデル生成部６３に通知する。推論部６５は、受領した予測値と、システムモデルリポジトリ６７に格納されたシステムモデルと、予測プロファイル６８に格納された情報とに基づいて確率推論処理を実行し、得られた確率値又は確率分布をポータルサーバ４２に送信する。予測部６４及び推論部６５が実行する以上の一連の処理が障害予兆検知処理である。
　予兆エンジン６０がポータルサーバ４２に確率値又は確率分布を送信するにあたっては、必ずしも障害予兆検知処理に同期して行う必要はなく、確率推論処理により得られた確率値又は確率分布をメモリ３（図１）やストレージ４（図１）に格納しておき、ポータルサーバ４２からの情報の提示要求に応じてポータルサーバ４２に送信するようにしても良い。
　以下、予兆サーバ４１が実行する障害予兆検知処理の核心をなす、システムプロファイル６６及びシステムモデルリポジトリ６７の構成と、予兆エンジン６０のモデル生成部６３、予測部６４及び推論部６５によりそれぞれ実行される各処理とについて具体的に説明する。
（１－４－２）システムプロファイルの構成
　システムプロファイル６６は、少なくとも図５に示すシステムプロファイルテーブル７０を備える。システムプロファイルテーブル７０は、予兆エンジン６０（図４）が図３について上述した監視対象システム５０を管理するために利用するテーブルであり、図５に示すように、システムＩＤフィールド７０Ａ、システム名フィールド７０Ｂ及び任意の個数の計測値フィールド７０Ｃから構成される。システムプロファイルテーブル７０の１つのレコード（行）は、１つの監視対象システム５０に対応する。
　そしてシステムＩＤフィールド７０Ａには、監視対象システム５０に付与されたその監視対象システム５０に固有の識別子（システムＩＤ）が格納され、システム名フィールド７０Ｂには、対応する監視対象システム５０を顧客側システム２２の運用管理担当者が特定できるよう付与された当該監視対象システム５０の名称（システム名）が格納される。
　また各計測値フィールド７０Ｃには、対応する監視対象システム５０を構成する各業務サーバ３０からログ収集装置３１がそれぞれ収集したシステム統計情報３５に含まれる個々の計測値の名称がそれぞれ格納される。よって、使用する計測値フィールド７０Ｃの個数は、レコード（監視対象システム５０）によって異なるものとなる。本実施の形態においては、計測値の名称（「AP1.cpu」、「DB2.mem」、……）を業務サーバ３０の名称（「AP1」、「AP2」、……）と計測値の種別（「cpu」、「mem」、……）とに基づいて生成して付与しているが、予兆サーバ４１において実行される各処理の円滑な実行を阻害しないよう一意性を担保できる命名の方法であれば、計測値の名称の付与方法はこれに限定するものではない。
　またシステムプロファイルテーブル７０では、監視対象システム５０がその実行に係る分散アプリケーションの性能指標も計測値フィールド７０Ｃに格納される。この性能指標とは、例えばＷｅｂアプリケーションであれば、単位時間当たりの同時接続ユーザ数（「CU1」、「CU2」、……）、平均応答時間（「ART3」、……）といった数値で示される指標である。計測値と同様、こうした性能指標には各々を区別できる名称が付与される。
　システムプロファイルテーブル７０は、典型的には予兆サーバ４１のメモリ３（図１）に格納されているが、ストレージ４（図１）に格納されていても良いし、他のサーバに格納しておき必要に応じて予兆サーバ４１がそのサーバから通信により取得するようにしても良い。また本実施の形態においては、説明を容易とするためにシステムプロファイルテーブル７０に格納されるべきデータの管理形式としてテーブル形式を採用しているが、キー・バリュー形式やドキュメント指向データベースなど、他のデータ管理形式を採用しても良い。
　なおシステムプロファイルテーブル７０の各レコードは、例えば顧客側システム２２の運用管理担当者が入力した情報を用いて作成する。
　図６は、システムモデルリポジトリ６７（図４）に格納される、ベイジアンネットワークによるシステムモデルの一例を示す。システムモデルとは、システムプロファイルテーブル７０に記録されている、監視対象システム５０に係る計測値や性能指標について、その計測値又は性能指標の時系列データを確率変数とみなし、これらの相互の関係を記述する確率モデルである。本実施の形態においては、このようなモデルとしてベイジアンネットワークを利用する。
　ベイジアンネットワークは、複数の確率変数をノードとする非循環有向グラフと、該グラフの表現するノード間の依存関係に基づいた各変数の条件付き確率表又は条件付き確率密度関数により構成される。
　図６は、あるアプリケーション５２（図３）の同時接続ユーザ数（ＣＵ：Concurrent Users）及び平均応答時間（ＡＲＴ：Average Response Time）と、そのアプリケーション５２の実行に関与する業務サーバ３０（図３）のうちのアプリケーションサーバとして機能する業務サーバ３０のＣＰＵ使用率（AP.cpu）及びメモリ消費量（AP.mem）と、そのアプリケーション５２の実行に関与する業務サーバ３０（図３）のうちのデータベースサーバとして機能する業務サーバ３０のＣＰＵ使用率（DB.cpu）及びメモリ消費量（DB.mem）との６つの項目をそれぞれノード７１Ａ～７１Ｆとするベイジアンネットワークにモデル化した例である。
　このベイジアンネットワークによるシステムモデル７１の眼目は、同時接続ユーザ数ＣＵ及び平均応答時間ＡＲＴの依存関係を表現することであり、同時接続ユーザ数ＣＵを基準指標、平均応答時間ＡＲＴをターゲット指標と呼ぶ。ターゲット指標とは、ベイジアンネットワークの確率推論において、事後確率分布を求める対象となるノードを指す。このシステムモデル７１の基準指標である同時接続ユーザ数ＣＵについて、ある値をエビデンスとして設定し、ターゲット指標の事後確率分布を推定することが本実施例における確率推論の典型的な処理である。
　ここで、エビデンスとしてリアルタイムの計測値を設定する代わりに、時系列予測手法により導いた将来の値を設定することで、その将来の時点におけるターゲット指標の事後確率分布を推定することができる。これが本実施の形態における障害予兆検知処理である。
　一般に時系列予測とは、ある変数の通時的な変化を観測して得られたデータ（時系列データ）からモデルを構築し、構築したモデルに基づいて変数の将来の値を予測する技術である。このような技術に適用するモデル構築の手法として、例えば線形単回帰、指数平滑法及びＡＲＩＭＡモデル等が知られている。
　また、こうしたベイジアンネットワークによるモデルは、統計的学習により構築することができる。特に、各確率変数の観測値を利用して、非循環有向グラフの構造を決定することを構造学習、グラフの各ノードの条件付き確率表又は条件付き確率密度関数のパラメタを生成することをパラメタ学習と呼ぶ。
　本実施の形態では、監視対象システム５０をモデル化するベイジアンネットワークのグラフ構造と、条件付き確率表又は条件付き確率密度関数は所与のものとする。
　図７は、図３に示す２つのアプリケーション５２Ａ，５２Ｂを含む監視対象システム５０をベイジアンネットワークのモデルにモデル化した一例を示す。図７に示すシステムモデル７２は、「アプリケーション＃０１」というアプリケーション５２Ａの同時接続ユーザ数（ＣＵ１）及び平均応答時間（ＡＲＴ１）にそれぞれ対応するノード７２Ａ，７２Ｂと、「アプリケーション＃０２」というアプリケーション５２Ｂの同時接続ユーザ数（ＣＵ２）及び平均応答時間（ＡＲＴ２）にそれぞれ対応するノード７２Ｃ，７２Ｄとを含む。
　この２つのアプリケーション５２Ａ，５２Ｂは、それぞれ別個の業務サーバ３０で実行されている。すなわち「アプリケーション＃０１」というアプリケーション５２Ａは「ＡＰ１」という業務サーバ３０で実行され、「アプリケーション＃０２」というアプリケーション５２Ｂは「ＡＰ２」という業務サーバ３０で実行されている。一方、これら２つのアプリケーション５２Ａ，５２Ｂは、データベースサーバとして機能する「ＤＢ１」という業務サーバ３０を共有している。
　このため、かかるシステムモデル７２は、「アプリケーション＃０１」というアプリケーション５２Ａに関わる計測値である、「ＡＰ１」という業務サーバ３０のＣＰＵ使用率（AP1.cpu）及びメモリ消費量（AP1.mem）にそれぞれ対応するノード７２Ｅ，７２Ｆと、「アプリケーション＃０２」というアプリケーション５２Ｂに関わる計測値である、「ＡＰ２」という業務サーバ３０のＣＰＵ使用率（AP2.cpu）及びメモリ消費量（AP2.mem）にそれぞれ対応するノード７２Ｇ，７２Ｈとに加えて、「ＤＢ１」という業務サーバ３０のＣＰＵ使用率（DB1.cpu）及びメモリ消費量（DB1.mem）にそれぞれ対応するノード７２Ｉ，７２Ｊを含む。
　これらシステムモデル７２（ベイジアンネットワーク）が含むノード７２Ａ～７２Ｊを、アプリケーション５２Ａ，５２Ｂを単位として分類するために必要な情報は、システムプロファイル６６を構成するアプリケーションプロファイルである。
　図８～図１０は、図５について上述したシステムプロファイルテーブル７０と共にシステムプロファイル６６（図４）を構成するアプリケーションプロファイル７３～７５の構成例を示す。アプリケーションプロファイル７３～７５は、システム構成情報の一種であり、アプリケーション５２と業務サーバ３０の対応関係を格納するテーブルである。以下においては、図８に示すアプリケーションプロファイルをアプリケーション業務サーバ対応テーブル７３と呼び、図９に示すアプリケーションプロファイルをアプリケーション指標テーブル７４と呼び、図１０に示すアプリケーションプロファイルをアプリケーションノードテーブル７５と呼ぶものとする。
　アプリケーション業務サーバ対応テーブル７３は、アプリケーション５２と、当該アプリケーション５２の実行に関与する業務サーバ３０との対応関係を予兆エンジン６０（図４）が管理するために利用するテーブルであり、図８に示すように、ＩＤフィールド７３Ａ、アプリケーション名フィールド７３Ｂ及び業務サーバ名フィールド７３Ｃから構成される。
　そしてＩＤフィールド７３Ａには、監視対象システム５０内のアプリケーション５２にそれぞれ付与されたそのアプリケーション５２に固有の識別子（アプリケーションＩＤ）が格納され、アプリケーション名フィールド７３Ｂには、対応するアプリケーション５２に付与されたそのアプリケーション５２の名称（アプリケーション名）が格納される。
　また業務サーバ名フィールド７３Ｃは、監視対象システム５０内の各業務サーバ３０にそれぞれ対応させて設けられた複数の個別業務サーバ名フィールド７３ＣＡに区分され、各個別業務サーバ名フィールド７３ＣＡ内に、対応するアプリケーション５２において対応する業務サーバ３０を利用するか否かを表す情報（利用する場合には「Ｙ」、利用しない場合には「Ｎ」）が格納される。
　なおアプリケーション業務サーバ対応テーブル７３の各レコードは、例えば顧客側システム２２の運用管理担当者が入力した情報を用いて作成する。
　またアプリケーション指標テーブル７４は、各アプリケーション５２の性能指標（ここでは基準指標及びターゲット指標）を予兆エンジン６０（図４）が管理するために利用するテーブルであり、図９に示すように、ＩＤフィールド７４Ａ、アプリケーション名フィールド７４Ｂ、基準指標フィールド７４Ｃ及びターゲット指標フィールド７４Ｄから構成される。
　そしてＩＤフィールド７４Ａ及びアプリケーション名フィールド７４Ｂには、それぞれアプリケーション業務サーバ対応テーブル７３のＩＤフィールド７３Ａ及びアプリケーション名フィールド７３Ｂに格納される情報と同じ情報が格納される。また基準指標フィールド７４Ｃには、対応するアプリケーション５２における基準指標が格納され、ターゲット指標フィールド７４Ｄには、対応するアプリケーション５２におけるターゲット指標が格納される。
　以上のアプリケーション業務サーバ対応テーブル７３及びアプリケーション指標テーブル７４にそれぞれ格納された情報と、システムプロファイルテーブル７０に格納された情報とを、計測値の名称を基にマッチングすることで、アプリケーション５２ごとにその実行に関与するノードを抽出することができる。
　アプリケーションノードテーブル７５は、そのマッチングの結果を予兆エンジン６０（図４）が管理するために利用するテーブルであり、図１０に示すように、ＩＤフィールド７５Ａ及びアプリケーション名フィールド７５Ｂと、複数のノードフィールド７５Ｃとから構成される。
　そしてＩＤフィールド７５Ａ及びアプリケーション名フィールド７５Ｂには、それぞれアプリケーション業務サーバ対応テーブル７３（図８）のＩＤフィールド７３Ａ及びアプリケーション名フィールド７３Ｂに格納された情報と同じ情報が格納される。また各ノードフィールド７５Ｃには、対応するアプリケーション５２の実行に関与するノードのノード名が格納される。
　図１１は、システムモデル７２にアプリケーション境界を設定した一例を示す。これは図７に示した２つのアプリケーション５２Ａ，５２Ｂを含むシステムモデルに対して、図８～図１０に示したアプリケーションプロファイル（アプリケーション業務サーバ対応テーブル７３、アプリケーション指標テーブル７４及びアプリケーションノードテーブル７５）の情報に基づいて、各ノードがいずれのアプリケーション５２に関与するかで分類し、その結果からアプリケーション境界を設定したものである。このシステムモデル７２は、「アプリケーション＃０１」というアプリケーション５２Ａにのみ属するノード７２Ａ，７２Ｂ，７２Ｅ，７２Ｆと、「アプリケーション＃０２」というアプリケーション５２Ｂにのみ属するノード７２Ｃ，７２Ｄ，７２Ｇ，７２Ｈと、両アプリケーション５２Ａ，５２Ｂが共有するノード７２Ｉ，７２Ｊを含む。
　この図１１のモデルからも明らかなように、「アプリケーション＃０１」というアプリケーション５２Ａに関係するノード７２Ａ，７２Ｂ，７２Ｅ，７２Ｆのみを含む部分グラフを抽出するには、両アプリケーション５２Ａ，５２Ｂが共有する「DB1.cpu」及び「DB1.mem」という２つのノード７２Ｉ，７２Ｊについて、「アプリケーション＃０２」というアプリケーション５２Ｂにのみ関係するノード７２Ｃ，７２Ｄ，７２Ｇ，７２Ｈとの間のアークａ～ｃを削除し、かつベイジアンネットワークとして確率推論を実行できるよう、条件付き確率表又は条件付き確率密度関数を維持する必要がある。このアーク削除の方法を、以下の（Ａ）～（Ｃ）の３つに分類して説明する。
（Ａ）　アークａは、「アプリケーション＃０１」及び「アプリケーション＃０２」という２つのアプリケーション５２Ａ，５２Ｂが共有する「DB1.mem」というノード（以下、これを共有ノードと呼ぶ）７２Ｊと、当該ノード７２Ｊの親ノードである「CU2」というノード７２Ｃとの間を直接に接続している。この場合、「CU2」というノード７２Ｃに設定されるエビデンスから、その直接の子ノードである「DB1.mem」というノード７２Ｊの条件付き確率表を更新することでアークａを削除することができる。
（Ｂ）　アークｂは、まずアークａと同様にして「AP2.cpu」というノード７２Ｇ及び「AP2.mem」というノード７２Ｈの条件付き確率表を更新したのち、variable eliminationアルゴリズム（非特許文献１を参照）により、「AP2.cpu」というノード７２Ｇ及び「AP2.mem」というノード７２Ｈをグラフから削除し、「DB1.cpu」という共有ノード７２Ｉの条件付き確率表を更新することで削除することができる。
（Ｃ）　アークｃは、「DB1.mem」という共有ノード７２Ｊと、「ART2」というノード７２Ｄとの間を直接に接続しており、「ART2」というノード７２Ｄは「DB1.mem」というノード７２Ｊの子ノードである。このような末端ノードの場合、「ART2」というノード７２Ｄにエビデンスを設定しない限り、「ART1」というノード７２Ｂの確率分布に影響が及ぶことはない。よって何らの操作を行うことなく、アークｃを削除することができる。
　以上の手法を組み合わせることで、「アプリケーション＃０１」というアプリケーション５２Ａに関係するノード７２Ａ，７２Ｂ，７２Ｅ，７２Ｆ，７２Ｉ，７２Ｊのみを含む図１２に示すような部分グラフ７６を抽出することができる。こうして抽出された部分グラフ７６とこれに対応する条件付き確率表により、「アプリケーション＃０１」というアプリケーション５２Ａに関係するノード７２Ａ，７２Ｂ，７２Ｅ，７２Ｆ，７２Ｉ，７２Ｊのみで確率推論が可能であることに注意されたい。この部分グラフ７６によるベイジアンネットワークモデルをサブモデルと呼ぶ。
（１－４－３）システムリポジトリの構成
　図１３は、システムモデルリポジトリ６７（図４参照）の構成例を示す。システムモデルリポジトリ６７には、上述のように予兆エンジン６０のモデル生成部６３により生成されたシステムモデルが記録される。本実施の形態の場合、システムモデルリポジトリ６７は、ＩＤフィールド６７Ａ、モデル名フィールド６７Ｂ、グラフ構造フィールド７６Ｃ及びパラメタフィールド６７Ｄを備えるテーブル構造を有する。
　そしてＩＤフィールド６７Ａには、各システムモデルにそれぞれ付与されたそのシステムモデルに固有の識別子（システムモデルＩＤ）が格納される。またモデル名フィールド６７Ｂには、対応するシステムモデルに付与されたモデル名が格納される。このモデル名は、各システムモデルを弁別することが容易となるよう運用管理担当者が付与することができる。
　またグラフ構造フィールド６７Ｃには、構造学習により生成されたグラフ構造が格納され、パラメタフィールド６７Ｄには、パラメタ学習により生成された条件付き確率表又は条件付き確率密度関数のパラメタが格納される。なおシステムモデルが、構造学習により生成されたグラフ構造と、パラメタ学習により生成された条件付き確率表又は条件付き確率密度関数のパラメタ群とからなることは上述の通りである。従って、グラフ構造フィールド６７Ｃ及びパラメタフィールド６７Ｄに、対応するシステムモデルの実体が格納されることになる。
　ただし、これらグラフ構造やパラメタは、テーブルに直接格納するには適さない形でメモリ３（図１）上に存在することがある。この場合、テーブルには各々へのポインタを格納しても良い。本実施の形態では、説明を容易とするためにシステムモデルリポジトリ６７の構造としてテーブル形式を採用しているが、オブジェクトデータベースやグラフデータベースなど、他のデータ構造をシステムモデルリポジトリ６７の構造として採用しても良い。また、別途用意するコンテンツリポジトリや構成管理ツール等の機能を利用したり、単にファイルシステムに格納するようにしても良い。どのような態様であれ、システムモデルのグラフ構造をパラメタから独立して取得できるよう構成するのが望ましい。
（１－４－４）予測モデルリポジトリの構成
　一方、図１４は、予測モデルリポジトリ６９（図４）の構成例を示す。この予測モデルリポジトリ６９には、予測部６４（図４）が実行する時系列予測処理で用いる予測モデル（時系列予測モデル）が格納される。本実施の形態の予測モデルリポジトリ６９は、図１４からも明らかなように、少なくともＩＤフィールド６９Ａ、アルゴリズムフィールド６９Ｂ及び過去データ期間フィールド６９Ｃを備えるテーブル構造を有する。
　そしてＩＤフィールド６９Ａには、各予測モデルにそれぞれ付与されたその予測モデルに固有の識別子（予測モデルＩＤ）が格納される。またアルゴリズムフィールド６９Ｂには、対応する予測モデルの構築に用いるアルゴリズムのアルゴリズム名が格納され、過去データ期間フィールド６９Ｃには、時系列予測処理において使用する過去データの時間的な範囲が格納される。なお予測モデルリポジトリ６９には、これ以外にも予測モデル（時系列予測モデル）の構築に必要なパラメタを記録することができる。
（１－４－５）予測プロファイルの構成
　他方、図１５は、予測プロファイル６８の構成例を示す。この予測プロファイル６８には、予兆エンジン６０がバッチ的に実行すべき障害予兆検知処理の定義が格納される。予測プロファイル６８の各レコード（行）は、それぞれ１つの障害予兆検知処理に対応する。
　この予測プロファイル６８は、図１５に示すように、少なくともＩＤフィールド６８Ａ、システム名フィールド６８Ｂ、システムモデルＩＤフィールド６８Ｃ、予測モデルＩＤフィールド６８Ｄ、既定リードタイムフィールド６８Ｅ、基準指標フィールド６８Ｆ及びターゲット指標フィールド６８Ｇを備えるテーブル構造を有する。
　そしてＩＤフィールド６８Ａには、障害予兆検知処理にそれぞれ付与された識別子（障害予兆検知処理ＩＤ）が格納され、システム名フィールド６８Ｂには、システムプロファイルテーブル７０（図５）に記録されている対応する障害予兆検知処理の対象となる監視対象システム５０（図３）のシステム名が格納される。ただし、システム名フィールド６８Ｂに、対応する監視対象システム５０のシステムＩＤを格納するようにしても良い。
　またシステムモデルＩＤフィールド６８Ｃには、対応する監視対象システム５０について実行する障害予兆検知の確率推論処理で用いるシステムモデル（その監視対象システム５０についてモデル生成部６３が作成し、システムモデルリポジトリ６７（図１３）に格納されたシステムモデル）のシステムモデルＩＤが格納され、予測モデルＩＤフィールド６８Ｄには、対応する監視対象システム５０について実行する障害予兆検知の時系列予測処理で用いる予測モデルの予測モデルＩＤが格納される。
　既定リードタイムフィールド６８Ｅには、その時系列予測処理で用いる既定リードタイムの値が格納される。なお既定リードタイムとは、時系列予測処理で得られる予測値を、過去データの最終時点から何秒後の値とするかを示す値である。さらに基準指標フィールド６８Ｆ及びターゲット指標フィールド６８Ｇには、確率推論処理で用いる基準指標又はターゲット指標の値がそれぞれ格納される。
　予測プロファイル６８に格納された各情報の使用方法については、後述する。予測プロファイル６８の各レコードは、例えば顧客側システム２２の運用管理担当者が入力した情報を用いて作成する。
（１－５）予兆サーバにおいて実行される各種処理
　次に、予兆サーバ４１において実行される各種処理の処理内容について説明する。
（１－５－１）障害予兆検知処理
　図１６は、予兆エンジン６０（図４）において実行される障害予兆検知処理の処理手順の一例を示す。本実施の形態の障害予兆検知処理は、時系列予測によってある性能指標（基準指標）の将来の値を取得し、次いでその値をエビデンスとしてベイジアンネットワークによる確率推論を行う、という手順で行われる。
　実際上、予兆エンジン６０では、障害予兆検知処理の実行時、まず予測部６４（図４）が、予測プロファイル６８に格納された基準指標の計測値をデータ記憶部６２（図４）から取得し（Ｓ１）、取得した基準指標の計測値をメモリ３（図１）に格納する（Ｓ２）。そして予測部６４は、この後、同じく予測プロファイル６８に記録された予測モデルＩＤ及び既定リードタイムに従って基準指標の将来の値を時系列予測する時系列予測処理を実行する（Ｓ３）。
　続いて、推論部６５が、時系列予測処理によって得られた基準指標の既定リードタイム後の予測値と、予測プロファイル６８に格納されたシステムモデルＩＤ及びターゲット指標に従って確率推論を行い（Ｓ４）、この後、推論部６５が、確率推論によって得た既定リードタイム後のターゲット指標の確率分布を出力する（Ｓ５）。以上により、予兆エンジン６０における障害予兆検知処理が終了する。
　ここで、図１７は、図１６について上述した障害予兆検知処理のステップＳ３において予測部６４により実行される時系列予測処理の具体的な処理内容を示す。
　予測部６４は、障害予兆検知処理のステップＳ３に進むと、この図１７に示す時系列予測処理を開始し、まず、予測プロファイル６８に記録された対応する予測モデルＩＤを取得し、取得した予測モデルＩＤに従って、予測モデルリポジトリ６９から該当するアルゴリズムと時系列予測処理に必要なパラメタを読み出す（Ｓ１０）。
　続いて、予測部６４は、予測モデルリポジトリ６９から過去データ期間を取得すると共に（Ｓ１１）、取得した過去データ期間分の基準指標の計測値を取得し（Ｓ１２）、さらに予測プロファイル６８から既定リードタイムを取得する（Ｓ１３）。
　この後、予測部６４は、以上のようにして得られた時系列予測のアルゴリズム及びパラメタと、計測値及び既定リードタイムとを用いて、時系列予測処理を実行する（Ｓ１４）。そして予測部６４は、この時系列予測処理の結果得られた既定リードタイム後の基準指標の予測値をメモリ３（図１）に格納し（Ｓ１５）、この後、この時系列予測処理を終了する。
　また図１８は、図１６について上述した障害予兆検知処理のステップＳ４における推論部６５の具体的な処理内容を示す。推論部６５は、障害予兆検知処理のステップＳ４に進むと、この図１８に示す確率推論処理を開始し、まず、上述のようにメモリ３（図）に格納された既定リードタイム後の基準指標の予測値を取得する（ステップＳ２０）。
　続いて、推論部６５は、予測プロファイル６８に格納されている対応するシステムモデルのシステムモデルＩＤを取得し、取得したシステムモデルＩＤが付与されたシステムモデルをシステムモデルリポジトリ６７から取得する（Ｓ２１）。また推論部６５は、予測プロファイル６８からターゲット指標を取得する（Ｓ２２）。
　そして、推論部６５は、以上のステップＳ２０～ステップＳ２２で得られた予測値、システムモデル及びターゲット指標を用いて確率分布の推定処理（以下、これを確率分布推定処理と呼ぶ）を実行することにより既定リードタイム後のターゲット指標の確率分布を算出し（Ｓ２３）、この後、この確率推論処理を終了する。
（１－５－２）サブモデル生成処理
　図１９は、予兆エンジン６０（図４）で実行される、サブモデルを生成するための処理（以下、これをサブモデル生成処理と呼ぶ）の手順の一例を示す。本実施の形態の場合、サブモデル生成処理は、監視制御クライアント３２（図４）が送信するサブモデルについての情報提供要求をポータルサーバ４２（図４）を介して予兆サーバ４１が受信したことを契機として、予兆エンジン６０のモデル生成部６３（図４）により実行される。
　実際上、監視制御クライアント３２は、顧客側システム２２の運用管理担当者の操作に応じて、サブモデルの抽出元となるシステムモデルのモデル名及び抽出対象であるアプリケーション５２のアプリケーション名を指定した情報提供要求をポータルサーバ４２（図４）に送信する。そしてポータルサーバ４２は、この情報提供要求を受信すると、当該情報提供要求において指定されたモデル名及びアプリケーション名を指定したサブモデル生成要求を予兆サーバ４１に転送する。
　このサブモデル生成要求を予兆サーバ４１が受信すると、当該予兆サーバ４１の予兆エンジン６０のモデル生成部６３が図１９に示すサブモデル生成処理を開始し、まず、受信したサブモデル生成要求において指定されたシステムモデルをシステムモデルリポジトリ６７（図４）から取得する（Ｓ３０）。
　続いて、モデル生成部６３は、抽出対象であるアプリケーション５２のアプリケーション名を基に、アプリケーションプロファイル７３～７５（図８～図１０）が格納する情報を検索し、該アプリケーション５２の実行に関係するノードを抽出する（Ｓ３１）。この際、同様に他のアプリケーション５２と共有するノードも抽出する（Ｓ３２）。
　次いで、モデル生成部６３は、抽出対象以外のアプリケーション５２の基準指標について、エビデンスとなる予測値を予測部６４から取得し（Ｓ３３）、この後、このようにして取得した情報に基づいて、図１１について上述した手法により不要なアークの削除を行うことで部分グラフ７６（図１２）を抽出する（Ｓ３４）。
　さらにモデル生成部６３は、以上のようにして抽出した部分グラフ７６に基づくサブモデルを生成し、得られたサブモデルをシステムモデルリポジトリ６７（図４）に格納した後（Ｓ３５）、このサブモデル生成処理を終了する。
　なお予兆エンジン６０では、この後、図１６～図１８について上述した障害予兆検知処理が実行される。この場合、この障害予兆検知処理では、図１８について上述した確率推論処理のステップＳ２１において、システムモデルに代えて上述のサブモデル生成処理により生成されたサブモデルが取得され、当該確率推論処理のステップＳ２３において、このサブモデルを利用して確率分布推定処理を実行することにより既定リードタイム後のターゲット指標の確率分布が算出される。
（１－６）クライアント画面の構成
　図２０は、監視制御クライアント３２（図２）からの要求に応じてポータルサーバ４２（図２）から当該監視制御クライアント３２に送信される情報（障害予兆検知処理の処理結果）に基づき監視制御クライアント３２のＷｅｂブラウザ３６（図２）によりコンソール６（図１）に表示されるクライアント画面８０の表示例を示す。
　クライアント画面８０は、機能メニュー８１、サービス一覧８２、基準指標エリア８３及びネットワークエリア８４を備えて構成される。そして機能メニュー８１は、複数のボタン８１Ａ～８１Ｄを備えており、これらボタン８１Ａ～８１Ｄの１つとして「グラフィカル監視」ボタン８１Ｂが設けられている。
　またサービス一覧８２には、典型的には顧客側システム２２内の監視対象システム５０（図３）及びアプリケーション５２（図３）が階層構造で一覧表示され、これら一覧表示された項目の中から所望する項目に対してマウスクリック操作を行うことにより、その項目を選択することができる。そしてサービス一覧８２では、このようにして１つの項目が選択された場合、その項目が選択されていることを表す状態（以下、これを選択状態と呼ぶ）に表示される。なお、ある項目が選択状態にあることを表す方法としては、その項目に下線を引く、又は、フォントや背景色を周囲と異なったものとする等の手段を用いることができる。なお図２０は、サービス一覧８２に表示された各項目の中からいずれかの監視対象システム（図２０では「システム＃０１」）が選択された場合の表示例である。
　基準指標エリア８３には、選択状態にある項目に対応する監視対象システム５０において収集対象となっている基準指標に関する情報が表示される。具体的に、基準指標エリア８３には、リードタイム表示８５、基準指標ノード８６及び予測値表示８７が表示される。
　リードタイム表示８５は、予測プロファイル６８に格納された既定リードタイムを表示したものであり、対応する監視対象システム５０を対象とする障害予兆検知処理における時系列予測処理が何秒後の予測値を求めて確率推論処理に供しているかを表す。また基準指標ノード８６は、その監視対象システム５０における基準指標を表し、ネットワークグラフ図のノード様に表示される。さらに予測値表示８７は、時系列予測処理により得られた既定リードタイム後の基準指標の予測値を表わし、基準指標ノードの各々との対応関係が明らかであるように表示される。
　またネットワークエリア８４には、例えば図１１に示すような監視対象システム５０をモデル化したネットワークグラフ構造と、ターゲット指標ノード８８、確率値表示８９及び確率分布表示９０とが表示される。
　このうちターゲット指標ノード８８は、対応する監視対象システム５０が含むターゲット指標を表すものであり、ネットワークグラフ図のノード様に表示される。またネットワークグラフ構造では、基準指標ノード８６とターゲット指標ノード８８とを接続するように表示される。
　確率分布表示９０としては、確率推論処理により得られた既定リードタイム後のターゲット指標の確率分布に基づき、該確率分布のヒストグラムが、ターゲット指標のそれぞれとの対応関係が明らかであるように表示される。なおヒストグラムに代えて、直交座標プロットやその他の方式により確率分布を表示するようにしても良い。また、その確率分布からある事象の発生確率を求め、確率値表示８９に表示することもできる。これら確率分布又は確率の表示態様は、運用管理担当者の意図に応じて任意に変更できるよう構成するのが望ましい。
　基準指標エリア８３及びネットワークエリア８４は、クライアント画面８０のサービス一覧８２においていずれかの監視対象システム５０が選択されることを契機として、情報が表示され、又は、その表示内容が更新される。
　実際上、クライアント画面８０のサービス一覧８２においていずれかの監視対象システム５０が選択された場合、監視制御クライアント３２（図４）は、選択された監視対象システム５０を対象としたシステムモデルの情報提供要求を予兆サーバ４１（図４）に送信する。かくして予兆エンジン６０（図４）は、この情報提供要求の受信を契機として、選択された監視対象システム５０を対象とした障害予兆検知処理（図１６～図１８）を実行する。そしてこの障害予兆検知処理の処理結果がポータルサーバ４２を経由して監視制御クライント３２に与えられ、当該障害予兆検知処理の処理結果に基づく情報が基準指標エリア８３及びネットワークエリア８４に表示され、又は、その表示内容が更新される。
　ただし基準指標エリア８３及びネットワークエリア８４の表示内容の更新について任意のタイミングやインターバルを設定できるよう情報処理システム１０を構成しても良い。また、クライアント画面８０の表示内容の更新を画面全体を同期して行う必要はなく、部分的に適宜更新するようにしても良い。
　一方、図２１は、上述のクライアント画面８０において、サービス一覧８２に表示された項目の中からいずれかのアプリケーション５２（図２１では「アプリ＃０１」）が選択された場合の表示例を示す。
　クライアント画面８０のサービス一覧８２においていずれかの監視対象システム５０が選択された場合、図２０について上述したように、選択された監視対象システム５０全体のシステムモデルがネットワークグラフ図としてクライアント画面８０に表示されるのに対して、クライアント画面８０のサービス一覧８２においていずれかのアプリケーション５２が選択された場合には、選択されたアプリケーション（以下、これを選択アプリケーションと呼ぶ）５２のサブモデルがネットワークグラフ図としてクライアント画面８０に表示される。
　実際上、クライアント画面８０のサービス一覧８２においていずれかのアプリケーション５２が選択された場合、監視制御クライアント３２（図４）は、選択アプリケーション５２を対象としたサブモデルの情報提供要求をポータルサーバ４２（図４）に送信する。またポータルサーバ４２は、この情報提供要求を受信すると、指定されたサブモデルについてのサブモデル生成要求を予兆サーバ４１（図４）に送信する。かくして予兆エンジン６０（図４）は、このサブモデル生成要求の受信を契機として、選択アプリケーション５２を対象としたサブモデル生成処理及び障害予兆検知処理を実行する。そしてこれらサブモデル生成処理及び障害予兆検知処理の処理結果がポータルサーバ４２を経由して監視制御クライント３２に与えられ、当該サブモデル生成処理及び障害予兆検知処理の処理結果に基づく情報がクライアント画面８０に表示される。
　また図２１に示すクライアント画面８０では、基準指標エリア８３には、基準指標ノード８６として選択アプリケーション５２に含まれる基準指標のみが表示され、ネットワークエリア８４には、ターゲット指標ノード８８として、選択アプリケーション５２に含まれるターゲット指標のみが表示される。
　このとき基準指標エリア８３には、予測値制御エリア１００も表示される。予測値制御エリア１００には、プルダウンボタン１０１が設けられ、このプルダウンボタン１０１に対するマウスクリック操作を行うことによって、予測モデルの一覧が掲載されたプルダウンリストを表示させることができる。また予測値制御エリア１００には、運用管理担当者が予測値を入力することができるテキストボックス１０２及び再計算ボタン１０３も設けられている。
　そして監視制御クライアント３２は、運用管理担当者が上述のプルダウンリストから時系列予測の予測モデルを選択すると、これに応じた情報提供要求をポータルサーバ４２に送信する。またポータルサーバ４２は、この情報提供要求を受信すると、当該情報提供要求において指定されたサブモデル及び予測モデルを指定したサブモデル生成要求を予兆サーバ４１に送信する。かくしてこのサブモデル生成要求を受信した予兆サーバ４１の予兆エンジン６０（図４）は、現在の予測モデルに代えて、サブモデル生成要求において指定された予測モデルを使用して障害予兆検知処理（図１６～図１８）を実行し、その結果をポータルサーバ４２を介して監視制御クライアント３２に送信する。かくして、かかる障害予兆検知処理の処理結果がクライアント画面８０に表示される。
　また監視制御クライアント３２は、運用管理担当者が上述のテキストボックス１０２に予測値を入力し再計算ボタン１０３を押下すると、これに応じた情報提供要求をポータルサーバ４２に送信する。またポータルサーバ４２は、この情報提供要求を受信すると、当該情報提供要求において指定された予測値を指定したサブモデル生成要求を予兆サーバ４１に送信する。かくしてこのサブモデル生成要求を受信した予兆サーバ４１の予兆エンジン６０は、時系列予測処理を実行することなく、サブモデル生成要求において指定されたサブモデル及び予測値をエビデンスと設定して確率推論処理を実行し、その結果をポータルサーバ４２を介して監視制御クライアント３２に送信する。この結果、かかる確率推論処理（図１８）の処理結果がクライアント画面８０に表示される。
（１－７）本実施の形態の効果
　以上のように本実施の形態の情報処理システム１０では、サービス提供者側システム２４の予兆サーバ４１において、予め生成した監視対象システム５０のシステムモデルを利用して、顧客側システム２２の運用管理担当者により指定されたアプリケーションの実行に関与するノードのみからなるサブモデルを生成し、生成したサブモデルに基づいてターゲット指標の将来の値を確率推論により算出する。
　この場合、かかるサブモデルはシステムモデルと比してノード数が少なく、従って、当該サブモデルを利用した確率推論処理は、システムモデルを利用した確率推論処理に比べて格段的に少ない計算量で処理を行うことができる。
　かくするにつき、本情報処理システム１０によれば、アプリケーションごとのターゲット指標の将来の値を迅速に求めることができ、障害予兆検知処理の処理結果を迅速に顧客側システムの運用管理担当者に提供することができる。
（２）第２の実施の形態
　第１の実施の形態では、予兆サーバ４１が図８～図１０について上述したアプリケーションプロファイルとして記憶する情報（アプリケーション業務サーバ対応テーブル７３、アプリケーション指標テーブル７４及びアプリケーションノードテーブル７５にそれぞれ格納された情報）を基にアプリケーション境界を判定するシステム運用管理方式について説明した。
　このシステム運用管理方式は、アプリケーションプロファイルが、アプリケーション５２（図３）に関連する業務サーバ３０（図２）の業務サーバ名と、指標名とについて、アプリケーション境界を判定するに十分な情報を格納していることを前提としている。しかしながら、現実のシステム運用においては、十分でないことがあり得る。
　そこで本実施の形態では、ノードに対応する計測値の時系列データのメタ情報を使用するシステム運用管理方式について説明する。時系列データのメタ情報とは、例えばデータの収集を開始した時期についての情報、又は、データの収集が一時的に中断していた期間についての情報であるが、これらに限定されるものではない。
　すなわち、アプリケーション５２との対応が不明であるノードについて、そのメタ情報を取得する。次いで、メタ情報が一致又は類似する他のノードと共通のアプリケーション５２に対応すると判定する。以下、このような本実施の形態のシステム運用管理方式について説明する。
　図２において、１１０は全体として第２の実施の形態による情報処理システムを示す。この情報処理システム１１０は、サービス提供者側システム１１１（図２）における図４に示す予兆サーバ１１２の予兆エンジン１１３のモデル生成部１１４により実行されるサブモデル生成処理の処理内容が異なる点を除いて第１の実施の形態による情報処理システム１０と同様に構成されている。
　図２２は、かかるモデル生成部１１４により実行される本実施の形態のサブモデル生成処理の具体的な処理手順を示す。モデル生成部１１４は、監視制御クライアント３２（図４）からの情報提示要求に応じてポータルサーバ４２（図４）から送信されるサブモデル生成要求を予兆サーバ１１２が受信すると、この図２２に示すサブモデル生成処理を開始し、まず、受信したサブモデル生成要求において指定されたモデル名のシステムモデルをシステムモデルリポジトリ６７（図４）から取得する（Ｓ４０）。
　続いて、モデル生成部１１４は、アプリケーションプロファイルに格納された情報を基に、アプリケーション５２の実行に関係するノードを抽出し（Ｓ４１）、この後、監視対象システム５０の全てのノードがアプリケーション５２と対応付けられているかを判定する（Ｓ４２）。
　そしてモデル生成部１１４は、この判定で肯定結果を得ると、ステップＳ４４～ステップＳ４７を図１３について上述した第１の実施の形態によるサブモデル生成処理のステップＳ３～ステップＳ６と同様に処理し、この後、このサブモデル生成処理を終了する。
　これに対してモデル生成部１１４は、ステップＳ４２の判定で否定結果を得ると、ノードに対応する計測値のメタ情報を取得する。典型的には、その計測値を収集した期間に関する情報である。そして、モデル生成部１１４は、アプリケーション５２との対応が判明しているノードのメタ情報と、判明していないノードのメタ情報を比較し、類似する場合は同一のアプリケーション５２に関係するものと判定する（Ｓ４３）。比較の方法としては、例えばｋ近傍法のような統計的分類法を使用することができる。
　そしてモデル生成部１１４は、この後、ステップＳ４４～ステップＳ４７を図１３について上述した第１の実施の形態によるサブモデル生成処理のステップＳ３～ステップＳ６と同様に処理し、この後、このサブモデル生成処理を終了する。
　以上のような本実施の形態の情報処理システム１１０によれば、予兆サーバ１１２が保持するアプリケーションプロファイルが、アプリケーション境界を判定するに十分な情報を格納していない場合においても、モデル生成部１１４が要求されたアプリケーション５２の実行に関連するノードのみからなるサブモデルを生成することができる。従って、本情報処理システム１１０によれば、第１の実施の形態により得られる効果に加えて、より柔軟性の高い情報処理システムを実現することができる。
（３）第３の実施の形態
　第２の実施の形態では、アプリケーションプロファイルがアプリケーション境界を判定するのに十分な情報を格納していない状況に際して、時系列データのメタ情報を使用する構成について説明した。一方で、メタ情報を使用する方式の場合、判定の曖昧さや不確実さの影響を排除できない。例えばデータ収集開始時期の僅かな異同や、偶然の一致により判定を誤る可能性を排除できない。
　そこで本実施の形態では、システムモデルのグラフ構造を使用してノード及びアプリケーションの対応関係を判定するよう構成された障害予兆検知方式について説明する。すなわち、基準指標及びターゲット指標についてその対応するアプリケーション５２が判明していることを前提に、両者を結ぶ全経路を導出し、その経路上にあるものを当該アプリケーション５２と関係するものとみなす。以下、このような本実施の形態の障害予兆検知方式について説明する。
　図２において、１２０は全体として第３の実施の形態による情報処理システムを示す。この情報処理システム１２０は、サービス提供者側システム１２１における図４に示す予兆サーバ１２２の予兆エンジン１２３のモデル生成部１２４により実行されるサブモデル生成処理の処理内容が異なる点を除いて第２の実施の形態による情報処理システム１１０と同様に構成されている。
　図２３は、かかるモデル生成部１２４により実行される本実施の形態のサブモデル生成処理の具体的な処理手順を示す。モデル生成部１２４は、監視制御クライアント３２（図４）からの情報提示要求に応じてポータルサーバ４２（図４）から送信されるサブモデル生成要求を予兆サーバ１１２が受信すると、この図２２に示すサブモデル生成処理を開始し、ステップＳ５０～ステップＳ５２を図２２について上述した第２の実施の形態によるサブモデル生成処理のステップＳ４０～ステップＳ４２と同様に処理する。
　そしてモデル生成部１２４は、ステップＳ５２の判断で肯定結果を得るとステップＳ５４～ステップＳ５７を図１３について上述した第１の実施の形態によるサブモデル生成処理のステップＳ３～ステップＳ６と同様に処理し、この後、このサブモデル生成処理を終了する。
　これに対してモデル生成部１２４は、ステップＳ５２の判断で否定結果を得ると、アプリケーション指標テーブル７４（図９）に格納された基準指標とターゲット指標との情報を抽出する。そしてモデル生成部１２４は、監視対象システム５０のシステムモデルのグラフ構造において、アプリケーション５２ごとにその基準指標及びターゲット指標間を結ぶ全ての経路を探索する。経路探索には、例えばバックトラッキング法を使用することができる。そしてモデル生成部１２４は、あるアプリケーション５２の基準指標及びターゲット指標間で得られた経路上にあるノードは、該アプリケーション５２に関係するものと判定する（Ｓ５３）。
　そしてモデル生成部１２４は、この後、ステップＳ５４～ステップＳ５７を図１３について上述した第１の実施の形態によるサブモデル生成処理のステップＳ３～ステップＳ６と同様に処理し、この後、このサブモデル生成処理を終了する。
　以上のような本実施の形態の情報処理システム１２０によれば、第２の実施の形態と比してより信頼性高くアプリケーション５２と各ノードとの対応関係を抽出することができる。従って本情報処理システム１２０によれば、より柔軟性及び信頼性の高い情報処理システムを実現することができる。
（４）他の実施の形態
　なお、本発明は上記した実施例に限定されるものではなく、様々な変形例が含まれる。例えば、上述した第１～第３の実施の形態は、本発明を分かりやすく説明するために詳細に説明したものであり、必ずしも説明したすべての構成を備えるものに限定されるものではない。また、ある実施の形態の構成の一部を他の実施の形態の構成に置き換えることが可能であり、また、ある実施の形態の構成に他の実施の形態の構成を加えることも可能である。また、第１～第３の実施の形態の構成の一部について、他の構成の追加・削除・置換をすることが可能である。
　また上述した第１～第３の実施の形態の各構成、機能、処理部及び処理手段等は、それらの一部又は全部を、例えば集積回路で設計する等によりハードウェアで実現しても良い。さらに第１～第３の実施の形態の各構成及び機能等は、プロセッサがそれぞれの機能を実現するプログラムを解釈し、実行することによりソフトウェアで実現しても良い。各機能を実現するプログラム、テーブル及び又はファイル等の情報は、メモリや、ＨＤＤ、ＳＳＤ等の記憶装置、またはＳＤカード、ＤＶＤ－ＲＯＭ（Digital Versatile Disk-Read Only Memory）等の記憶媒体に置くことができる。
　さらに上述した第１～第３の実施の形態の図面においては、説明上必要と考えられる制御線及び情報線のみを示しており、製品上必ずしも全ての制御線や情報線を示しているとは限らない。実際にはほとんどすべての構成が相互に接続されていると考えても良い。
　本発明は、種々の情報処理システムに広く適用することができる。
　１……情報処理装置、２……プロセッサ、３……メモリ、４……ストレージ、２０，１１０，１２０……情報処理システム、２１……顧客サイト、２２……顧客側システム、２３……サービスサイト、２４，１１１，１２１……サービス提供者側システム、３０……業務サーバ、３１……ログ収集装置、３２……監視制御クライアント、３４……アプリケーションプログラム、３５……システム統計情報、３６……Ｗｅｂブラウザ、４１，１１２，１２２……予兆サーバ、４２……ポータルサーバ、５０……監視対象システム、５２，５２Ａ～５２Ｃ……アプリケーション、６０，１１３，１２３……予兆エンジン、６１……データ取得部、６２……データ記憶部、６３，１１４，１２４……モデル生成部、６４……予測部、６５……推論部、６６……システムプロファイル、６７……システムモデルリポジトリ、６８……予測プロファイル、６９……予測モデルリポジトリ、７０……システムプロファイルテーブル、７１，７２……システムモデル、７１Ａ～７１Ｆ，７２Ａ～７２Ｊ……ノード、７３……アプリケーション業務サーバ対応テーブル、７４……アプリケーション指標テーブル、７５……アプリケーションノードテーブル、７６……部分グラフ、８０……クライアント画面、８１……サービス一覧、８３……基準指標エリア、８４……ネットワークエリア、８５……リードタイム表示、８６……基準指標ノード、８７……予測値表示、８８……ターゲット指標ノード、８９……確率値表示、９０……確率分布表示、１００……予測値制御エリア、１０１……プルダウンボタン、１０２……テキストボックス、１０３……再計算ボタン。

Claims (15)

  1. 　１又は複数の計算機から構成される監視対象システムの稼働状況を監視し、当該監視対象システムにおける障害発生の予兆検知を行う監視装置において実行される監視方法において、
    　前記監視装置は、
    　各種処理に必要な情報が格納された記憶装置と、
    　前記記憶装置に格納された前記情報を参照して処理を実行する処理部と
    　を有し、
    　前記処理部が、前記監視対象システムにおける基準指標及びターゲット指標を含む複数の指標についての計測値を取得する第１のステップと、
    　前記処理部が、複数の前記指標の計測値に基づいて、前記基準指標の将来の値でなる予測値を予測する第２のステップと、
    　前記処理部が、前記監視対象システムのシステムモデル及び当該システムモデルの一部であるサブモデルを生成し、前記基準指標の予測値及び生成した前記サブモデルに基づいて、前記ターゲット指標の計測値が所定値又は所定値の範囲となる確率を推論する第３のステップと
    　を備えることを特徴とする監視方法。
  2. 　前記第３のステップにおいて、前記処理部は、
    　前記システムモデルとして、ベイジアンネットワークのモデルを生成する
    　ことを特徴とする請求項１に記載の監視方法。
  3. 　前記第３のステップにおいて、前記処理部は、
    　生成した前記システムモデルに基づいて、前記監視対象システム内の指定されたアプリケーションに対応するサブモデルを生成する
    　ことを特徴とする請求項１に記載の監視方法。
  4. 　前記記憶装置には、
    　予め登録された、前記監視対象システムにおける複数の前記指標と、前記アプリケーションとの対応関係に関する情報が格納され、
    　前記第３のステップにおいて、
    　前記処理部は、前記記憶装置に格納された前記対応関係に関する情報に基づいて、指定された前記アプリケーションに対応する前記指標を抽出し、抽出結果に基づいて前記サブモデルを生成する
    　ことを特徴とする請求項３に記載の監視方法。
  5. 　前記第２のステップにおいて、前記処理部は、
    　予め設定された又は指定された既定リードタイム後の前記基準指標の予測値を予測する
    　ことを特徴とする請求項１に記載の監視方法。
  6. 　前記第３のステップにおいて、前記処理部は、
    　各前記指標のメタ情報を比較し、比較結果に基づいて前記監視対象システム内の指定された前記アプリケーションに対応する前記サブモデルを生成する
    　ことを特徴とする請求項３に記載の監視方法。
  7. 　前記記憶装置には、
    　予め登録された、前記監視対象システムにおける前記アプリケーションごとの前記基準指標及び前記ターゲット指標に関する情報が格納され、
    　前記第３のステップにおいて、
    　前記処理部は、前記記憶装置に格納された前記アプリケーションごとの前記基準指標及び前記ターゲット指標に関する情報に基づいて、生成した前記システムモデルにおいて、指定された前記アプリケーションの前記基準指標及び前記ターゲット指標間を結ぶ全ての経路を探索し、探索結果に基づいて、当該アプリケーション対応する前記サブモデルを生成する
    　ことを特徴とする請求項３に記載の監視方法。
  8. 　１又は複数の計算機から構成される監視対象システムの稼働状況を監視し、当該監視対象システムにおける障害発生の予兆検知を行う監視装置において、
    　各種処理に必要な情報が格納された記憶装置と、
    　前記記憶装置に格納された前記情報を参照して処理を実行する処理部と
    　を有し、
    　前記処理部は、
    　前記監視対象システムにおける基準指標及びターゲット指標を含む複数の指標についての計測値を取得するデータ取得部と、
    　複数の前記指標の計測値に基づいて、前記基準指標の将来の値でなる予測値を予測する予測部と、
    　前記監視対象システムのシステムモデルを生成する一方、当該システムモデルの一部であるサブモデルを生成するモデル生成部と、
    　前記基準指標の予測値及び生成した前記サブモデルに基づいて、前記ターゲット指標の計測値が所定値又は所定値の範囲となる確率を推論する確率推論部と
    　を備える
    　ことを特徴とする監視装置。
  9. 　前記モデル生成部は、
    　前記システムモデルとして、ベイジアンネットワークのモデルを生成する
    　ことを特徴とする請求項８に記載の監視装置。
  10. 　前記モデル生成部は、
    　生成した前記システムモデルに基づいて、前記監視対象システム内の指定されたアプリケーションに対応するサブモデルを生成する
    　ことを特徴とする請求項８に記載の監視装置。
  11. 　前記記憶装置には、
    　予め登録された、前記監視対象システムにおける複数の前記指標と、前記アプリケーションとの対応関係に関する情報格納され、
    　前記モデル生成部は、
    　前記記憶装置に格納された前記対応関係に関する情報に基づいて、指定された前記アプリケーションに対応する前記指標を抽出し、抽出結果に基づいて前記サブモデルを生成する
    　ことを特徴とする請求項１０に記載の監視装置。
  12. 　前記予測部は、
    　予め設定された又は指定された既定リードタイム後の前記基準指標の予測値を予測する
    　ことを特徴とする請求項８に記載の監視装置。
  13. 　前記モデル生成部は、
    　各前記指標のメタ情報を比較し、比較結果に基づいて前記監視対象システム内の指定された前記アプリケーションに対応する前記サブモデルを生成する
    　ことを特徴とする請求項１０に記載の監視装置。
  14. 　前記記憶装置には、
    　予め登録された、前記監視対象システムにおける前記アプリケーションごとの前記基準指標及び前記ターゲット指標に関する情報が格納され、
    　前記モデル生成部は、
    　前記記憶装置に格納された前記アプリケーションごとの前記基準指標及び前記ターゲット指標に関する情報に基づいて、生成した前記システムモデルにおいて、指定された前記アプリケーションの前記基準指標及び前記ターゲット指標間を結ぶ全ての経路を探索し、探索結果に基づいて、当該アプリケーション対応する前記サブモデルを生成する
    　ことを特徴とする請求項１０に記載の監視装置。
  15. 　１又は複数の計算機から構成される監視対象システムの稼働状況を監視し、当該監視対象システムにおける障害発生の予兆検知を行う監視装置に、
    　前記監視対象システムにおける基準指標及びターゲット指標を含む複数の指標についての計測値を取得する第１のステップと、
    　複数の前記指標の計測値に基づいて、前記基準指標の将来の値でなる予測値を予測する第２のステップと、
    　前記監視対象システムのシステムモデル及び当該システムモデルの一部であるサブモデルを生成し、前記基準指標の予測値及び生成した前記サブモデルに基づいて、前記ターゲット指標の計測値が所定値又は所定値の範囲となる確率を推論する第３のステップと
    　を備える処理を実行させることを特徴とする監視プログラムが格納された記憶媒体。
PCT/JP2014/063239 2014-05-19 2014-05-19 監視方法、監視装置及び記憶媒体 WO2015177840A1 (ja)

Priority Applications (1)

Application Number Priority Date Filing Date Title
PCT/JP2014/063239 WO2015177840A1 (ja) 2014-05-19 2014-05-19 監視方法、監視装置及び記憶媒体

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2014/063239 WO2015177840A1 (ja) 2014-05-19 2014-05-19 監視方法、監視装置及び記憶媒体

Publications (1)

Publication Number Publication Date
WO2015177840A1 true WO2015177840A1 (ja) 2015-11-26

Family

ID=54553538

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2014/063239 WO2015177840A1 (ja) 2014-05-19 2014-05-19 監視方法、監視装置及び記憶媒体

Country Status (1)

Country Link
WO (1) WO2015177840A1 (ja)

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220035355A1 (en) * 2020-08-03 2022-02-03 Endress+Hauser Conducta Gmbh+Co. Kg Measurement value processing system and measurement value processing method

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008017269A (ja) * 2006-07-07 2008-01-24 Fuji Xerox Co Ltd 画像形成装置、故障診断システム、故障診断方法、及び故障診断プログラム
US20100318855A1 (en) * 2009-06-16 2010-12-16 Oracle International Corporation Techniques for determining models for performing diagnostics
US20120005534A1 (en) * 2010-07-02 2012-01-05 Fulu Li Method and apparatus for dealing with accumulative behavior of some system observations in a time series for bayesian inference with a static bayesian network model
WO2014109112A1 (ja) * 2013-01-11 2014-07-17 株式会社日立製作所 情報処理システム監視装置、監視方法、及び監視プログラム

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008017269A (ja) * 2006-07-07 2008-01-24 Fuji Xerox Co Ltd 画像形成装置、故障診断システム、故障診断方法、及び故障診断プログラム
US20100318855A1 (en) * 2009-06-16 2010-12-16 Oracle International Corporation Techniques for determining models for performing diagnostics
US20120005534A1 (en) * 2010-07-02 2012-01-05 Fulu Li Method and apparatus for dealing with accumulative behavior of some system observations in a time series for bayesian inference with a static bayesian network model
WO2014109112A1 (ja) * 2013-01-11 2014-07-17 株式会社日立製作所 情報処理システム監視装置、監視方法、及び監視プログラム

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
TOMONORI IKUSE ET AL.: "Reducing Computational Costs of Root Cause Analysis using Dynamic Dependency Graph", IPSJ SIG NOTES, vol. 2011 -OS, no. 7, November 2011 (2011-11-01), pages 1 - 8 *

Cited By (1)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US20220035355A1 (en) * 2020-08-03 2022-02-03 Endress+Hauser Conducta Gmbh+Co. Kg Measurement value processing system and measurement value processing method

Similar Documents

Publication Publication Date Title
US11606379B1 (en) Identifying threat indicators by processing multiple anomalies
US11550829B2 (en) Systems and methods for load balancing in a system providing dynamic indexer discovery
US10698777B2 (en) High availability scheduler for scheduling map-reduce searches based on a leader state
US11704341B2 (en) Search result replication management in a search head cluster
US11258807B2 (en) Anomaly detection based on communication between entities over a network
US11405301B1 (en) Service analyzer interface with composite machine scores
US9588833B2 (en) Information processing system monitoring apparatus, monitoring method, and monitoring program
US9246777B2 (en) Computer program and monitoring apparatus
US8775372B2 (en) Retrieving historical object-related configuration data
US20110289119A1 (en) Methods and systems for monitoring server cloud topology and resources
US20160283304A1 (en) Performance prediction method, performance prediction system and program
US11887015B2 (en) Automatically-generated labels for time series data and numerical lists to use in analytic and machine learning systems
US11429935B2 (en) Retrieving historical tags hierarchy plus related objects
US20170371979A1 (en) Creating and testing a correlation search
US9692654B2 (en) Systems and methods for correlating derived metrics for system activity
JP2007174235A (ja) 属性情報収集装置、属性情報収集方法および属性情報収集プログラム
WO2015177840A1 (ja) 監視方法、監視装置及び記憶媒体
KR20180011183A (ko) 메시지 알림들을 제거하는 방법, 시스템, 및 서버
US11533246B1 (en) Network probe placement optimization
Mdhaffar et al. D-CEP4CMA: a dynamic architecture for cloud performance monitoring and analysis via complex event processing
Rashmi et al. A review on overlapping community detection methodologies

Legal Events

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

Ref document number: 14892301

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 14892301

Country of ref document: EP

Kind code of ref document: A1

NENP Non-entry into the national phase

Ref country code: JP