WO2017134758A1 - 管理計算機及び管理対象計算機の管理方法 - Google Patents

管理計算機及び管理対象計算機の管理方法 Download PDF

Info

Publication number
WO2017134758A1
WO2017134758A1 PCT/JP2016/053126 JP2016053126W WO2017134758A1 WO 2017134758 A1 WO2017134758 A1 WO 2017134758A1 JP 2016053126 W JP2016053126 W JP 2016053126W WO 2017134758 A1 WO2017134758 A1 WO 2017134758A1
Authority
WO
WIPO (PCT)
Prior art keywords
degree
abnormality
usage characteristic
value
determination
Prior art date
Application number
PCT/JP2016/053126
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/JP2016/053126 priority Critical patent/WO2017134758A1/ja
Priority to JP2017565010A priority patent/JP6674481B2/ja
Priority to US15/744,626 priority patent/US10909016B2/en
Publication of WO2017134758A1 publication Critical patent/WO2017134758A1/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
    • 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
    • G06F11/3409—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 for performance assessment
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3003—Monitoring arrangements specially adapted to the computing system or computing system component being monitored
    • G06F11/3006—Monitoring arrangements specially adapted to the computing system or computing system component being monitored where the computing system is distributed, e.g. networked systems, clusters, multiprocessor systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3051—Monitoring arrangements for monitoring the configuration of the computing system or of the computing system component, e.g. monitoring the presence of processing resources, peripherals, I/O links, software programs
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/3055—Monitoring arrangements for monitoring the status of the computing system or of the computing system component, e.g. monitoring if the computing system is on, off, available, not available

Definitions

  • the present invention relates to a management computer and a management method for monitoring the operating status of the system.
  • operation performance the system processing status
  • indexes for grasping the operation performance there are resource usage, throughput, response time, and the like.
  • the resource is a resource necessary for the system to perform processing, and includes a server, a storage device, a network device, and a CPU, a memory, an input / output device, a secondary storage device, and the like of the device.
  • a method for monitoring the operation performance of a system there is conventionally a method of detecting, as an abnormality, a case where the performance index is different from the normal behavior on the basis of measurement data of the normal performance index.
  • Patent Document 1 discloses a method of creating a time-series standard for monitoring items of a single performance index as a method of creating a standard from measurement data of a performance index of a normal system.
  • Patent Document 2 discloses a method of creating a reference by combining monitoring items of a plurality of performance indexes and classifying them by measurement data vector positions.
  • usage characteristics such as the behavior of applications that use system resources
  • the usage characteristics may change. Even if the usage characteristics do not change, the operating performance of the system resources may fluctuate due to problems with the system resources themselves.
  • Appropriate measures to be taken differ depending on whether the fluctuation in operating performance is caused by a problem of the system resource itself or a change in usage characteristics.
  • the measured value related to the performance index during resource operation is in the range that is not included in the data at the time of creating the reference, and if it is detected as abnormal, the administrator First, it is necessary to analyze whether the operating performance is abnormal due to a problem in the system itself or whether the operating performance is abnormal due to a change in usage characteristics. For this reason, there is a problem that a large amount of work is required until an appropriate countermeasure is taken, and a quick countermeasure cannot be performed. It is an object of the present invention to reduce the work burden of investigating the cause and taking countermeasures for an administrator by making an appropriate determination in consideration of changes in usage (usage characteristics) of system resources in operation performance monitoring.
  • the management computer includes a processor and manages the first management target computer accessed from the first application program.
  • the processor acquires a first operation performance that is a value related to the resource performance of the first managed computer and a first usage characteristic that is a value related to access to the first managed computer from the first application program. . Then, the degree of abnormality of the first operating performance and the degree of abnormality of the first usage characteristic are calculated, and the first degree of abnormality of the first usage characteristic and the calculated degree of abnormality of the first usage characteristic are calculated.
  • the operating status of the management target computer 1 is notified.
  • the burden of analyzing the cause of an administrator is reduced by appropriately determining whether or not a change in usage (usage characteristics) of a resource is a cause, and appropriate measures to be taken are quickly determined. I can do it.
  • Example 1 of this invention It is a figure which shows the concept of the system in Example 1 of this invention. It is a figure which shows the hardware constitutions of the management server in Example 1 of this invention. It is a figure which shows the structure of the functional module of the performance monitoring program in Example 1 of this invention. It is a figure which shows the flowchart of the performance monitoring program in Example 1 of this invention. It is a figure which shows the table structure of the operation performance monitoring item management table which manages the monitoring item regarding the operation performance in Example 1 of this invention. It is a figure which shows the table structure of the usage characteristic monitoring item management table which manages the monitoring item regarding the usage characteristic in Example 1 of this invention. It is a figure which shows the mechanism which manages the reference data in Example 1 of this invention.
  • Example 1 of this invention It is a figure which shows the flowchart of the operation condition diagnosis process of the performance monitoring program in Example 1 of this invention. It is a figure which shows the table structure of the monitoring data management table which manages the monitoring object data in Example 1 of this invention in time series. It is a figure which shows the structure of the determination method in Example 1 of this invention. It is a figure which shows the structure of the determination method using the data for a fixed period in Example 1 of this invention. It is a figure which shows the table structure of the notification management table which manages the notification content according to the determination result in Example 1 of this invention. It is a figure which shows the example of the output screen in Example 1 of this invention. It is a figure which shows the outline
  • FIG. 1 is a conceptual diagram of a computer system for implementing the present invention.
  • Each includes one or more user computers 100, a server 102, a network device 103, a storage device 104, and a management server 101 for managing the system.
  • the application program 106 runs on one or more user computers 100, and each of the one or more servers is connected to a network.
  • the server 102 and the storage apparatus 104 are connected via the network device 103 in FIG. 1, but may be directly connected.
  • the management server 101 is connected to each device via a management network (not shown).
  • middleware 105 such as a database (DB) execution base (hereinafter referred to as a DB server) or an application execution base operates, and the application program 106 accesses the middleware via the Internet or a local network.
  • the application program may run on the same server as the middleware.
  • FIG. 2 shows the hardware configuration of the management server 101.
  • the hardware configuration of the other server 102 is the same.
  • the server and management server may be virtual servers.
  • the performance monitoring program 206 is loaded on the memory 202 of the management server 101 and executed by the CPU 201.
  • the secondary storage device 203 stores data of the table 207 used by the performance monitoring program.
  • an application program is loaded on the memory and executed by the CPU.
  • Each server may be implemented as a virtual machine instead of a physical machine.
  • Fig. 3 shows the functional module configuration of the performance monitoring program.
  • Operational performance information collection unit 301 that collects operating information such as resource usage, which is a performance index of servers, storage devices, etc.
  • usage information collection unit 302 that collects information on access to middleware on the server
  • normal system A monitoring standard creation unit 303 that creates monitoring standards using information collected for a certain period of time during operation, a monitoring standard management table 304 that manages the created monitoring standards, and compares periodic measurement data of operational performance information with the standards.
  • An operational performance abnormality degree calculation unit 305 that calculates an abnormality degree, a usage characteristic abnormality calculation part 306 that calculates an abnormality degree by comparing periodic measurement data of usage information with a reference, and determines a situation from the calculated abnormality degree
  • a situation determination unit 307 and an output unit 308 that outputs a determination result are included.
  • FIG. 4 is a flowchart of the performance monitoring program in the present embodiment, and shows the processing flow of the present embodiment.
  • Each step is executed by a central processing unit (CPU) 201.
  • the monitoring standard creation step S401 a monitoring standard is created for each of the performance information and usage characteristic information collected for a certain period.
  • the operational performance monitoring standard is created based on the operational performance monitoring item management table of FIG. 5, and the usage characteristic monitoring standard is created based on the usage characteristic monitoring item management table of FIG. Therefore, the operation performance monitoring item management table 500 in FIG. 5 and the usage characteristic monitoring item management table 600 in FIG. 6 will be described first.
  • FIG. 5 is a diagram showing the configuration of the operation performance monitoring item management table.
  • a vector ID field 501 for managing a vector in which a plurality of monitoring items are combined, a target field 502 indicating the type of collection target apparatus or software, and a monitoring item field 503 indicating a monitoring target item name are configured.
  • a monitoring item is an item that periodically collects information from a target device such as a server, middleware on the server, a storage device, and a network device, and software, and a vector is managed by a combination of one or more monitoring items.
  • These monitoring items are values related to the resource performance of the monitoring target device, and indicate how much the resources of the monitoring target device are currently performing their processing capabilities. In the example of FIG.
  • a vector with a vector ID of 1 manages a CPU usage rate and a memory usage rate, which are monitoring items, using a collection target as a server.
  • Combinations of vector IDs 501 may be defined in advance by the system, or may be set by addition or deletion by a user using the management server. The combinations of vector IDs 501 shown in FIG. 5 are merely examples.
  • FIG. 6 is a diagram showing the configuration of the usage characteristic monitoring item management table.
  • a vector ID field 601 for managing a vector in which a plurality of monitoring items are combined, a target field 602 indicating the type of apparatus or software to be collected, and a monitoring item field 603 are configured.
  • a vector with a vector ID of 1 manages the number of sessions and the number of transactions, which are monitoring items, with the collection target as a server.
  • These monitoring items are values relating to access to the server from an application program running on the user computer.
  • the monitoring items are set in advance by the system, or set by a user using the management server by adding or deleting, and managed as one or more vectors.
  • the combinations of vector IDs 601 shown in FIG. 6 are merely examples.
  • a monitoring item in the monitoring item field 503 of the operation performance monitoring item management table of FIG. 5 information for a certain period is collected.
  • the period here may be fixed in advance in the system, or may be set by an administrator who uses the management server.
  • the data of each monitoring item is regarded as data at the same monitoring time or within the monitoring time error, and is expressed as a multi-dimensional vector value with each monitoring item as an axis.
  • the data x1 of the CPU usage rate in the monitoring item field 503 of 10:00:00 and the data y1 of the memory usage rate of 10:00:10 are one vector.
  • Data for a certain period expressed as a vector value is classified into one or more groups.
  • the classification method is, for example, a K-means method in which close values are classified into a plurality of circles (in the case of two dimensions, a sphere in the case of three dimensions or more), and the center coordinates and radius of the group are extracted.
  • the group here is called a cluster.
  • the classification result is stored in the monitoring reference management table in FIG. The monitoring reference management table will be described later.
  • notification is necessary based on the result (S403). This determination is made when there is an abnormal state in the determination result of each vector based on the result of measurement data for one time (S404). Alternatively, notification may be made when an abnormal state continues n times or more based on the past plural (m) measurement data results. The number of times m and n is defined by the system or specified by the user.
  • the operation diagnosis process is a process flow for each measurement data collection, but it may be performed for a certain period of time.
  • the determination of whether notification is necessary may be a method in which the determination results of data for a certain period are collected for each vector, and only notifications of the most types are output.
  • the monitoring standard determines whether or not it is necessary to recreate the monitoring standard (S405). If the abnormality level of the usage characteristic data is equal to or greater than the threshold value, it is determined whether the abnormality level of the past multiple (m) usage characteristic data is equal to or more than the threshold value n times. If the threshold value is greater than or equal to n times, it is necessary to re-create the monitoring standard, and the monitoring standard is created again for both operating performance and usage characteristics.
  • FIG. 7 shows the mechanism for managing the created cluster that is the reference for monitoring.
  • FIG. 7A is a diagram showing a configuration of a monitoring reference management table for managing the created monitoring reference.
  • Cluster ID field 701 for identifying a cluster extracted by the monitoring reference creation process
  • center coordinate field 702 managed by numerical values for each axis constituting a vector for the center coordinate for each cluster
  • cluster circle (sphere in 3D or more) Is composed of a radius field 703 for managing the radius of the.
  • FIG. 7 shows an example of a two-dimensional vector based on two monitoring items, but in the case of three or more dimensions, the axis field of the center coordinate is adjusted to the number of dimensions.
  • FIG. 7B is a diagram illustrating an example of a reference cluster created from two monitoring items of the CPU usage rate and the memory usage rate on a two-dimensional graph. Here, four clusters are created and given IDs.
  • FIG. 8 is a flowchart showing the flow of the operation status diagnosis process. Each step is executed by a central processing unit (CPU) 201.
  • CPU central processing unit
  • a numerical value indicating the degree of deviation from the monitoring standard compared to the monitoring standard (hereinafter, this numerical value is referred to as the degree of abnormality) is calculated (S801).
  • the degree of abnormality is calculated based on the distance between the measurement data and the center coordinate by specifying the cluster having the closest distance between the measurement data and the center coordinate, normalizing the radius of the cluster to 1. The further away the measured data is from the cluster, the greater the degree of abnormality.
  • the management server manages the threshold for the degree of abnormality as a criterion for notifying the user.
  • the threshold value may be the same value or different value between the operation performance monitoring vector and the usage characteristic monitoring vector.
  • the threshold value may be defined in advance by the system, or may be set by the user.
  • the degree of abnormality is calculated from the measurement data for each vector (S802).
  • the abnormality level of the usage characteristic data is first compared with the threshold value (S803), and then the threshold value is compared with the abnormality level of the operation performance data (S804, S805).
  • the state is determined (S806 to S809).
  • the operating status of the resource is defined under the following conditions.
  • -Normal state When the usage characteristics are below the threshold and the operating performance is below the threshold-Warning state: When the usage characteristics are below the threshold and the operating performance is above the threshold-Attention required: The usage characteristics are above the threshold and the operating performance is above the threshold -Attention (low risk) state: When the usage characteristics are equal to or greater than the threshold and the operation performance is less than the threshold, the state determination by comparison with this threshold is repeated for all vectors for operation performance monitoring (S810, S811).
  • FIG. 9 shows a configuration of a monitoring data management table for managing measurement data of monitoring items.
  • the measured data and the calculated degree of abnormality are managed for each time.
  • the measurement data with respect to the time is regarded as data at the time within the monitoring time error. For example, assuming that the monitoring time error is less than ⁇ 30 seconds, the measurement data at 10:00 is assumed to be data having a monitoring time of 09:59:31 to 10:00:30.
  • FIG. 10 is a diagram showing a mechanism of operation status diagnosis.
  • FIG. 10A is an example of a usage characteristic monitoring vector.
  • the number of transactions indicating the use of the DB server is the x-axis, and the number of sessions is the y-axis.
  • Each circle indicates a cluster which is a monitoring standard.
  • FIG. 10B is an example of an operation performance monitoring vector.
  • the CPU usage rate is the x-axis and the memory usage rate is the y-axis.
  • Circles on each vector indicate measurement data. Circles # 1 to # 4 indicate that they are data at the same time. For example, from the data managed in FIG. 9, when the measurement data at time T1 is # 1, the data (1001) of # 1 in FIG. is there.
  • the data # 1 (1002) has an abnormality degree of a11 and is above the threshold, and is out of the circle of the cluster.
  • FIG. 10 (c) shows the abnormalities of the usage characteristics and operation performance on the x-axis and y-axis of the graph.
  • the degree of abnormality (a1, a11) at the time T1 is plotted at the position of the data 1003. Since this position is the warning range 1004, the state is determined to be a warning.
  • the ranges are normal 1005, attention required 1006, and caution (small risk) 1007, and each state is determined.
  • FIG. 11 is a diagram showing an example of a result of monitoring data for a certain period for a certain operation performance vector.
  • S403 determination of whether notification in the flowchart of FIG. 4 is necessary (S403), when data for a certain period is used, among normal period data, normal state, warning state, caution state, caution (low risk) state The number of determined data is measured, and the state with the largest number of data is notified. For example, as shown in FIG. 11, when there is the most data in the range (1101) in which the degree of abnormality is equal to or greater than the threshold, it is determined that the state needs attention and a notification is output.
  • the operational performance criteria and the usage performance criteria are re-created, and the management server 101 re-creates the operational performance criteria and the usage characteristic criteria stored in the secondary storage device 203. .
  • FIG. 12 is a table for managing notification contents to be output according to the state. It includes a target field 1201 indicating a resource to be monitored, a type field 1203 indicating a message type corresponding to the status field 1202, and a message field 1204 for managing message contents.
  • the normal state is managed with no message (null) and is not output.
  • the message may include a target vector monitoring item or target device.
  • FIG. 13 is a diagram showing an example of an output screen in the present embodiment.
  • the upper level (1301) displays the degree of abnormality of the monitored performance monitoring vector in time series
  • the lower level (1302) displays the output notification as an event list.
  • a message proposing an appropriate countermeasure may be displayed together with the type of notification.
  • the notifications are of different types such as warning (1303) and caution (1304). With these displays, the administrator can identify appropriate countermeasures to be taken according to different notifications, and prompt actions can be taken.
  • FIG. 13 is merely an example of an output screen.
  • the screen of FIG. 11 may be output.
  • notifications can be divided according to appropriate determination as to whether or not a change in the characteristics of the resource user is the cause, and the burden of the separation process on the administrator can be reduced.
  • a DB server is provided to a user's application program in the form of a PaaS (Platform as a Service) in a cloud environment.
  • PaaS Platinum as a Service
  • a cloud environment In monitoring the provided system, if it is detected that the CPU usage rate of the server executing the DB server is different from the usual, for example, the case where the CPU usage increased due to using an inappropriate execution plan on the DB server side
  • This is an abnormality of the resource itself that is, the abnormality of the resource itself, but the case where the number of transactions is larger than usual is an increase in CPU usage due to a change in the usage (usage characteristics) of the resource such as an increase in input.
  • these cannot be distinguished, and the administrator must analyze which case, and appropriate measures cannot be taken promptly.
  • FIG. 14 shows an outline of a system targeted by the present invention in the second embodiment.
  • the same middleware operates on a plurality of servers, and the application program and the server are connected to the load balancer 1401. Access from an application program is distributed to a plurality of middleware and processed by a load distribution device.
  • the distribution to a plurality of middleware may be executed by the user computer 106 or the server 102 having the load distribution software, or by a device other than the user computer 106 or the server 102 having the load distribution software. May be.
  • middleware will be described using an example of a DB server.
  • the DB server shares data by sharing the storage device.
  • the usage characteristics of the application program are acquired from the OS and DB server of each server that is the access destination. Further, a value obtained by adding the measurement data of the monitoring items related to the usage information acquired from each server at the same time is calculated. Note that data whose monitoring time is within a certain error is regarded as measurement data at the same time.
  • a vector for monitoring each of the plurality of DB servers and a vector for monitoring the total value are provided.
  • columns for usage characteristic monitoring are provided for each server.
  • a column for managing the total value of all servers in a distributed configuration and the degree of abnormality in the total value is provided.
  • the operation performance is collected from servers, storage devices, etc., and an operation performance monitoring vector is provided for each device for monitoring.
  • the summation process of measurement data is performed in the monitoring reference creation process (S401) and the operation diagnosis process (S402) in the flowchart of FIG.
  • the monitoring standard a standard for each DB server distributed as a monitoring standard for monitoring usage characteristics and a standard for each application program that is a total value of the distribution to the DB server are created.
  • the degree of abnormality of the usage characteristic for each server and the degree of abnormality of the total value of the usage characteristics of each server are calculated.
  • the degree of abnormality of usage characteristics for each server is calculated from the usage characteristics of each server and the criteria for each DB server.
  • the degree of abnormality of the total usage characteristics of each server is the sum of the usage characteristics for each server and It is calculated from the standard.
  • the calculation method is the same as in Example 1.
  • the degree of abnormality in the usage characteristics of the server is determined for each server. The determination is made by comparing the degree of abnormality of each operational performance. That is, the degree of abnormality of the usage characteristics for each server is calculated from the usage characteristics for each server and the standards for each DB server in step (S801) of FIG.
  • step (S803) it is determined whether the abnormality level of the usage characteristics for each server is less than a threshold value.
  • the other steps in FIG. 8 and the display to the user after the determination are the same as in the first embodiment.
  • a process for determining the degree of abnormality of each operation performance of each server by comparing the degree of abnormality of the usage characteristics of the application program based on the total value of the distributed access. to add. That is, the degree of abnormality of the total value of the usage characteristics of each server is determined from the total value of the usage characteristics of each server and the standard for each application program, which is the total value of the distribution to the DB server in step (S801) of FIG. calculate. In step (S803), it is determined whether the degree of abnormality of the total value of the usage characteristics of each server is less than a threshold value.
  • the other steps in FIG. 8 and the display to the user after the determination are the same as in the first embodiment.
  • the usage characteristics use the total abnormalities, and each storage device Judged against the degree of abnormality in operational performance. That is, the degree of abnormality of the total value of the usage characteristics of each server is determined from the total value of the usage characteristics of each server and the standard for each application program, which is the total value of the distribution to the DB server in step (S801) of FIG. calculate. In step (S803), it is determined whether the degree of abnormality of the total value of the usage characteristics of each server is less than a threshold value.
  • the other steps in FIG. 8 and the display to the user after the determination are the same as in the first embodiment.
  • the storage device operating performance is different from normal (the degree of abnormality is greater than or equal to the threshold), it is possible to perform appropriate notification that determines whether the usage characteristics of the application program are different from normal it can.
  • the usage characteristic data of each server is determined. Data on the degree of abnormality calculated from the total value is used.
  • the monitoring criteria are re-created for the vector of the usage characteristics and each operation performance Is deemed necessary.
  • FIG. 15 shows an outline of a system targeted by the present invention in the third embodiment.
  • the resources of one physical server 1501 are virtualized by a hypervisor 1502 that is virtualization platform software and used by a plurality of virtual machines 1503.
  • an IaaS Infrastructure as a Service
  • the physical server 1501 is connected to the storage apparatus 104 via the network device 103 as in FIG. 1, but may be directly connected.
  • the management server 101 is connected to each device as shown in FIG. 15 via a management network (not shown).
  • Application programs run on the virtual machine 1503, but individual application programs are not monitored here, and information on the use of physical server resources for each virtual machine is acquired as usage characteristic monitoring vector information To do.
  • the usage characteristic monitoring item management table of FIG. 6 manages combinations of CPU usage rates and memory usage rates, which are monitoring items of virtual machines, with the target being a virtual machine.
  • the operation performance information information on operation is collected from the device as in the first embodiment.
  • the hypervisor of the physical server is targeted, and items related to resource competition and the like are collected as information on the operation performance monitoring vector. For example, a value indicating the percentage of time when execution of the virtual machine could not be scheduled by the CPU, memory swap usage, and the like are set.
  • the target is a hypervisor and these items are managed in combination.
  • Measured data is managed by providing a column for usage characteristic monitoring for each virtual machine in the monitoring data management table of FIG.
  • the operational performance monitoring column is managed by the monitoring item column for the hypervisor.
  • the monitoring reference creation process (S401) is the same as in the first embodiment.
  • a monitoring standard is created from past measurement data for usage characteristic data and hypervisor operational performance data for each virtual machine.
  • the degree of abnormality is calculated for each usage characteristic data and hypervisor operation performance data for each virtual machine.
  • the degree of abnormality of each usage performance data is compared with the degree of abnormality of one usage characteristic data in the same time period. The difference is that a plurality of usage characteristic data in the same time zone are compared with the degree of abnormality of one operational performance data.
  • FIG. 16 is a diagram showing a mechanism for determining data at a certain time in the present embodiment.
  • the degree of abnormality in the performance data of the hypervisor is represented on the y axis
  • the degree of abnormality in the usage characteristic data of each virtual machine is represented on the x axis.
  • Circles indicate coordinates representing the degree of abnormality at a certain time as a vector.
  • the degree of abnormality of the operation performance data is the same at the same time
  • FIG. 16 shows data 1601 at time T1 and data 1602 at time T2.
  • the operation performance data of the hypervisor is different from normal (the degree of abnormality is greater than or equal to the threshold) and the usage characteristic data of some virtual machines is different from normal (the degree of abnormality is greater than or equal to the threshold) (1602), This is the behavior of the hypervisor due to changes in usage characteristics, and is determined to be a state of caution.
  • the virtual machine having the abnormality degree of the usage characteristic data equal to or higher than the threshold is a specific ratio or more with respect to the total number, or one virtual machine having the abnormality degree equal to or higher than the threshold may be determined. Even if it is, it may be judged as a state of caution. Judgment conditions for the proportion of virtual machines included in the range are defined in advance by the system or the administrator. Even if the performance data of the hypervisor is less than the threshold, whether it is normal or caution (low risk) status depends on the abnormalities of the usage characteristic data for each virtual machine and the percentage of virtual machines included in each range. judge.
  • the message at the time of notification is the same as in FIG. 12 of the first embodiment, and the target is managed as a hypervisor for each state and notified according to the determination.
  • notification it is good also as not only the method of notifying when the judgment result of one time is other than the normal time but also a method of notifying the state containing the most judgment results about the judgment result of a fixed period. For example, if the determination results from time T1 to T10 are warnings at T1 and attention is required from T2 to T10, notification is made as a warning state after determination at T10.
  • the notification of the determined state is notified including the virtual machine information.
  • the determination state is a warning
  • the degree of abnormality of the usage characteristic data of each virtual machine is less than the threshold value, and “no virtual machine affects the operation performance” is set.
  • the judgment state is cautionary, there is a virtual machine whose usage characteristic data abnormality degree is equal to or greater than a threshold, and information such as “virtual machines whose usage characteristics have changed are VM1, VM2, VM3” is given to the notification.
  • the display to the user is not limited to the notification shown in FIG. 12.
  • the management computer displays the screen shown in FIG. 16, and each virtual machine such as VM1, VM2, and VM3 is displayed on each data on the screen shown in FIG. You may show to a user correspondingly. As a result, the user can grasp the degree of abnormality of the virtual machine and its usage characteristics that affect the operating performance.
  • the determination processing (S405) in the flowchart of FIG. 4 has a plurality of usage characteristic data for each virtual machine.
  • the number of virtual machines that have become more than a specific percentage defined by the system it is determined that the standard needs to be recreated. Re-create the monitoring criteria for the usage characteristics data of each virtual machine and the performance performance data of the hypervisor.
  • the present embodiment is not limited to the configuration of FIG. 15, and can be applied to the case where a plurality of user computers 100 exist in FIG. 1 and the server 102 is accessed from a plurality of application programs 106.
  • a value related to access to the server 102 from the application program 106 shown in FIG. 6 is managed.
  • the information that the usage characteristic acquires as monitoring vector information is not information that uses a physical server for each virtual machine, but is a value related to access to the server 102 for each of a plurality of application programs 106.
  • the operation performance information is the same as that in the first embodiment, and the measurement data is managed by providing a column for use characteristic monitoring for each application program (AP) 106 in the monitoring data management table of FIG.
  • the monitoring reference creation process (S401) is the same as that of the first embodiment.
  • a monitoring reference is created from past measurement data for the usage characteristic data for each application program 106 and the performance data for the monitoring items shown in FIG.
  • the degree of abnormality is calculated for each of the usage characteristic data for each application program 106 and the operation performance data of the server 105 and the storage 104.
  • a plurality of usage characteristic data in the same time zone are compared with the degree of abnormality of one operation performance data as in the case of the configuration of FIG.
  • 16 is different from the configuration of FIG. 15 in that the abnormality level of the operational performance data of the server 102 or the storage apparatus 104 is represented on the y axis and the abnormality degree of the usage characteristic data of each application program 106 is represented on the x axis.
  • the operation performance data of the server 102 or the storage device 104 is different from normal (abnormality is greater than or equal to a threshold value), and all of the plurality of usage characteristics are the same usage characteristics as normal.
  • the degree of abnormality is less than the threshold (1601)
  • the operating status of the server 102 or the storage device 104 is determined as a warning state.
  • the use characteristic is It is the behavior of the server 102 or the storage apparatus 104 due to the change, and is determined to be a state of caution.
  • the number of application programs 106 whose usage characteristic data abnormality level is equal to or greater than a threshold is equal to or greater than a specific ratio with respect to the total number, it may be determined that a state of caution is required. Even if there is one, it may be determined that a state of caution is required.
  • the determination condition for the ratio of the application program 106 included in the range is defined in advance by the system or the administrator. Even when the performance data of the hypervisor is less than the threshold, whether it is normal or attention (low risk) is the same depending on the degree of abnormality of the usage characteristic data of the application program 106 and the ratio of the application program 106 included in each range. Judgment.
  • the target is managed by the state as the server 102 or the storage device 104, and notified according to the determination.
  • notification it is good also as not only the method of notifying when the judgment result of one time is other than the normal time but also a method of notifying the state containing the most judgment results about the judgment result of a fixed period. For example, if the determination results from time T1 to T10 are warnings at T1 and attention is required from T2 to T10, notification is made as a warning state after determination at T10.
  • the notification of the determined state is notified including the information of the application program 106.
  • the determination state is a warning
  • the abnormalities of the usage characteristic data of each application program 106 are all less than the threshold value, and “there is no application program 106 that affects the operation performance”.
  • the judgment state is cautionary, there is an application program 106 whose degree of abnormality in the usage characteristic data is equal to or greater than the threshold, and information such as “Application program 106 whose usage characteristics have changed is AP1, AP2, AP3” is given to the notification. To do.
  • the display to the user is not limited to the notification shown in FIG. 12.
  • the management computer displays the screen shown in FIG. 16, and the application program 106 such as AP1, AP2, AP3 corresponds to each data on the screen shown in FIG. It may be shown to the user.
  • the user can grasp the degree of abnormality of the application program 106 and its usage characteristics that has an influence on the operating performance.
  • the determination processing (S405) in the flowchart of FIG. 4 has a plurality of usage characteristic data for each application program 106.
  • the application program 106 whose degree of abnormality is equal to or higher than a threshold value exceeds a specific ratio defined by the system, it is determined that the reference needs to be recreated.
  • Monitoring criteria are re-created for the usage characteristic data of each application program 106 and the operation performance data of the server 102 and the storage apparatus 104, respectively.
  • the resources of the server 102 and the storage apparatus 104 can be obtained by comparing the operation performance of the server 102 and the storage apparatus 104 on the resource providing side with the usage characteristics that are values related to access to the server 102 from each application program 106. Therefore, it is possible to determine whether the application program 106 having changed usage characteristics has an influence, and perform appropriate notification. In addition, the administrator can easily determine which application program 106 is influencing when the operation performance is different from the normal performance.
  • management server 102 server 103: network device 104: storage device 105: execution platform software 106: application program

Landscapes

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

Abstract

過去の平常時の挙動に基づいてパフォーマンスの監視を行う場合、平常時と異なるパフォーマンスの挙動を検出に際して、リソースの使い方が変動するシステムにおいては、平常時と異なる使い方が原因なのかどうかを判別することが難しい。 システム稼動時のパフォーマンスを測定して平常稼動時と異なるパフォーマンスを検出する手段と、システムの使用に関する特性を測定して平常稼動時と異なる特性であることを検出する手段と、パフォーマンス情報と使用に関する特性情報を照合する手段により、パフォーマンスの挙動がシステムの使用に関する特性の変化であるかどうかを判別し、監視精度の向上を図る。

Description

管理計算機及び管理対象計算機の管理方法
　本発明はシステムの稼働時の状況を監視する管理計算機および管理方法に関するものである。
　システムの運用管理においては、システムの稼動時にシステムの処理能力が低下することで利用者に影響を与えることを防ぐために、システムの処理の状況（以降では稼動性能と呼ぶ）を監視することで、稼働性能の異常に早期に気づき、事前に適切な対処する必要がある。稼動性能を把握するための指標としては、リソース使用量、スループット、レスポンスタイム等がある。
　ここでリソースとはシステムが処理を行うために必要な資源であって、システムを構成するサーバ、ストレージ装置、ネットワーク機器および、それら装置のCPU、メモリ、入出力装置、二次記憶装置等である。システムの稼動性能監視の方法としては、従来、平常時の性能指標の測定データを基準として、性能指標が平常時のふるまいと異なる場合を異常として検出する方法がある。
　平常時のシステムの性能指標の測定データから基準を作成する方法として、単一の性能指標の監視項目について時系列の基準を作成する方法が［特許文献１］に示されている。また、複数の性能指標の監視項目を組合せ、測定データのベクトル位置で分類することにより基準を作成する方法が［特許文献２］に示されている。
特開2001-142746号公報 特開2012-242985号公報
　クラウド環境のようにシステムをユーザに提供する場合、システムのリソースを使用するアプリケーションの挙動などのシステムのリソースの使い方（以降では使用特性と呼ぶ）が変化することがある。システムリソースの稼動性能は使用特性が変化していなくても、システムリソース自体の問題によって変動することもあれば、システムリソース自体に問題がなくとも、使用特性が変化したことに依存して変動することもある。そして、稼働性能の変動がシステムリソース自体の問題によるものなのか、使用特性の変化によるものなのかによって、とるべき適切な対処が異なる。しかし、前記の従来技術では、使用特性の変化は考慮されていないため、リソースの稼動時の性能指標に関する測定値が基準作成時のデータにない範囲となり、異常として検出された場合、管理者が、システム自体の問題による稼働性能の異常なのか、使用特性の変化による稼働性能の異常なのかをまず分析する必要ある。そのため、適切な対処をとるまでにかかる作業負担が多く、迅速な対処が行えないという課題がある。 
　本発明は稼働性能の監視においてシステムリソースの使い方（使用特性）の変化を考慮した適切な判定を行うことで、管理者の原因調査や対策にかかる作業負担を軽減することを目的とする。
　管理計算機は、プロセッサを含み、第１のアプリケーションプログラムからアクセスされる第１の管理対象計算機を管理する。プロセッサは、第１の管理対象計算機のリソース性能に関する値である第１の稼働性能と第１のアプリケーションプログラムから第１の管理対象計算機へのアクセスに関する値である第１の使用特性とを取得する。そして、第１の稼働性能の異常度と第１の使用特性の異常度とを算出し、算出された第１の稼働性能の異常度と算出された第１の使用特性の異常度とから第１の管理対象計算機の稼働状況を通知する。
　本発明によれば、稼働性能の監視において、リソースの使い方（使用特性）の変動が原因かどうかの適切な判定によって管理者の原因分析負担が軽減され、取るべき適切な措置を迅速に決定することが出来る。
本発明の実施例１におけるシステムの概念を示す図である。 本発明の実施例１における管理サーバのハードウェア構成を示す図である。 本発明の実施例１における性能監視プログラムの機能モジュールの構成を示す図である。 本発明の実施例１における性能監視プログラムのフローチャートを示す図である。 本発明の実施例１における稼動性能に関する監視項目を管理する稼動性能監視項目管理テーブルのテーブル構成を示す図である。 本発明の実施例１における使用特性に関する監視項目を管理する使用特性監視項目管理テーブルのテーブル構成を示す図である。 本発明の実施例１における基準データを管理する仕組みを示す図である。 本発明の実施例１における性能監視プログラムの稼働状況診断処理のフローチャートを示す図である。 本発明の実施例１における監視対象のデータを時系列に管理する監視データ管理テーブルのテーブル構成を示す図である。 本発明の実施例１における判定方法の仕組みを示す図である。 本発明の実施例１における一定期間分のデータを使用した判定方法の仕組みを示す図である。 本発明の実施例１における判定結果に応じた通知内容を管理する通知管理テーブルのテーブル構成を示す図である。 本発明の実施例１における出力画面の例を示す図である。 本発明の実施例２におけるシステムの概要を示す図である。 本発明の実施例３におけるシステムの概念を示す図である。 本発明の実施例３における一時刻の異常度の例を示す図である。
［第１の実施例］
　図１は本発明を実施するコンピュータシステムの概念図である。それぞれ1台以上のユーザ計算機１００、サーバ１０２、ネットワーク機器１０３、ストレージ装置１０４と、システムを管理するための管理サーバ１０１から構成される。１台以上のユーザ計算機１００ではアプリケーションプログラム１０６が動作し、１台以上のサーバはそれぞれネットワークに接続される。またサーバ１０２とストレージ装置１０４は、図１ではネットワーク機器１０３経由で接続しているが、直接接続であってもよい。管理サーバ１０１は管理用ネットワーク（図示せず）を介して各装置と接続される。サーバでは例えばデータベース（DB）実行基盤（以降ではDBサーバと呼ぶ）やアプリケーション実行基盤といったミドルウェア１０５が動作し、アプリケーションプログラム１０６はインターネットまたはローカルネットワーク経由でミドルウェアにアクセスする。アプリケーションプログラムはミドルウェアと同じサーバ上で動作してもよい。
　図２は管理サーバ１０１のハードウェア構成を示している。１つ以上の中央処理装置（CPU）２０１、メモリ２０２、ハードディスク等の二次記憶装置２０３、キーボード、マウスからの入力とディスプレイへの出力情報を制御する入出力インタフェース２０４、ネットワークに接続するネットワークインタフェース２０５から構成される。他サーバ１０２のハードウェア構成も同様である。なお、サーバおよび管理サーバは仮想サーバであってもよい。
　管理サーバ１０１のメモリ２０２上には性能監視プログラム２０６がロードされ、CPU２０１により実行される。また二次記憶装置２０３には性能監視プログラムが使用するテーブル２０７のデータが保存される。アプリケーションサーバ１０２ではアプリケーションプログラムがメモリ上にロードされ、CPUにより実行される。
　なお、各サーバは物理マシンでなく仮想マシンとして実装されてもよい。
　図３は性能監視プログラムの機能モジュール構成を示す。サーバ、ストレージ装置等の性能指標であるリソース使用量等の稼動時の情報を収集する稼動性能情報収集部３０１、サーバ上のミドルウェアへのアクセスに関する情報を収集する使用情報収集部３０２、システムの正常稼動時に一定期間収集した情報を使用して監視の基準を作成する監視基準作成部３０３、作成した監視基準を管理する監視基準管理テーブル３０４、稼動性能情報の定期的な測定データを基準と比較して異常度を算出する稼動性能異常度算出部３０５、使用情報の定期的な測定データを基準と比較して異常度を算出する使用特性異常算出部３０６、算出した異常度から状況の判定を行う状況判定部３０７、判定結果を出力する出力部３０８から構成される。
　図４は本実施例における性能監視プログラムのフローチャートであり、本実施例の処理の流れを示している。各ステップは中央処理装置（CPU）２０１によって実行される。監視基準作成ステップS４０１では一定期間収集した稼動性能の情報と使用特性の情報のそれぞれについて、監視基準を作成する。稼働性能の監視基準は図５の稼動性能監視項目管理テーブルに基づいて、使用特性の監視基準は図６の使用特性監視項目管理テーブルに基づいてそれぞれ作成される。よって、図５の稼動性能監視項目管理テーブル５００、図６の使用特性監視項目管理テーブル６００についてまず説明する。
　図５は稼動性能監視項目管理テーブルの構成を示す図である。複数の監視項目を組み合わせたベクトルを管理するためのベクトルIDフィールド５０１、収集対象の装置またはソフトウェアの種別を示す対象フィールド５０２、監視対象の項目名を示す監視項目フィールド５０３から構成される。監視項目は、サーバ、サーバ上のミドルウェア、ストレージ装置、ネットワーク機器といった対象装置、ソフトウェアから定期的に情報を収集する項目であって、ベクトルは一つ以上の監視項目の組み合わせで管理する。これらの監視項目は監視対象装置のリソース性能に関する値であり、監視対象の装置のリソースが自身の処理能力を現在どれだけ発揮出来ているかを示すものである。図５の例では、ベクトルＩＤが１のベクトルは、収集対象をサーバとして、監視項目であるＣＰＵ使用率とメモリ使用率を管理する。ベクトルID５０１の組み合わせはシステムで事前に定義するか、管理サーバを使用するユーザが追加、削除により設定してもよく、図５で示すベクトルID５０１の組み合わせは例示に過ぎない。
　図６は使用特性監視項目管理テーブルの構成を示す図である。複数の監視項目を組み合わせたベクトルを管理するためのベクトルIDフィールド６０１、収集対象の装置またはソフトウェアの種別を示す対象フィールド６０２、監視項目フィールド６０３から構成される。図６の例では、ベクトルＩＤが１のベクトルは、収集対象をサーバとして、監視項目であるセッション数とトランザクション数を管理する。これらの監視項目は、ユーザ計算機で稼動するアプリケーションプログラムからサーバへのアクセスに関する値である。監視項目は、システムで事前に設定するか、管理サーバを使用するユーザが追加、削除により設定され、一つ以上のベクトルとして管理する。図６で示すベクトルID６０１の組み合わせは例示に過ぎない。
　図４の監視基準作成ステップS４０１での基準作成の説明に戻る。図５の稼動性能監視項目管理テーブルの監視項目フィールド５０３にある監視項目について、一定期間分の情報を収集する。ここでの期間は予めシステムに固定としてもよいし、管理サーバを使用する管理者が設定してもよい。各監視項目のデータは監視時刻が同じまたは監視時刻誤差内のものを同時刻のデータとみなして、各監視項目を軸とする複数次元のベクトル値として表す。
　監視時刻誤差を1分未満とする場合、例えば監視項目フィールド５０３のＣＰＵ使用率の10時00分00秒のデータｘ１と、メモリ使用率の10時00分10秒のデータｙ１は、一つのベクトルのデータ（ｘ１、ｙ１）とする。ベクトル値として表した一定期間分のデータを一つ以上のグループに分類する。分類方法は例えば、近い値を複数の円（2次元の場合、三次元以上の場合は球）に分類し、グループの中心座標と半径を抽出するK-means手法とする。ここでのグループはクラスタと呼ばれる。分類結果は、図７（a）の監視基準管理テーブルに保存する。監視基準管理テーブルについては後に説明する。
　また図６の使用特性監視項目管理テーブルで管理する監視項目についても、同様に情報の収集と分類を行う。
　次に、作成した監視基準を使用した稼動状況診断を行う（S４０２）。稼動診断処理については後に図８の詳細フローを用いて説明する。
　稼動診断処理後は、結果に基づいて通知が必要かを判定する（S４０３）。ここでの判定は、一時刻分の測定データの結果に基づいて、各ベクトルの判定結果に正常でない状態がある場合に通知を行う（S４０４）。または過去の複数（ｍ）回分の測定データの結果に基づいてｎ回以上、正常でない状態が続いた場合に通知するとしてもよい。回数ｍ、ｎはシステムで定義するかユーザが指定する。
　稼動診断処理は、測定データ収集の都度、処理するフローとしているが、一定期間分をまとめて行ってもよい。その場合、通知が必要かどうかの判定は、ベクトル毎に一定期間分のデータの判定結果をまとめて、最も多い種別の通知のみを出力する方法としてもよい。
　さらに、監視基準の再作成が必要かどうかを判断する（S４０５）。使用特性データの異常度が閾値以上である場合には、過去複数（ｍ）回分の使用特性データの異常度がｎ回以上閾値以上であるかを判断する。n回以上閾値以上になっている場合には、監視基準の再作成が必要として、再度、稼働性能と使用特性の双方について監視基準の作成を行う。
　図７は作成した監視の基準となるクラスタを管理する仕組みを示す。図７(a)は作成した監視基準を管理する監視基準管理テーブルの構成を示す図である。監視基準作成処理により抽出したクラスタを識別するためのクラスタIDフィールド７０１、クラスタ別に、中心座標についてベクトルを構成する軸ごとの数値で管理する中心座標フィールド７０２、クラスタの円（３次元以上では球）の半径を管理する半径フィールド７０３から構成される。図７は２つの監視項目による２次元のベクトルを例としているが、３次元以上の場合は中心座標の軸フィールドを次元数に合わせる。図７（ｂ）はＣＰＵ使用率とメモリ使用率の２つの監視項目から作成した基準のクラスタを２次元グラフ上で示す例の図である。ここでは４つのクラスタが作成され、それぞれＩＤを付与する。
　図８は稼動状況診断処理の流れを示すフローチャート図である。各ステップは中央処理装置（CPU）２０１によって実行される。測定した使用特性データについて、監視基準と比較して監視基準からの外れ度合いを示す数値（以降ではこの数値を異常度を呼ぶ）を算出する（S８０１）。ここで、異常度の算出は、測定データと中心座標との距離が最も近いクラスタを特定し、クラスタの半径を１と正規化して、測定データと中心座標との距離に基づいて算出する。測定データがクラスタから離れるほど、異常度は大きくなる。
　管理サーバではユーザに対する通知を行うための判定基準として、異常度に対する閾値を管理する。閾値は、稼動性能監視ベクトルと使用特性監視ベクトルで同じ値であっても、異なる値であってもよい。閾値はシステムで事前に定義してもよいし、ユーザが設定してもよい。
　次に稼動性能監視ベクトルについて同様に、ベクトル毎に測定データから異常度を算出する（Ｓ８０２）。
図８では、最初に使用特性データの異常度について閾値と比較し（S８０３）、次に稼動性能データの異常度について閾値を比較する（S８０４、S８０５）。その結果、状態を決定する（S８０６～S８０９）。ここでリソースの稼動の状態を以下の条件で定義する。
　　・正常状態：使用特性が閾値未満かつ稼動性能が閾値未満の場合
　　・警告状態：使用特性が閾値未満かつ稼動性能が閾値以上の場合
　　・要注意状態：使用特性が閾値以上かつ稼動性能が閾値以上の場合
　　・注意（リスク小）状態：使用特性が閾値以上かつ稼動性能が閾値未満の場合
　そして、この閾値との比較による状態決定を稼動性能監視用の全ベクトルについて繰り返す（S８１０、S８１１）。
　図９は監視項目の測定データを管理する監視データ管理テーブルの構成を示す。使用特性ベクトルと稼動性能監視用の各ベクトルについて、時刻毎に、測定データと算出した異常度を管理する。ここで時刻に対する測定データは、監視時刻誤差内のものを該時刻のデータとみなす。例えば監視時刻誤差は±30秒未満とすると、時刻10時00分の測定データは09時59分31秒～10時00分30秒間の監視時刻を持つデータとする。
　図１０は稼動状況診断の仕組みを示す図である。図１０(a)は使用特性監視用ベクトルの一例である。監視項目として、DBサーバの使用を示すトランザクション数をｘ軸、セッション数をｙ軸としている。各円は監視基準であるクラスタを示している。図１０(b)は稼動性能監視用ベクトルの一例である。監視項目として、CPU使用率をｘ軸、メモリ使用率をｙ軸としている。各ベクトル上の丸印は測定データを示す。＃１～＃４の丸印はそれぞれ同時刻のデータであることを示す。例えば図９で管理するデータから、時刻T1における測定データを＃１とした場合、図１０(a)では＃１のデータ（１００１）は異常度がa1で閾値未満であり、クラスタの円内にある。
　図１０(b)では＃１のデータ（１００２）は異常度がa11で閾値以上であり、クラスタの円から外れている。使用特性と稼動性能の異常度をグラフのx軸、ｙ軸で表したものが図１０(ｃ)である。時刻T1における異常度（a1、a11）はデータ１００３の位置にプロットされ、この位置は警告範囲１００４であるため、状態は警告と判定される。＃２～＃４についても同様に異常度に基づいてプロットした場合、それぞれ正常１００５、要注意１００６、注意(リスク小)１００７の範囲となり、各状態と判定される。
　図１１はある稼動性能ベクトルについて、一定期間分のデータを監視した結果の例を示す図である。図４のフローチャートにおける通知が必要かの判断（S４０３）において、一定期間分のデータを使用する場合、一定期間のデータのうち、正常状態、警告状態、要注意状態、注意（リスク小）状態と判定されたデータの数をそれぞれ計測し、もっとも多いデータの数だった状態を通知する。例えば、図１１のようにそれぞれの異常度が閾値以上である範囲（１１０１）になるデータが最も多い場合、要注意状態と判断して通知を出力する。
　また基準の再作成が必要かの判断（S４０５）においては、図１１の使用特性の異常度が閾値以上の範囲（１１０１と１１０２）に、一定割合以上のデータがある場合、稼働性能の基準と使用特性の基準の再作成が必要と判断する。再作成が必要と判断した場合には、稼働性能の基準と使用性能の基準を再作成し、管理サーバ１０１が再作成した稼働性能の基準と使用特性の基準を二次記憶装置２０３に格納する。具体的には図７（a）監視基準管理テーブルを更新する。
　図１２は状態に応じて出力する通知内容を管理するテーブルである。監視対象のリソースを示す対象フィールド１２０１、状態フィールド１２０２と対応するメッセージ種別を示す種別フィールド１２０３、メッセージ内容を管理するメッセージフィールド１２０４から構成される。正常状態については本例ではメッセージをなし（null）で管理し、出力しない。メッセージに対象ベクトルの監視項目や対象装置を含めてもよい。
　図１３は本実施例における出力画面の例を示す図である。上段（１３０１）には、監視対象の稼動性能監視用ベクトルの異常度を時系列に表示し、下段（１３０２）には、出力された通知をイベント一覧として表示する。イベント一覧では通知の種別とともに、適切な対処法を提案するメッセージを表示してもよい。上段のグラフ上で稼動性能が閾値を超過している場合でも通知は警告（１３０３）と注意（１３０４）といった異なる種別となっている。これらの表示により、管理者は、異なる通知によってとるべき適切な対処法を切り分けることができ、迅速な対処が可能となる。
　また、管理者によっては、多くの通知の中から、例えば、警告（１３０３）の通知に対して優先的に対応したい場合もある。よって、図１３に示す出力画面上で、管理者が通知したい通知種別の選択を受け付け、選択された通知種別の通知のみを表示するようにしてもよい。これにより、多くの通知が発生した際に、管理者が現在必要としている通知のみを表示することで、管理者の管理効率が向上する。図１３は出力画面の一例にすぎず、例えば図１１の画面を出力してもよい。
　以上により、リソース監視において、リソースを使用する側の特性の変動が原因かどうかの適切な判定によって通知を分けることができ、管理者に対する切り分け処理の負担を軽減できる。
　一つの具体例では、クラウド環境のPaaS（Platform as a Service）形態で、DBサーバをユーザのアプリケーションプログラムに提供する。提供システムの監視において、DBサーバを実行するサーバのCPU使用率が普段と異なることを検出した場合、例えばDBサーバで適切でない実行計画を用いたことでCPU使用が増えたケースはDBサーバの側の異常つまりリソース自体の異常だが、トランザクション数が普段より多いケースは入力増加というリソースの使い方（使用特性）の変化に伴うCPU使用増加である。従来技術ではこれらを区別できないため、管理者がどちらのケースなのかを分析せねばならず、適切な対処を迅速に行うことができない。
　しかし、本発明により、CPU使用率の変動を検出し、通知がなされる場合には、トランザクション数に変動があったか否かによってさらに異なる通知がされるため、管理者は通知に対応する適切な対処を迅速に行うことが可能となる。
［第２の実施例］
　本発明の第１の実施例の変形例として、アプリケーションプログラムが使用するミドルウェアが複数のサーバに分散された構成の実施例を示す。実施例１は稼動状況を監視する装置一台と、アプリケーションプログラムによる使用特性を一つのベクトルで監視する形態であるのに対して、本実施例は稼動状況を監視する装置およびミドルウェアが複数台である点が異なる。
　図１４は実施例２における本発明が対象とするシステムの概要を示す。複数台のサーバで同じミドルウェアが動作し、アプリケーションプログラムとサーバは負荷分散装置１４０１に接続する。アプリケーションプログラムからのアクセスは、負荷分散装置によって、複数台のミドルウェアに分散して処理される。複数のミドルウェアへの分散は、ユーザ計算機１０６やサーバ１０２が負荷分散ソフトウェアを有して実行してもよいし、ユーザ計算機１０６やサーバ１０２とは別の装置が負荷分散ソフトウェアを有して実行してもよい。
　ここでは実施例１同様、ミドルウェアをDBサーバの例で説明する。DBサーバは複数台での分散処理する構成において、ストレージ装置を共有としてデータを共有する。
　本実施例においては、アプリケーションプログラムの使用特性はアクセス先である各サーバのOSおよびDBサーバから取得する。さらに、同時刻に各サーバから取得した使用情報に関する監視項目の測定データを合算した値を算出する。なお監視時刻が一定誤差内のデータを、同時刻の測定データとみなす。
　使用特性監視用ベクトルについては、複数のDBサーバをそれぞれ監視するベクトルと、合算値を監視するベクトルを設ける。図９で示した監視データ管理テーブルには、使用特性監視用のカラム（図９の例ではトランザクション数、セション数、異常度）をサーバ毎に設ける。さらに、トランザクション数、セション数それぞれについて、分散構成の全サーバの合計値と、合計値における異常度を管理するカラムを設ける。
　稼動性能については、実施例１同様、サーバ、ストレージ装置等から収集し、装置毎に稼動性能監視用ベクトルを設けて監視する。
　測定データの合算処理は、図４のフローチャートの監視基準の作成処理（S４０１）と稼動診断処理（S４０２）において行う。
　監視基準については、使用特性監視用の監視基準として分散されたDBサーバ毎の基準と、DBサーバへの分散をまとめた合計値であるアプリケーションプログラム毎の基準を作成する。
図８のフローチャートで示す稼動診断処理については、使用特性データから異常度を算出するステップ（S801）において、サーバ毎の使用特性の異常度と各サーバの使用特性の合計値の異常度を算出する。サーバ毎の使用特性の異常度は、サーバ毎の使用特性とDBサーバ毎の基準から算出し、各サーバの使用特性の合計値の異常度は、各サーバの使用特性の合計値とアプリケーションプログラム毎の基準から算出する。
　算出の方法は実施例１と同様である。使用特性の異常度とサーバの稼働性能の異常度を照らし合わせる場合、異常度を照らし合わせて状況を判別するステップでは、まず実施例１と同様に、サーバ毎にサーバの使用特性の異常度と、各稼動性能の異常度とを照らし合わせて判定する。つまり、図８のステップ（S８０１）でサーバ毎の使用特性とDBサーバ毎の基準とからサーバ毎の使用特性の異常度を算出する。そして、ステップ（S８０３）ではサーバ毎の使用特性の異常度が閾値未満かを判定する。図８におけるそれ以外のステップと判定後のユーザへの表示は実施例１と同様である。
　この判定により、個々のサーバに分散されたサーバへのアプリケーションプログラムからのアクセスが、それぞれのサーバの稼動性能に与える影響を考慮した状況を判別した通知を行うことができる。
　上記の判定に加えて、本実施例では個々のサーバの各稼動性能の異常度に対して、分散されたアクセスの合計値に基づくアプリケーションプログラムの使用特性の異常度を照らし合わせて判定する処理を追加する。つまり、図８のステップ（S８０１）で各サーバの使用特性の合計値とDBサーバへの分散をまとめた合計値であるアプリケーションプログラム毎の基準とから各サーバの使用特性の合計値の異常度を算出する。そして、ステップ（S８０３）では各サーバの使用特性の合計値の異常度が閾値未満かを判定する。図８におけるそれ以外のステップと判定後のユーザへの表示は実施例１と同様である。
　上記のサーバ毎の使用特性の異常度との突き合わせによる判定では、分散の割合が変化したのか、アプリケーションプログラムの使用特性そのものが変化したのか分からないので、アプリケーションプログラム単位に合計した値を使用特性として照らし合わせることで、アプリケーションプログラムの使用特性が平常時と異なる状況なのかを判別した通知が可能になる。
　さらに、使用特性の異常度とストレージ装置の稼働性能の異常度を照らし合わせる場合は、ストレージ装置は分散サーバに共有されているため、使用特性は合計値の異常度を使用し、ストレージ装置の各稼動性能の異常度と照らし合わせて判定する。つまり、図８のステップ（S８０１）で各サーバの使用特性の合計値とDBサーバへの分散をまとめた合計値であるアプリケーションプログラム毎の基準とから各サーバの使用特性の合計値の異常度を算出する。そして、ステップ（S８０３）では各サーバの使用特性の合計値の異常度が閾値未満かを判定する。図８におけるそれ以外のステップと判定後のユーザへの表示は実施例１と同様である。
　この判定により、ストレージ装置の稼働性能が平常時と異なる（異常度が閾値以上）場合であっても、アプリケーションプログラムの使用特性が平常時と異なる状況なのかを判別した適切な通知を行うことができる。　また、本実施例では、図４のフローチャートにおける基準の再作成が必要かの判断処理（S４０５）については、アプリケーションプログラム単位で使用状況が変化したかを判断するため、使用特性データとして各サーバの合計値から算出される異常度のデータを用いる。合計値の使用特性データの異常度が閾値以上である場合に、一定期間の過去データのうち一定個数以上が閾値以上である場合には、使用特性と各稼動性能のベクトルについて監視基準の再作成が必要と判断する。
　以上により、分散処理構成のシステムにおいても、分散されたリソースの稼動性能と、それらのリソースを使用するアプリケーションプログラムの使用特性のデータを照らし合わせることにより、リソースの状態の適切な判定による通知が可能となる。
［第３の実施例］
　本発明の第１の実施例の変形例として、一台の装置のリソースに対して、使用するソフトウェアが複数である構成における実施例を示す。実施例１は稼動性能を監視する装置一台と、アプリケーションプログラムによる使用特性を一つのベクトルで監視する形態であるのに対して、本実施例は装置一台の稼動性能に対して、使用特性のベクトルが複数となる点が異なる。
ここでは、サーバ仮想化環境を例とする。図１５は実施例３における本発明が対象とするシステムの概要を示す。一台の物理サーバ１５０１のリソースを仮想化基盤ソフトウェアであるハイパーバイザ１５０２が仮想化し、複数の仮想マシン１５０３が使用する構成である。クラウド環境では仮想マシンを顧客に提供するIaaS（Infrastructure as a Service）形態を想定する。
　物理サーバ１５０１は図１と同様にネットワーク機器１０３に経由でストレージ装置１０４と接続されるが直接接続であってもよい。管理サーバ１０１は管理用ネットワーク（図示せず）を介して図１５のように各装置と接続される。仮想マシン１５０３上にはアプリケーションプログラム等が動作するが、ここでは個々のアプリケーションプログラムは監視の対象とせず、仮想マシン毎に物理サーバのリソースを使用する情報を、使用特性監視用ベクトルの情報として取得する。図６の使用特性監視項目管理テーブルには、対象を仮想マシンとして、仮想マシンの監視項目であるCPU使用率やメモリ使用率の組合せを管理する。
　稼動性能の情報については、実施例１と同様に装置から稼動時の情報を収集する。ここでは物理サーバのハイパーバイザを対象とし、リソースの競合等に関する項目を稼動性能監視用ベクトルの情報として収集する。例えばCPUで仮想マシンの実行をスケジュールできなかった時間の割合を示す値や、メモリのスワップ使用量等とする。図５の稼動性能監視項目管理テーブルには、対象をハイパーバイザとして、これらの項目を組み合わせて管理する。
　測定データについては、図９の監視データ管理テーブルには、使用特性監視用のカラムを仮想マシン毎に設けて管理する。稼動性能監視用のカラムはハイパーバイザ用の監視項目のカラムで管理する。
　図４のフローチャートにおいて、監視基準の作成処理（S４０１）は第１の実施例と同様である。仮想マシン毎の使用特性データとハイパーバイザの稼動性能データについて、過去の測定データから監視基準を作成する。
　図８の稼動状況診断処理では、仮想マシン毎の使用特性データとハイパーバイザの稼働性能データについてそれぞれ異常度を算出する。データを照らし合わせて状況を判断する処理については、実施例１では各稼動性能データの異常度に対して、同一時間帯の一つの使用特性データの異常度を照らし合わせるが、本実施例では一つの稼動性能データの異常度に対して、同一時間帯の複数の使用特性データを照らし合わせる点が異なる。
　図１６は、本実施例における、ある時刻のデータを判定する仕組みを示す図である。ハイパーバイザの稼動性能データの異常度をｙ軸に、各仮想マシンの使用特性データの異常度をｘ軸で表している。丸印はある時刻のそれぞれの異常度をベクトルで表した座標を示している。同一時刻において稼動性能データの異常度は同じであり、図１６には時刻T1におけるデータ１６０１と、時刻T2におけるデータ１６０２を示している。
　本実施例における判定では、ハイパーバイザの稼動性能データが平常時と異なり（異常度が閾値以上）、いずれの仮想マシンも平常時と同様の使用特性である（異常度が閾値未満）場合（１６０１）は、ハイパーバイザの稼働状況を警告状態と判断する。
　ハイパーバイザの稼動性能データが平常時と異なり（異常度が閾値以上）、いくつかの仮想マシンの使用特性データが平常時と異なる（異常度が閾値以上）場合（１６０２）は、該仮想マシンの使用特性が変化したことによるハイパーバイザの挙動であって、要注意状態と判断する。ここでは、使用特性データの異常度が閾値以上の仮想マシンが全体台数に対して特定の割合以上の場合に要注意状態と判断してもよいし、異常度が閾値以上の仮想マシンが１台であっても要注意状態と判断してもよい。範囲に含まれる仮想マシンの割合についての判断条件は予めシステムか管理者が定義しておく。ハイパーバイザの稼動性能データが閾値未満である場合についても、正常か注意（リスク小）状態かは、仮想マシン毎の使用特性データの異常度と、各範囲に含まれる仮想マシンの割合によって同様に判定する。
　通知時のメッセージについては、実施例１の図１２と同様で、対象をハイパーバイザとして状態別に管理し、判定に従って通知する。
　なお、通知については、一時刻の判断結果が正常時以外の場合に通知する方法だけでなく、一定期間の判定結果について、最も多くの判定結果が含まれる状態を通知する方法としてもよい。例えば時刻T１からT10までの判定結果が、T1では警告、T2～T10までは要注意であれば、T10の判定後に要注意状態として通知する。
　さらに本実施例では、判定した状態の通知に、仮想マシンの情報を含めて通知する。例えば判定状態が警告である場合には、各仮想マシンの使用特性データの異常度はいずれも閾値未満であり、「稼動性能に影響を与える仮想マシンはなし」とする。判定状態が要注意である場合には、使用特性データの異常度が閾値以上の仮想マシンが存在し、「使用特性が変化した仮想マシンはVM１,VM２,VM３」といった情報を通知に付与する。
ユーザへの表示については、図１２による通知に限られず、例えば管理計算機が図１６に示す画面を表示し、図１６を示す画面上で個々のデータにVM１,VM２,VM３といったそれぞれの仮想マシンを対応させてユーザに示してもよい。これにより、ユーザは稼働性能に影響を与えている、仮想マシンとその使用特性の異常度がどの程度かを把握することが可能となる。
　また本実施例では、図４のフローチャートにおける基準の再作成が必要かの判断処理（S405）については、仮想マシン毎に複数の使用特性データを持つことから、使用特性データの異常度が閾値以上になった仮想マシンが、システムで定義する特定の割合以上になった場合に、基準の再作成が必要と判断する。各仮想マシンの使用特性データとハイパーバイザの稼動性能データについて、それぞれ監視基準を再作成する。
　以上により、リソースの提供側であるハイパーバイザの稼動性能と、リソースを使用する各仮想マシンの使用特性を照らし合わせることで、ハイパーバイザのリソースに問題があるのか、使用特性の変化した仮想マシンが影響しているのかを判別して、適切な通知を行うことができる。また管理者はハイパーバイザの稼動性能が平常時と異なる場合に、影響を与えている仮想マシンを容易に判別することができる。
　また、本実施例は図１５の構成に限られず、図１でユーザ計算機１００が複数存在し、複数のアプリケーションプログラム１０６からサーバ１０２にアクセスがある場合にも適応できる。
　この場合には、複数のアプリケーションプログラム１０６毎に、図６に示すアプリケーションプログラム１０６からサーバ１０２へのアクセスに関する値を管理する。そして、使用特性が監視用ベクトルの情報として取得する情報は、仮想マシン毎に物理サーバを使用する情報ではなく、複数のアプリケーションプログラム１０６毎のサーバ１０２へのアクセスに関する値となる。
　稼働性能の情報については、実施例１と同様であり、測定データについては、図９の監視データ管理テーブルには、使用特性監視用のカラムをアプリケーションプログラム（AP）１０６毎に設けて管理する。
　図４のフローチャートにおいて、監視基準作成処理(S401)は実施例１と同様である。アプリケーションプログラム１０６毎の使用特性データと図５に示す監視項目の稼働性能データについて、過去の測定データから監視基準を作成する。
　図８の稼働状況診断処理では、アプリケーションプログラム１０６毎の使用特性データとサーバ１０５、ストレージ１０４の稼働性能データについてそれぞれ異常度を算出する。データを照らし合わせて状況を判断する処理については、図１５の構成の場合と同様に一つの稼動性能データの異常度に対して、同一時間帯の複数の使用特性データを照らし合わせる。
　図１６では、サーバ１０２又はストレージ装置１０４の稼動性能データの異常度をｙ軸に、各アプリケーションプログラム１０６の使用特性データの異常度をｘ軸で表す点が図１５の構成の場合と異なる。
　図１の構成の場合における判定では、サーバ１０２又はストレージ装置１０４の稼動性能データが平常時と異なり（異常度が閾値以上）、複数の使用特性の何れもが平常時と同様の使用特性である（異常度が閾値未満）場合（１６０１）は、サーバ１０２又はストレージ装置１０４の稼働状況を警告状態と判断する。
　サーバ１０２又はストレージ装置１０４の稼動性能データが平常時と異なり（異常度が閾値以上）、いくつかの使用特性データが平常時と異なる（異常度が閾値以上）場合（１６０２）は、使用特性が変化したことによるサーバ１０２又はストレージ装置１０４の挙動であって、要注意状態と判断する。ここでは、使用特性データの異常度が閾値以上のアプリケーションプログラム１０６の数が総数に対して特定の割合以上の場合に要注意状態と判断してもよいし、異常度が閾値以上のアプリケーションプログラム１０６が１つあっても要注意状態と判断してもよい。範囲に含まれるアプリケーションプログラム１０６の割合についての判断条件は予めシステムか管理者が定義しておく。ハイパーバイザの稼動性能データが閾値未満である場合についても、正常か注意（リスク小）状態かは、アプリケーションプログラム１０６の使用特性データの異常度と、各範囲に含まれるアプリケーションプログラム１０６の割合によって同様に判定する。
　通知時のメッセージについては、対象をサーバ１０２又はストレージ装置１０４として状態別に管理し、判定に従って通知する。
　なお、通知については、一時刻の判断結果が正常時以外の場合に通知する方法だけでなく、一定期間の判定結果について、最も多くの判定結果が含まれる状態を通知する方法としてもよい。例えば時刻T１からT10までの判定結果が、T1では警告、T2～T10までは要注意であれば、T10の判定後に要注意状態として通知する。
　さらに図１の構成の場合の本実施例では、判定した状態の通知に、アプリケーションプログラム１０６の情報を含めて通知する。例えば判定状態が警告である場合には、各アプリケーションプログラム１０６の使用特性データの異常度はいずれも閾値未満であり、「稼動性能に影響を与えるアプリケーションプログラム１０６はなし」とする。判定状態が要注意である場合には、使用特性データの異常度が閾値以上のアプリケーションプログラム１０６が存在し、「使用特性が変化したアプリケーションプログラム１０６はAP１,AP２,AP３」といった情報を通知に付与する。
　ユーザへの表示については、図１２による通知に限られず、例えば管理計算機が図１６に示す画面を表示し、図１６を示す画面上で個々のデータにAP１,AP２,AP３といったアプリケーションプログラム１０６を対応させてユーザに示してもよい。これにより、ユーザは稼働性能に影響を与えている、アプリケーションプログラム１０６とその使用特性の異常度がどの程度かを把握することが可能となる。
　また図１の構成における本実施例では、図４のフローチャートにおける基準の再作成が必要かの判断処理（S405）については、アプリケーションプログラム１０６毎に複数の使用特性データを持つことから、使用特性データの異常度が閾値以上になったアプリケーションプログラム１０６が、システムで定義する特定の割合以上になった場合に、基準の再作成が必要と判断する。各アプリケーションプログラム１０６の使用特性データとサーバ１０２、ストレージ装置１０４の稼動性能データについて、それぞれ監視基準を再作成する。
　以上により、リソースの提供側であるサーバ１０２、ストレージ装置１０４の稼動性能と、各アプリケーションプログラム１０６からサーバ１０２へのアクセスに関する値である使用特性を照らし合わせることで、サーバ１０２、ストレージ装置１０４のリソースに問題があるのか、使用特性の変化したアプリケーションプログラム１０６が影響しているのかを判別して、適切な通知を行うことができる。また管理者は稼動性能が平常時と異なる場合に、影響を与えているアプリケーションプログラム１０６を容易に判別することができる。
１００：ユーザ計算機
１０１：管理サーバ
１０２：サーバ
１０３：ネットワーク機器
１０４：ストレージ装置
１０５：実行基盤ソフトウェア
１０６：アプリケーションプログラム

Claims (18)

  1. 　第１のアプリケーションプログラムからアクセスされる第１の管理対象計算機を管理し、プロセッサを含む管理計算機であって、
    　前記プロセッサは、
    　前記第１の管理対象計算機のリソース性能に関する値である第１の稼働性能と前記第１のアプリケーションプログラムから前記第１の管理対象計算機へのアクセスに関する値である第１の使用特性とを取得し、
    　前記第１の稼働性能の異常度と前記第１の使用特性の異常度とを算出し、
    　前記算出された第１の稼働性能の異常度と前記算出された第１の使用特性の異常度とから前記第１の管理対象計算機の稼働状況を通知する、
    　ことを特徴とする管理計算機。
  2. 　前記プロセッサは、
    　前記第１の稼働性能の異常度と第１の閾値とを比較する第１の判定をし、前記第１の使用特性の異常度と第２の閾値とを比較する第２の判定をし、
    　前記第１の判定と前記第２の判定との結果に基づいて、前記第１の管理対象計算機の稼働状況を通知する、
    　ことを特徴とする請求項１に記載の管理計算機。
  3. 　前記管理計算機はさらに記憶装置を含み、
    　前記記憶装置は稼働性能の基準値と使用特性の基準値とを格納し、
    　前記プロセッサは、
    　前記取得した第１の稼働性能の前記稼働性能の基準値からの外れ度合いを前記第１の稼働性能の異常度として算出し、
    　前記取得した第１の使用特性の前記使用特性の基準値からの外れ度合いを前記第１の使用特性の異常度として算出する、
    　ことを特徴とする請求項２に記載の管理計算機。
  4. 　前記管理計算機は、
    　前記第１の判定において前記第１の稼働性能の異常度が前記第１の閾値以上である場合であって、前記第２の判定において前記第１の使用特性の異常度が前記第２の閾値以上である場合、には第１の通知を表示し、
    　前記第１の判定において前記第１の稼働性能の異常度が前記第１の閾値以上である場合であって、前記第２の判定において前記第１の使用特性の異常度が前記第２の閾値未満である場合、には第２の通知を表示する、
    　ことを特徴とする請求項３に記載の管理計算機。
  5. 　前記プロセッサは、所定の期間内に、
    　前記第１の判定において前記第１の稼働性能の異常度が前記第１の閾値以上である場合であって、前記第２の判定において前記第１の使用特性の異常度が前記第２の閾値以上である場合、の第１の回数、
    　前記第１の判定において前記第１の稼働性能の異常度が前記第１の閾値以上である場合であって、前記第２の判定において前記第１の使用特性の異常度が前記第２の閾値未満である場合、の第２の回数、
    　前記第１の判定において前記第１の稼働性能の異常度が前記第１の閾値未満である場合であって、前記第２の判定において前記第１の使用特性の異常度が前記第２の閾値以上である場合、の第３の回数、
    　前記第１の判定において前記第１の稼働性能の異常度が前記第１の閾値未満である場合であって、前記第２の判定において前記第１の使用特性の異常度が前記第２の閾値未満である場合、の第４の回数、
    　を計測し、
    　前記第１の回数と前記第２の回数と前記第３の回数と前記第４の回数とのうち最大のものを算出し、
    　前記管理計算機は、
    　前記第１の回数と前記第２の回数と前記第３の回数と前記第４の回数の何れが最大かによって異なる通知を表示する、
    　ことを特徴とる請求項３に記載の管理計算機。
  6. 　前記プロセッサは、
    　前記取得した第１の稼働性能値から前記稼働性能値の基準値を作成し、前記取得した第１の使用特性値から使用特性値の基準値を作成する、
    　前記記憶装置は、前記作成された稼働性能値の基準値と前記作成された使用特性値の基準値とを格納する、
    　ことを特徴とする請求項３に記載の管理計算機。
  7. 　前記プロセッサは、所定の期間内に、前記第１の使用特性の異常度の前記第２の閾値を越える割合が所定の値を上回る場合には、前記稼働性能の基準値と前記使用特性の基準値とを再作成し、
    　前記記憶装置は、前記再作成された稼働性能の基準値と前記再作成された使用特性の基準値とを格納する、
    　ことを特徴とする請求項６に記載の管理計算機。
  8. 　前記管理計算機はさらに第２の管理対象計算機を管理し、
    　前記プロセッサは、
    　前記第２の管理対象計算機のリソース性能に関する値である第２の稼働性能と前記第１のアプリケーションプログラムから前記第２の管理対象計算機へのアクセスに関する値である第２の使用特性とを取得し、
    　前記第２の稼働性能の異常度と前記第２の使用特性の異常度とを算出し、
    　前期第１の使用特性と前記第２の使用特性との合計である合計使用特性を算出し、
    　前記合計使用特性の異常度を算出し、
    　前記算出された第１の稼働性能の異常度と前記算出された第１の使用特性の異常度と前記第２の稼働性能の異常度と前記第２の使用特性の異常度と前記算出された合計使用特性とから前記第１の管理対象計算機と第２の管理対象計算機の稼働状況を通知する、
    　ことを特徴とする請求項１に記載の管理計算機。
  9. 　前記管理計算機はさらに第２のアプリケーションプログラムからアクセスされ、
    　前記プロセッサはさらに、
    　前記第２のアプリケーションプログラムから前記第２の管理対象計算機へのアクセスに関する値である第３の使用特性を取得し、
    　前記第３の使用特性の異常度を算出し、
    　前記算出された第１の稼働性能の異常度と前記算出された第１の使用特性の異常度と前記算出された第３の使用特性の異常度とから前記第１の管理対象計算機の稼働状況を通知する、
    　ことを特徴とする請求項１に記載の管理計算機。
  10. 　第１のアプリケーションプログラムからアクセスされる第１の管理対象計算機の管理方法であって、
    　前記第１の管理対象計算機のリソース性能に関する値である第１の稼働性能と前記第１のアプリケーションプログラムから前記第１の管理対象計算機へのアクセスに関する値である第１の使用特性とを取得し、
    　前記第１の稼働性能の異常度と前記第１の使用特性の異常度とを算出し、
    　前記算出された第１の稼働性能の異常度と前記算出された第１の使用特性の異常度とから前記第１の管理対象計算機の稼働状況を通知する、
    　ことを特徴とする管理対象計算機の管理方法。
  11. 　前記第１の稼働性能の異常度と第１の閾値とを比較する第１の判定をし、
    　前記第１の使用特性の異常度と第２の閾値とを比較する第２の判定をし、
    　前記第１の判定と前記第２の判定との結果に基づいて、前記第１の管理対象計算機の稼働状況を通知する、
    　ことを特徴とする請求項１０に記載の管理対象計算機の管理方法。
  12. 　前記管理計算機はさらに記憶装置を含み、
    　前記記憶装置は稼働性能の基準値と使用特性の基準値とを格納し、
    　前記取得した第１の稼働性能の前記稼働性能の基準値からの外れ度合いを前記第１の稼働性能の異常度として算出し、
    　前記取得した第１の使用特性の前記使用特性の基準値からの外れ度合いを前記第１の使用特性の異常度として算出する、
    　ことを特徴とする請求項１１に記載の管理対象計算機の管理方法。
  13. 　前記第１の判定において前記第１の稼働性能の異常度が前記第１の閾値以上である場合であって、前記第２の判定において前記第１の使用特性の異常度が前記第２の閾値以上である場合、には第１の通知を表示し、
    　前記第１の判定において前記第１の稼働性能の異常度が前記第１の閾値以上である場合であって、前記第２の判定において前記第１の使用特性の異常度が前記第２の閾値未満である場合、には第２の通知を表示する、
    　ことを特徴とする請求項１２に記載の管理対象計算機の管理方法。
  14. 　所定の期間内に、
    　前記第１の判定において前記第１の稼働性能の異常度が前記第１の閾値以上である場合であって、前記第２の判定において前記第１の使用特性の異常度が前記第２の閾値以上である場合、の第１の回数、
    　前記第１の判定において前記第１の稼働性能の異常度が前記第１の閾値以上である場合であって、前記第２の判定において前記第１の使用特性の異常度が前記第２の閾値未満である場合、の第２の回数、
    　前記第１の判定において前記第１の稼働性能の異常度が前記第１の閾値未満である場合であって、前記第２の判定において前記第１の使用特性の異常度が前記第２の閾値以上である場合、の第３の回数、
    　前記第１の判定において前記第１の稼働性能の異常度が前記第１の閾値未満である場合であって、前記第２の判定において前記第１の使用特性の異常度が前記第２の閾値未満である場合、の第４の回数、
    　を計測し、
    　前記第１の回数と前記第２の回数と前記第３の回数と前記第４の回数とのうち最大のものを算出し、
    　前記第１の回数と前記第２の回数と前記第３の回数と前記第４の回数の何れが最大かによって異なる通知をする、
    　ことを特徴とする請求項１２に記載の管理対象計算機の管理方法。
  15. 　前記取得した第１の稼働性能値から前記稼働性能値の基準値を作成し、
    　前記取得した第１の使用特性値から使用特性値の基準値を作成し、
    　前記作成された稼働性能値の基準値と前記作成された使用特性値の基準値とを格納する、
    　ことを特徴とする請求項１２に記載の管理対象計算機の管理方法。
  16. 　所定の期間内に、前記第１の使用特性の異常度の前記第２の閾値を越える割合が所定の値を上回る場合には、前記稼働性能の基準値と前記使用特性の基準値とを再作成し、
    　前記再作成された稼働性能の基準値と前記再作成された使用特性の基準値とを格納する、
    　ことを特徴とする請求項１５に記載の管理対象計算機の管理方法。
  17. 　前記管理計算機はさらに第２の管理対象計算機を管理し、
    　前記第２の管理対象計算機のリソース性能に関する値である第２の稼働性能と前記第１のアプリケーションプログラムから前記第２の管理対象計算機へのアクセスに関する値である第２の使用特性とを取得し、
    　前記第２の稼働性能の異常度と前記第２の使用特性の異常度とを算出するステップと、
    　前期第１の使用特性と前記第２の使用特性との合計である合計使用特性を算出し、
    　前記合計使用特性の異常度を算出し、
    　前記算出された第１の稼働性能の異常度と前記算出された第１の使用特性の異常度と前記第２の稼働性能の異常度と前記第２の使用特性の異常度と前記算出された合計使用特性とから前記第１の管理対象計算機と第２の管理対象計算機の稼働状況を通知する、
    　ことを特徴とする請求項１０に記載の管理対象計算機の管理方法。
  18. 　前記管理計算機はさらに第２のアプリケーションプログラムからアクセスされ、
    　前記第２のアプリケーションプログラムから前記第２の管理対象計算機へのアクセスに関する値である第３の使用特性を取得し、
    　前記第３の使用特性の異常度を算出し、
    　前記算出された第１の稼働性能の異常度と前記算出された第１の使用特性の異常度と前記算出された第３の使用特性の異常度とから前記第１の管理対象計算機の稼働状況を通知する、
    　ことを特徴とする請求項１０に記載の管理対象計算機の管理方法。
PCT/JP2016/053126 2016-02-03 2016-02-03 管理計算機及び管理対象計算機の管理方法 WO2017134758A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/JP2016/053126 WO2017134758A1 (ja) 2016-02-03 2016-02-03 管理計算機及び管理対象計算機の管理方法
JP2017565010A JP6674481B2 (ja) 2016-02-03 2016-02-03 管理計算機及び管理対象計算機の管理方法
US15/744,626 US10909016B2 (en) 2016-02-03 2016-02-03 Management computer and method of managing computer to be managed

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2016/053126 WO2017134758A1 (ja) 2016-02-03 2016-02-03 管理計算機及び管理対象計算機の管理方法

Publications (1)

Publication Number Publication Date
WO2017134758A1 true WO2017134758A1 (ja) 2017-08-10

Family

ID=59500141

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2016/053126 WO2017134758A1 (ja) 2016-02-03 2016-02-03 管理計算機及び管理対象計算機の管理方法

Country Status (3)

Country Link
US (1) US10909016B2 (ja)
JP (1) JP6674481B2 (ja)
WO (1) WO2017134758A1 (ja)

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US11010273B2 (en) * 2017-06-28 2021-05-18 Intel Corporation Software condition evaluation apparatus and methods
JP6995701B2 (ja) * 2018-06-15 2022-01-17 株式会社日立製作所 系統断面データ管理装置および方法
JP6724960B2 (ja) * 2018-09-14 2020-07-15 株式会社安川電機 リソース監視システム、リソース監視方法、及びプログラム
CN110928741B (zh) * 2018-09-20 2021-09-24 西门子（中国）有限公司 系统状态监视方法、装置和存储介质

Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008191849A (ja) * 2007-02-02 2008-08-21 Ns Solutions Corp 稼働管理装置、情報処理装置、稼働管理装置の制御方法、情報処理装置の制御方法及びプログラム
JP2010186310A (ja) * 2009-02-12 2010-08-26 Nec Corp 運用管理装置および運用管理方法ならびにそのプログラム
JP2014203310A (ja) * 2013-04-05 2014-10-27 富士通株式会社 情報処理装置、プログラム及び情報処理方法
JP2015046133A (ja) * 2013-08-29 2015-03-12 日本電信電話株式会社 制御装置、計算資源管理方法及び計算資源管理プログラム

Family Cites Families (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2001142746A (ja) 1999-11-11 2001-05-25 Nec Software Chubu Ltd 計算機システムの負荷監視装置
JP5485939B2 (ja) 2011-05-18 2014-05-07 日立Ｇｅニュークリア・エナジー株式会社 機器異常判定装置、及び機器異常判定方法
US10616078B1 (en) * 2014-03-20 2020-04-07 Amazon Technologies, Inc. Detecting deviating resources in a virtual environment

Patent Citations (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2008191849A (ja) * 2007-02-02 2008-08-21 Ns Solutions Corp 稼働管理装置、情報処理装置、稼働管理装置の制御方法、情報処理装置の制御方法及びプログラム
JP2010186310A (ja) * 2009-02-12 2010-08-26 Nec Corp 運用管理装置および運用管理方法ならびにそのプログラム
JP2014203310A (ja) * 2013-04-05 2014-10-27 富士通株式会社 情報処理装置、プログラム及び情報処理方法
JP2015046133A (ja) * 2013-08-29 2015-03-12 日本電信電話株式会社 制御装置、計算資源管理方法及び計算資源管理プログラム

Also Published As

Publication number Publication date
US20180210803A1 (en) 2018-07-26
JP6674481B2 (ja) 2020-04-01
JPWO2017134758A1 (ja) 2018-07-19
US10909016B2 (en) 2021-02-02

Similar Documents

Publication Publication Date Title
US20190384648A1 (en) Proactive high availability in a virtualized computer system
JP6674481B2 (ja) 管理計算機及び管理対象計算機の管理方法
US6968291B1 (en) Using and generating finite state machines to monitor system status
US9967326B2 (en) Information handling system application decentralized workload management
US20120324451A1 (en) Virtualization planning system
US9542213B2 (en) Method and system for identifying virtualized operating system threats in a cloud computing environment
JP6152770B2 (ja) 管理プログラム、管理方法、および情報処理装置
EP3200076A1 (en) System and method for load estimation of virtual machines in a cloud environment and serving node
US9852007B2 (en) System management method, management computer, and non-transitory computer-readable storage medium
US9569251B2 (en) Analytics platform spanning a subset using pipeline analytics
EP3503473B1 (en) Server classification in networked environments
Xue et al. Managing data center tickets: Prediction and active sizing
US20140337534A1 (en) Server virtualization
US9588792B2 (en) Method and system for sorting and bucketizing alerts in a virtualization environment
US11113364B2 (en) Time series data analysis control method and analysis control device
Alguliyev et al. Hybridisation of classifiers for anomaly detection in big data
WO2013035266A1 (ja) 監視装置、監視方法およびプログラム
CN112015995A (zh) 数据分析的方法、装置、设备以及存储介质
US20150120921A1 (en) Techniques for workload toxic mapping
JP2016103126A (ja) 重要業績評価指標のカテゴリ分割の条件を求める方法、並びに、その為のコンピュータ及びコンピュータ・プログラム
EP3982267B1 (en) Display method and device for object representation indexes
US10228822B2 (en) Optimal visualization of systems with large quantity of technical servicer instances
US11757736B2 (en) Prescriptive analytics for network services
JP7409866B2 (ja) 通信監視装置及び通信監視方法
JP7012778B2 (ja) 監視システム、監視装置及び監視方法

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: 16889248

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 15744626

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2017565010

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 16889248

Country of ref document: EP

Kind code of ref document: A1