JP2014157412A - Event aggregation device, event aggregation method, and event aggregation program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide an event aggregation device, an event aggregation method, and an event aggregation program capable of easily determining a failure by which an event occurring in a computer system is caused and reducing work load required for examination diagnosis of the event.SOLUTION: The event aggregation device includes: an information acquisition unit 1 for acquiring event history information which shows occurrence history of an event showing a failure or a sign of failure in a computer system and metric history information which shows a use state of a resource in the computer system for metric as a measurement value; a storage unit 2 for storing a system sketch in which a state of the metric at the time of failure occurrence in the computer system is defined; and an aggregation unit 3 for aggregating, from the event history information, each event occurring in a time zone when a measurement result of each metric shown by the metric history information and a state of each metric shown by the system sketch are matched, as an event group corresponding to the system sketch.

Description

  The present invention relates to an event aggregating apparatus, an event aggregating method and an event aggregating program for a computer system composed of a plurality of components, and in particular, an event aggregating apparatus for aggregating events in each part of each computer for each failure event of the computer system, The present invention relates to an event aggregation method and an event aggregation program.

  In operation management of a computer system composed of a plurality of components, it is necessary for a user to be able to use an IT (Information Technology) service stably. Therefore, the management server has a function of verifying an event indicating a state defined as a failure, for example, a state in which the user cannot normally receive the IT service or a state in which the user may not be able to normally receive the service. Have.

  For example, as described in Patent Document 1, the management server detects a plurality of events indicating a failure of the computer system or a sign of the failure, and accumulates these events in a database. The management server also has an analysis function for analyzing the causal relationship of a plurality of events.

  The analysis method in the management server uses a rule that uses an event group (related event) related to a failure as a condition and an event (cause event) expressing the cause of the failure as an analysis result. Then, the cause event is extracted from a plurality of events including the related event and the cause event.

  The method described in Patent Document 1 calculates the occurrence rate of a related event defined in the rule condition, and sets the calculation result as the certainty factor of the cause event that is the rule analysis result. The method described in Patent Document 1 can estimate a cause event that is an analysis result of a rule even if all the related events defined in the rule condition do not occur. In the method described in Patent Literature 2, when a large number of events occur due to a plurality of failures, the cause events of a rule including a part of related events defined in the rule condition are sorted in the order of occurrence rate of related events. List all. The method described in Patent Document 3 uses an event pattern in the same time zone on the same day of the week as a rule, and detects an event pattern that appears at a frequency different from that pattern.

US Pat. No. 7,107,185 JP 2012-59063 A Japanese Patent No. 4944391

  In the methods described in Patent Document 1, Patent Document 2, and Patent Document 3, it is necessary to predefine rules that express combinations of all related events that occur due to a failure. However, as the types and sizes of computer system components increase, it is possible to define combinations of some related events that occur due to failures, but to define combinations of all related events that occur due to failures. It is difficult.

  As a result, a related event that is not defined in the rule condition among related events that occur due to a failure may be handled as an event different from the failure. Therefore, the administrator spends a lot of work load to investigate and diagnose whether the event is a new failure event or an existing failure related event with respect to a related event not defined in the rule.

  Therefore, the present invention provides an event aggregating apparatus, an event aggregating method, and an event aggregating method that can easily determine which fault an event that has occurred in a computer system is caused, and that can reduce the work load required for event investigation and diagnosis. The purpose is to provide a program.

  An event aggregating apparatus according to the present invention includes event history information indicating an occurrence history of an event indicating a failure of a computer system or an indication of failure, and metric history information indicating a resource usage state in a computer system as a measured value for each metric. An information acquisition unit acquired from a computer system, a storage unit that stores a system sketch that defines the state of each metric when a failure occurs in the computer system, and a measurement result of each metric indicated by the metric history information from the event history information, And an aggregating unit that extracts events that occur in a time zone in which the state of each metric indicated by the system sketch matches, and aggregates the extracted events as an event group corresponding to the system sketch.

  The event aggregation method according to the present invention includes event history information indicating an occurrence history of an event indicating a failure of a computer system or an indication of failure, and metric history information indicating a resource usage state in the computer system as a measured value for each metric. The measurement result of each metric indicated by the metric history information obtained from the computer system and the event history information matches the state of each metric at the time of failure of the computer system defined in the system sketch stored in the storage unit. It is characterized by extracting events that occurred in a time zone and collecting each extracted event as an event group corresponding to the system sketch.

  An event aggregation program according to the present invention provides a computer with event history information indicating an occurrence history of an event indicating a failure of a computer system or a failure sign, and metric history information indicating a resource usage state in the computer system as a measured value for each metric. Are obtained from the computer system, the event history information, the measurement result of each metric indicated by the metric history information, and each metric at the time of failure of the computer system defined in the system sketch stored in the storage unit. It is characterized in that an event that occurs in a time zone that matches the state is extracted, and a process for aggregating the extracted events as an event group corresponding to the system sketch is executed.

  According to the present invention, it is possible to easily determine which failure is caused by an event that has occurred in a computer system, and it is possible to reduce the work load required for event investigation and diagnosis.

It is a block diagram which shows the structure of 1st Embodiment of an event aggregation system. It is a block diagram which shows the structure of 1st Embodiment of a computer system. It is a block diagram which shows the structure of 1st Embodiment of the computer which a computer system contains. It is a block diagram which shows the structure of 1st Embodiment of a management server. It is explanatory drawing which shows an example of the system topology management table stored in the secondary storage device of the management server. It is explanatory drawing which shows an example of the metric definition table | surface stored in the secondary storage device of the management server. It is explanatory drawing which shows an example of the operation | movement topology management table stored in the secondary storage device of the management server. It is explanatory drawing which shows an example of a system sketch. It is explanatory drawing which shows an example of a system sketch. It is explanatory drawing which shows an example of the system sketch expressing the metric state of a computer group. It is explanatory drawing which shows an example of the system sketch expressing the state of the metric group of a computer group. It is explanatory drawing which shows an example of the metric history table stored in the secondary storage device of the management server. It is explanatory drawing which shows an example of the event history table stored in the secondary storage device of the management server. It is explanatory drawing which shows an example of the system sketch management table stored in the secondary storage device of the management server. It is explanatory drawing which shows an example of the event aggregation result table stored in the secondary storage device of the management server. It is explanatory drawing which shows an example of the event aggregation result table stored in the secondary storage device of the management server. It is a flowchart which shows the system sketch production | generation process which the system sketch production | generation module of a management server performs. It is a flowchart which shows the event aggregation process which the event aggregation process module of a management server performs. It is explanatory drawing which shows an example of the display screen which shows an event aggregation result. It is a block diagram which shows the minimum structure of the event aggregation apparatus by this invention. It is a block diagram which shows the other minimum structure of the event aggregation apparatus by this invention.

Embodiment 1. FIG.
A first embodiment of the present invention will be described below with reference to the drawings.

  This embodiment is merely an example for realizing the present invention, and does not limit the technical scope of the present invention.

  Moreover, the same number is given and demonstrated about a common structure in each figure.

  Further, in the description of the present embodiment, there is a place where “software”, “program”, or “module” is described as an operation subject. These portions may be read as processing whose main operation is a processor. The reason is that software, a program, or a module is executed by a processor to perform a predetermined process using a memory and a communication interface (communication control device).

  In addition, the process whose main operation is a program or module may be a process performed by a computer such as a management server or an information processing apparatus. Further, part or all of the program may be realized by dedicated hardware. Various programs may be installed in each computer by a program distribution server or a storage medium.

  FIG. 1 is a block diagram showing the configuration of the first embodiment of the event aggregation system.

  Here, processing for aggregating events for each failure of the computer system will be described.

  The distributed system shown in FIG. 1 includes a computer system 10, a management server 20, a management terminal 30, user terminals 40-1 to 40-n, and IP (Internet Protocol) switches 50-1 and 50-2. Have. The computer system 10 and the user terminals 40-1 to 40-n are connected via a network 60-1. The computer system 10, the management server 20, and the management terminal 30 are connected via a network 60-2.

  The computer system 10 receives file I / O requests from the user terminals 40-1 to 40-n, and executes access to a storage device such as a magnetic disk in response to the file I / O requests. In addition, the computer system 10 generates a monitoring information log indicating the resource usage status and the operating status of the application and operating system.

  The user terminals 40-1 to 40-n receive a service execution request from a user or the like, and transmit a file I / O request to the computer system 10. In addition, the user terminals 40-1 to 40-n receive the execution result of the file I / O request by the computer system 10.

  The management server 20 refers to the monitoring information log held by the computer system 10 and acquires a plurality of events indicating a failure of the computer system 10 or a sign of the failure. The management server 20 aggregates these events for each failure, and stores the aggregation result in the storage device.

  The management terminal 30 communicates with a UI (User Interface) display processing module of the management server via the network 60-2. The management terminal 30 displays various information acquired by the communication on the output device of the own terminal. The administrator refers to various information displayed on the management terminal 30 and uses the input device of the management terminal 30 to make various settings for the management server 20, the IP switches 60-1, 60-2, and the computer system 10. Do work.

  FIG. 2 is a block diagram illustrating a configuration of the computer system 10 according to the first embodiment.

  The computer system 10 includes a front end node 11 and processing nodes 12-1 to 12-n. In this embodiment, these nodes are connected via a network 14 including an IP switch 13. In addition, although one front end node is illustrated in FIG. 2, there may be any number of front end nodes.

  The front end node 11 is a computer such as a communication terminal, for example. The front end node 11 is connected to the user terminals 40-1 to 40-n. The front-end node 11 is a computer that receives a service execution request from the user terminals 40-1 to 40-n and transfers it to a processing node. Further, the front end node 11 transfers the execution results of the services by the processing nodes 12-1 to 12-n to the user terminals 40-1 to 40-n.

  The processing nodes 12-1 to 12-n are computers such as communication terminals, for example. The processing nodes 12-1 to 12-n are connected to the management server 20 and the management terminal 30. The processing nodes 12-1 to 12-n execute processing corresponding to the service. The processing nodes 12-1 to 12-n may be virtual computers constructed on a computer.

  The computer system 10 is realized by, for example, a cloud computing system, a grid computing system, a parallel distributed computer, a super computer, a server computer, a personal computer, and a system that arbitrarily combines these.

  FIG. 3 is a block diagram showing the configuration of the first embodiment of a computer (front end node, processing node) included in the computer system 10.

  The computer 100 includes a communication I / F (interface) 110, a processor 120, a memory 130, and a secondary storage device 140. The computer 100 may include an output device 150 such as a display for outputting a processing result, and an input device 160 such as a keyboard for an administrator to input an instruction. Each component of the computer 100 is connected to each other via a circuit such as an internal bus.

  The communication I / F 110 connects the computer 100 to a network.

  The processor 120 is, for example, a CPU.

  The memory 130 is, for example, a cache memory. In the present embodiment, data processing software 131 and monitoring software 132 are stored in the memory 130.

  The data processing software 131 executes part or all of the processing corresponding to the service. In this embodiment, the data processing software 131 is an application and an operating system.

  The application uses the storage area provided by the operating system to input / output data to / from the storage area.

  The operating system executes processing for causing an application to recognize the processor as a plurality of logical processors. In addition, the operating system executes processing for causing the application to recognize the memory as a plurality of logical memories. The operating system also executes processing for causing the application to recognize the secondary storage device as a plurality of logical secondary storage areas.

  The monitoring software 132 monitors the usage state of the resources of the computer 100 at predetermined intervals, and stores the monitoring result in the monitoring information log. Here, the resources include the processor 120 or logical processor, the memory 130 or logical memory, the secondary storage device 140 or logical secondary storage area, and the communication I / F 110.

  In addition, the monitoring software 132 monitors the operating status of the data processing software 131, that is, the application and the operating system, and stores the monitoring result in the monitoring information log at predetermined intervals.

  The secondary storage device 140 is a storage device such as a hard disk drive. The secondary storage device 140 includes a semiconductor memory, a magnetic disk, or both a semiconductor memory and a magnetic disk. The secondary storage device 140 stores a monitoring information log.

  The monitoring information log is information including metric history information and event history information. The metric history information and the event history information are information for updating a metric history table and an event history table held by the management server 20, which will be described later. Hereinafter, the expression “xxx table” is used, but these are not limited to a specific data structure. Therefore, expressions such as “xxx table”, “xxx list”, “xxx database”, “xxx queue”, and other expressions may be used.

  FIG. 4 is a block diagram illustrating a configuration of the management server 20 according to the first embodiment.

  The management server 20 includes a communication I / F 21, a processor 22, a memory 23, and a secondary storage device 24. The management server 20 may include an output device 25 such as a display for outputting processing results, and an input device 26 such as a keyboard for an administrator to input instructions. The output device 25 and the input device 26 may be separate devices or may be included in one device. Each component of the management server 20 is connected to each other via a circuit such as an internal bus.

  The communication I / F 21 connects the management server 20 to the network.

  The processor 22 is, for example, a CPU.

  The memory 23 is, for example, a cache memory.

  The memory 23 includes a program control module 231, a configuration information acquisition module 232, a performance information acquisition module 233, an event acquisition module 234, a UI display processing module 235, a system sketch generation module 236, and an event aggregation processing module 237. Is stored.

  The secondary storage device 24 is a storage device such as a hard disk drive. The secondary storage device 24 includes a semiconductor memory, a magnetic disk, or both a semiconductor memory and a magnetic disk.

  The secondary storage device 24 stores a system topology management table, a metric definition table, an operation topology management table, a metric history table, an event history table, a system sketch management table, and an event aggregation result table.

  The program control module 231 instructs the configuration information acquisition module 232 to acquire system topology management information from a computer or IP switch of a computer system to be managed at predetermined intervals.

  Further, the program control module 231 instructs the performance information acquisition module 233 to acquire metric history information from a computer or an IP switch of a computer system to be managed at every predetermined period.

  Further, the program control module 231 instructs the event acquisition module 234 to acquire event history information from a computer or an IP switch of a computer system to be managed at every predetermined period.

  In addition, the program control module 231 instructs the system sketch generation module 236 to generate system sketch management information at predetermined intervals.

  Further, the program control module 231 instructs the event aggregation processing module 237 to update the event aggregation result information every predetermined period.

  The configuration information acquisition module 232 acquires system topology management information from the computer and IP switch of the computer system to be managed, and updates the system topology management table.

  The performance information acquisition module 233 acquires metric history information from the computer and IP switch of the computer system to be managed, and updates the metric history table.

  The event acquisition module 234 acquires event history information from the computer and IP system of the computer system to be managed, and updates the event history table.

  The UI display processing module 235 displays various information stored in the secondary storage device 24 via the output device 25 in response to a request from the administrator via the input device 26.

  The system sketch generation module 236 refers to the system topology management table, the metric definition table, and the metric history table, executes a system sketch generation process described later, and updates the system sketch management table.

  The event aggregation processing module 237 refers to the system topology management table, the metric definition table, the operation topology management table, the metric history table, the event history table, the system sketch management table, and the event aggregation result table, and executes event aggregation processing described later. And update the event aggregation result table.

  Each module may be provided as a hardware module instead of a software module stored in the memory. Further, the processing performed by each module may be provided as one or more program codes, or a plurality of modules may be provided as one programmed code. In the description, “module” may be read as “program”.

  The management server 20 includes a serial interface or an Ethernet (registered trademark) interface as a communication I / F 21, and a management terminal 30 having a display, a keyboard, or a pointer device is connected to the communication I / F 21 as a display computer. Good. Thereby, the management server 20 can receive the input by transmitting the display information to the display computer and displaying the information on the display computer or receiving the input information from the display computer. .

  FIG. 5 is an explanatory diagram showing an example of a system topology management table stored in the secondary storage device 24 of the management server 20.

  As shown in FIG. 5, the system topology management table includes information indicating “system topology key ID”, “computer group ID”, “computer ID”, and “computer part ID”.

  “System topology key ID” is an identifier of a record in the system topology management table. “Computer group ID” is an identifier of a computer group of a computer system to be managed by the management server 20. “Computer ID” is an identifier of a computer to be managed by the management server 20. The “computer part ID” is an identifier of a part that constitutes the inside of the computer to be managed by the management server 20.

  For example, the record having the system topology key ID “STKeyID1” shown in FIG. 5 indicates that the computer group “NODEGrp1” includes the computer “NODE1” and the computer “NODE1” has a processor.

  FIG. 6 is an explanatory diagram showing an example of a metric definition table stored in the secondary storage device 24 of the management server 20.

  The metric definition table is information for defining measurement items (metrics). Specifically, as shown in FIG. 6, “metric key ID”, “metric group ID”, “computer part ID”, “metric ID”, “metric upper limit abnormal threshold” and “metric lower limit abnormal threshold” are indicated. Contains information.

  The “metric key ID” is an identifier of a record in the metric definition table. The “metric group ID” is an identifier of a metric group to be monitored by the computer to be managed by the management server 20. The “computer part ID” is an identifier of a part that constitutes the inside of the computer to be managed by the management server 20. The “metric upper limit abnormal threshold value” is a threshold value that indicates the upper limit of the normal range of the metric value that is the monitoring target of the part that constitutes the inside of the computer that is the management target of the management server 20. The “metric lower limit abnormality threshold value” is a threshold value that indicates the lower limit of the normal range of the metric value that is the monitoring target of the part that constitutes the inside of the computer that is the management target of the management server 20.

  For example, the record whose metric key ID is “MKeyID1” shown in FIG. 6 indicates that the metric to be monitored belongs to the metric group of the resource and is a metric of the unit time usage rate of the processor. Further, it indicates that an upper limit abnormality is detected when the value of the unit usage rate of the processor exceeds 80%.

  FIG. 7 is an explanatory diagram illustrating an example of an operation topology management table stored in the secondary storage device 24 of the management server 20.

  As shown in FIG. 7, the operation topology management table includes information indicating “operation topology key ID”, “operation domain”, “operation failure classification”, and “system sketch map ID (SSMap ID)”.

  “Operation topology key ID” is an identifier of a record in the operation topology management table. “Operation domain” is an identifier of the operation area of the computer system to be managed by the management server 20. The “operation failure classification” is an identifier of a failure that occurs in the computer system that is the management target of the management server 20. “SSMapID” is an identifier of a system sketch representing the state of each metric of each computer in the operation failure category. Hereinafter, a system sketch whose identifier is “SSMapIDx-x” is expressed as a system sketch “SSMapIDx-x”.

  A system sketch is a rule that expresses the state of a metric when a failure occurs. Specifically, the system sketch defines a metric state when a failure occurs in each computer of the computer system to be managed by the management server 20. In the present embodiment, the metric states include “normal”, “upper limit error”, “above lower limit”, “all state match”, and “not applicable”.

  “Normal” indicates a state where the metric value is in a normal range.

  “Upper limit abnormality” indicates a state in which the metric value exceeds a threshold value indicating the upper limit of the normal range.

  “Lower limit abnormality” indicates a state in which the metric value falls below a threshold value indicating the lower limit of the normal range.

  “All state coincidence” indicates that the metric value is “normal”, “upper limit error”, or “lower limit error”. In the system sketch, “all state coincidence” is represented by “*”.

  “Not applicable” indicates that the metric is not subject to the rule. In the system sketch, “not applicable” is represented by “−”.

  For example, in the record shown in FIG. 7 where the operation topology key ID is “OTKeyID1”, the failure of “response degradation” in the “Application” operation area indicates that the state of each metric of each computer is the system sketch “SSMapID1-1”. ”Or“ SSMapID1-2 ”.

  8 and 9 are explanatory diagrams illustrating an example of a system sketch.

  FIG. 8 is a rule that expresses the state of each metric of each computer at the time of response deterioration in the operation area of “Application”.

  The system sketch “SSMapID1-1” shown in FIG. 8 indicates the state of each metric of the computer “NODE1” and the computer “NODE2” when the response processing of the data processing software “SW1” of the computer system 10 to be managed by the management server 20 is deteriorated. Is a rule expressing the state of each metric. The system sketch “SSMapID1-2” illustrated in FIG. 8 is a rule that represents the state of each metric of each computer when the response processing of the data processing software “SW2” of the computer system 10 to be managed by the management server 20 is deteriorated.

  For example, the system sketch “SMCapID1-1” shown in FIG. 8 has the values of the metric “MKeyID1”, the metric “MKeyID2”, and the metric “MKeyID3” in the computer “NODE1”, and the metric “MKeyID4”. This indicates that the value is “upper limit error” and the metric “MKeyID5” is “not applicable”. Further, the computer “NODE2” has the values of the metric “MKeyID1”, the metric “MKeyID2”, and the metric “MKeyID3” “normal”, the metric “MKeyID4” “not applicable”, and the metric “MKeyID5”. Indicates one of the following states: “Normal”, “Upper limit error”, or “Lower limit error”.

  FIG. 9 is a rule representing the state of each metric of each computer at the time of a resource failure in the “Infrastructure” operation area.

  The system sketches “SSMapID2-1” and “SSMapID2-4” shown in FIG. 9 indicate the state of each metric of the computer “NODE1” at the time of a resource failure of the processor (CPU) of the computer system to be managed by the management server 20. This is a rule expressing the state of each metric of the computer “NODE2”. The system sketches “SSMapID2-2” and “SSMapID2-5” illustrated in FIG. 9 are rules that express the state of each metric of each computer when a memory resource failure occurs in the computer system to be managed by the management server 20. The system sketches “SSMapID2-3” and “SSMapID2-6” shown in FIG. 9 are rules representing the state of each metric of each computer when a disk resource failure occurs in the computer system to be managed by the management server 20.

  For example, in the system sketch “SSMapID2-1” shown in FIG. 9, the value of the metric “MKeyID1” in the computer “NODE1” has an upper limit abnormality, and the values of the metric “MKeyID2”, the metric “MKeyID3”, and the metric “MKeyID4” Indicates “normal”, “upper limit error”, or “lower limit error”, and the metric “MKeyID5” is “not applicable”. In addition, in the computer “NODE2”, the values of the metric “MKeyID1”, the metric “MKeyID2”, the metric “MKeyID3”, and the metric “MKeyID5” are either “normal”, “upper limit abnormal”, or “lower limit abnormal”. Thus, the metric “MKeyID4” is excluded.

  The system sketch may be a rule that expresses the state of each metric of each computer group when a failure occurs in a computer system that is a management target of the management server 20. FIG. 10 is an explanatory diagram illustrating an example of a system sketch that represents a metric state of a computer group. For example, as illustrated in FIG. 10, the system sketch may be a rule expressing the state of each metric in the computer group “NODEGrp1”. In this case, the system sketch “SSMapID1-3” illustrated in FIG. 10 is a rule that expresses the system sketch “SSMapID1-1” and the system sketch “SSMapID1-2” illustrated in FIG.

  Furthermore, the system sketch may be a rule that expresses the state of each metric group of each computer group in the event of a failure that occurs in a computer system managed by the management server. FIG. 11 is an explanatory diagram showing an example of a system sketch expressing the state of a metric group of a computer group. For example, as shown in FIG. 11, the rule may represent a state of a metric group “resource”, a metric “MKeyID4”, and a metric “MKeyID5” in the computer group “NODEGrp1”. In this case, the system sketch “SSMapID2-7” shown in FIG. 11 is a rule expressing the system sketches from the system sketch “SSMapID2-1” to the system sketch “SSMapID2-6” shown in FIG.

  FIG. 12 is an explanatory diagram illustrating an example of a metric history table stored in the secondary storage device 24 of the management server 20.

  As shown in FIG. 12, the metric history table includes “metric history key ID”, “system topology key ID”, “metric key ID”, “measurement date / time”, “measured value”, and “system sketch generation processed flag”. Contains information indicating.

  The “metric history key ID” is an identifier of a record in the metric history table. “System topology key ID” is an identifier of a record in the system topology management table. The “metric key ID” is an identifier of a record in the metric definition table. “Measurement date and time” is the measurement date and time of the metric. “Measured value” is a measured value of a metric. The “system sketch generation process completed flag” is a flag indicating whether or not the system sketch generation process for the metric history table record has been completed.

  For example, the record having the metric history key ID “MH History 1” shown in FIG. 12 has the measured value of the processor unit time utilization rate “40%” in the computer “NODE 1” of the computer group “NO DEGrp1”. Indicates that the sketch generation process has been completed. In addition, the measurement date / time is “2012/1/1/1 13:00:00”.

  FIG. 13 is an explanatory diagram illustrating an example of an event history table stored in the secondary storage device 24 of the management server 20.

  As shown in FIG. 13, the event history table is information indicating “event key ID”, “occurrence date / time”, “system topology key ID”, “event ID”, “event message”, and “event aggregation processing flag”. including.

  “Event key ID” is an identifier of a record in the event history table. “Occurrence date and time” is the occurrence date and time of the event. The “system topology key ID” is a system topology key ID corresponding to the occurrence location of the event. “Event ID” and “event message” are an identifier of the message notified by the event and its contents. The “event aggregation processing completed flag” is a flag indicating whether or not the event aggregation processing for the event has been completed.

  For example, the record with the event key ID “EventKeyID1” shown in FIG. 13 is the data processing software “SW1” of the computer “NODE1” in the computer group “NODEGRP1” at “2012/1/1 13:05:00”. It indicates that the event ID of the event that has occurred is “SW1Event4” and the event message is “SW1 error”. It also indicates that the event has been subjected to event aggregation processing. Hereinafter, an event history whose identifier is “EventKeyIDx” is expressed as an event history “EventKeyIDx”.

  FIG. 14 is an explanatory diagram showing an example of a system sketch management table stored in the secondary storage device 24 of the management server 20.

  As shown in FIG. 14, the system sketch management table includes information indicating “Run Time System Sketch (RSS) key ID”, “metric key ID list”, “start date and time”, and “end date and time”.

  “RSS key ID” is an identifier of a record in the system sketch management table. The “metric history key ID list” is a set of metric history records that are targets of system sketch generation processing. The “start date / time” is the start date / time of the system sketch generation process. The “end date / time” is the end date / time of the system sketch generation process.

  For example, the record whose RSS key ID is “RSSMapKeyID1” shown in FIG. 14 is a time zone metric from “2012/1/1 13:00:00” to “2012/1/1 13:09:59”. Are metrics from “MH History 1” to “MH History 8”.

  15 and 16 are explanatory diagrams illustrating an example of an event aggregation result table stored in the secondary storage device 24 of the management server 20.

  As shown in FIGS. 15 and 16, the event aggregation result table includes information indicating “event aggregation group key ID”, “operation topology key ID”, “event key ID”, and “status”.

  “Event aggregation group key ID” is an identifier of a record in the event aggregation result table. “Operation topology key ID” is an identifier of a record in the operation topology management table. “Event key ID” is an identifier of a record in the event history table. “Status” indicates the start state of the administrator for the event aggregation group.

  For example, in the record shown in FIG. 15 in which the event aggregation group key ID is “EventGroupKeyID1”, the event group (event group) in the response degradation in the operation area “Application” corresponds to the event corresponding to the event key history “EventKeyID1”. , The event corresponding to the event history “EventKeyID2” and the event corresponding to the event history “EventKeyID3”. Further, it indicates that the manager has not started the record. As shown in FIG. 13, the event corresponding to the event key history “EventKeyID1” is an event that occurs in the data processing software “SW1” of the computer “NODE1” and whose message is “SW1 error”. The event corresponding to the event key history “EventKeyID2” is an event that occurs in the data processing software “SW1” of the computer “NODE1” and whose message is “response abnormality”. The event corresponding to the event key history “EventKeyID3” is an event that occurs in the data processing software “SW2” of the computer “NODE2” and whose message is “SW2 error”.

  Next, the operation of this embodiment will be described.

  FIG. 17 is a flowchart showing a system sketch generation process executed by the system sketch generation module 236 of the management server 20.

  In the present embodiment, before the system sketch generation module 236 executes the system sketch generation process, the administrator stores the system topology management table and the metric definition table in the secondary storage device 24 in advance.

  The system sketch generation module 236 acquires a list of all computer part IDs of computers to be managed from the system topology management table. Further, the system sketch generation module 236 acquires a metric key ID that matches the acquired computer part ID from the metric definition table (step S101).

  The system sketch generation module 236 acquires, from the metric history table, a metric history record that has the system sketch generation processing flag “No” and includes the metric key ID acquired in step S101. At this time, the system sketch generation module 236 acquires at least one record for each metric key ID from the oldest in time series, and updates the system sketch generation processing completed flag of the acquired record to “Yes” (step) S102).

  The system sketch generation module 236, from the metric history table after the system sketch generation processing flag update in step S102, has the system sketch generation processing flag “No”, and includes the metric history including the metric key ID acquired in step S101. Get a record. The system sketch generation module 236 acquires the oldest record from the acquired records (step S103).

  The system sketch generation module 236 sets the set of metric history records acquired in step S102 as a target of the system sketch generation process. That is, the set of metric history records is registered in the metric key ID list of the system sketch management record. In addition, the system sketch generation module 236 registers the metric measurement date and time of the oldest chronological record in the set of metric history records acquired in step S102 as the system sketch start date and time of the system sketch management record. Also, the date and time one second before the metric measurement date and time of the metric history record acquired in step S103 is registered as the system sketch end date and time of the system sketch management record. The system sketch generation module 236 stores the system sketch management record in the system sketch management table together with the record identifier (step S104).

  FIG. 18 is a flowchart showing the event aggregation processing executed by the event aggregation processing module 237 of the management server 20.

  Before the event aggregation processing module 237 executes the event aggregation processing, the administrator stores the system topology management table, the metric definition table, and the operation topology management table in the secondary storage device 24 in advance.

  The event aggregation processing module 237 acquires a list of event history records whose event aggregation processing completed flag is “No” from the event history table (step S201).

  The event aggregation processing module 237 repeatedly executes the processes shown in steps S203 to S210 for each record acquired in step S201 (step S202). If there is no record to be processed, the event aggregation process ends.

  The event aggregation processing module 237 refers to the event aggregation result table, and determines whether there is an event history record registered in the event key ID list of each event aggregation group that matches the processing target record. Confirmation (step S203). At this time, the event aggregation processing module 237 includes the event whose record to be processed includes the system topology key ID registered in the system topology management table and is registered in the event key ID list of the event aggregation group. When the same event ID as the history record is included, it is determined that there is an event history record that matches the record to be processed.

  If there is a matching event history record (YES in step S204), the event aggregation processing module 237 updates the event aggregation result table. Specifically, the identifier (event key ID) of the record to be processed is added to the event key ID list of the event aggregation group that has a matching event history record (step S205).

  If there is no matching event history record (NO in step S204), the event aggregation processing module 237 acquires a metric history key ID list including the occurrence date and time of the event history record to be processed from the system sketch management table. (Step S206).

  The event aggregation processing module 237 obtains an SSMap ID corresponding to each operational topology key ID from the operational topology management table. The event aggregation processing module 237 checks whether or not the metric state of each metric history record in the metric history key ID list matches the state indicated by the system sketch corresponding to the acquired SSMap ID (step S207). For example, since the metric state indicated by the metric history record “MHistory1-MHistory8” of the system sketch management record “RSMapKeyID1” is only the metric “MKeyID4” in the computer “NODE1”, the system sketch “SSMAPID1-1”. It is determined that it matches the state indicated by.

  If the metric state of each metric history record matches the state indicated by the system sketch (YES in step S208), the event aggregation processing module 237 identifies the identifier (SSMapID) of the operation topology in which the system sketch identifier (SSMapID) is registered ( A new event aggregation result record having the operation topology key ID) and the identifier of the event history record to be processed (event key ID) as elements is generated and registered in the event aggregation result table (step S209).

  When the metric state of each metric history record and the state indicated by the system sketch do not match (NO in step S208), the event aggregation processing module 237 operates the operation topology key assigned to the operation topology whose failure classification is “other failures”. A new event aggregation result record having an ID (for example, “OTKeyID99”) and the event history record (event key ID) as elements is registered in the event aggregation result table (step S210).

  The event aggregation processing module 237 returns to the process of step S203 after executing the process of step S205, executing the process of step S209, or executing the process of step S210 (step S211).

  FIG. 19 is an explanatory diagram illustrating an example of a display screen showing an event aggregation result.

  The management server 20, specifically, the UI display processing module 235 transmits display information to the display computer, and displays a display screen showing the event aggregation result on a display or the like provided in the display computer.

  As shown in FIG. 19, the event aggregation result stored in the event aggregation result table is displayed on the display screen showing the event aggregation result. The management server 20 may display any of the event history information corresponding to the record identifier of the event history table in the event list field of the event aggregation result display screen. In addition, the management server 20 may provide a column for displaying only the number of records in the event history table on the event aggregation result display screen.

  As described above, in the present embodiment, according to the rule (system sketch) expressing the state of each metric when a failure occurs in the computer system to be managed by the management server by the event aggregation processing, Aggregate and group events that occur due to failures. Then, the event aggregation result is presented to the administrator. As a result, it is possible for the administrator to easily determine which failure event, and to reduce the work load required for event investigation and diagnosis.

  In addition, as the scale of a computer system to be managed increases, the possibility of simultaneous failures occurring at a plurality of locations increases. Therefore, when the present invention is applied to a large-scale computer system, the effects of the present invention can be further enjoyed.

  FIG. 20 is a block diagram showing the minimum configuration of the event aggregation device according to the present invention. FIG. 21 is a block diagram showing another minimum configuration of the event aggregation device according to the present invention.

  As shown in FIG. 20, the event aggregating apparatus (corresponding to the management server 20 shown in FIGS. 1 and 4) is a failure of the computer system (corresponding to the computer system 10 shown in FIGS. 1 and 2) or a sign of the failure. Information acquisition unit 1 (management server shown in FIG. 4) that acquires event history information indicating an occurrence history of events indicating metric history information that represents a resource usage state in a computer system as a measured value for each metric from the computer system 20 corresponding to the program control module 231, the performance information acquisition module 232, and the event acquisition module 234 stored in the memory 23 in FIG. 20, and a storage unit that stores a system sketch that defines the state of each metric when a failure occurs in the computer system 2 (the management service shown in FIG. Corresponding to the secondary storage device 24 in the bar 20), and the event history information, the event that occurred in the time zone in which the measurement result of each metric indicated by the metric history information matches the state of each metric indicated by the system sketch. The aggregating unit 3 (corresponding to the program control module 231 and the event aggregation processing module 237 stored in the memory 23 in the management server 20 shown in FIG. 4) that extracts and aggregates each extracted event as an event group corresponding to the system sketch. ).

  According to such a configuration, events that occur due to the failure can be aggregated according to a rule that expresses the state of each metric when the failure occurs. Therefore, it is possible to easily determine which fault the generated event is caused by, and it is possible to reduce the work load required for the investigation and diagnosis of the event.

  In the above embodiment, the following event aggregation device is also disclosed.

(1) As shown in FIG. 21, a display processing unit 4 that generates display information for displaying an aggregated event group (a UI display processing module 235 stored in the memory 23 in the management server 20 shown in FIG. 4). Event aggregation device.

  According to such a configuration, by outputting the display information to a display computer or the like, an event that occurs due to a failure in the computer system can be presented to the administrator. In this way, events that occur in the failure are aggregated into event groups that match the status of each metric of the failure, and the result of the aggregation is displayed on a display computer, etc. It is possible to easily determine whether it is present, and it is possible to reduce the workload required for event investigation and diagnosis.

(2) As shown in FIG. 21, for each predetermined period, the system sketch generation unit 5 (in the management server 20 shown in FIG. 4) generates a system sketch management record including a set of metric history information acquired during the predetermined period. The aggregation unit 3 includes a measurement result of each metric indicated by the set of metric history information included in the system sketch management record, and a storage unit, which corresponds to the program control module 231 and the system sketch generation module 236 stored in the memory 23. When the state of each metric indicated by any one of the system sketches stored in the section 2 matches, an event that occurred in the time zone when the system sketch management record is generated is defined as an event group corresponding to the system sketch. Event aggregator that aggregates.

  According to such a configuration, it is possible to accurately determine whether the event is a new failure event or an existing failure event with respect to an undefined related event, and the events are aggregated more efficiently. be able to.

DESCRIPTION OF SYMBOLS 1 Information acquisition part 2 Memory | storage part 3 Aggregation part 4 Display processing part 5 System sketch production | generation part 10 Computer system 11 Front-end node 12-1 to 12-n Processing node 13 IP switch 14 Network 20 Management server 21 Communication I / F
DESCRIPTION OF SYMBOLS 22 Processor 23 Memory 231 Program control module 232 Configuration information acquisition module 233 Performance information acquisition module 234 Event acquisition module 235 UI display processing module 236 System sketch generation module 237 Event aggregation processing module 24 Secondary storage device 25 Output device 26 Input device 30 Management Terminal 40-1 to 40-n User terminal 50-1, 50-2 IP switch 60-1, 60-2 Network 100 Computer 110 Communication I / F
120 processor 130 memory 131 data processing software 132 monitoring software 140 secondary storage device 150 output device 160 input device

Claims (9)

Information for acquiring from the computer system event history information indicating the occurrence history of an event indicating a failure or a sign of failure of the computer system, and metric history information representing a resource usage state in the computer system as a measured value for each metric. An acquisition unit;
A storage unit for storing a system sketch that defines the state of each metric when a failure occurs in the computer system;
From the event history information, an event that occurred in a time zone in which the measurement result of each metric indicated by the metric history information matches the state of each metric indicated by the system sketch is extracted, and each extracted event is extracted from the system sketch. An event aggregating apparatus comprising: an aggregating unit that aggregates as an event group corresponding to. The event aggregation device according to claim 1, further comprising: a display processing unit that generates display information for displaying the aggregated event group. A system sketch generation unit that generates a system sketch management record including a set of metric history information acquired during the predetermined period for each predetermined period,
The aggregation unit, when the measurement result of each metric indicated by the set of metric history information included in the system sketch management record matches the state of each metric indicated by any one of the system sketches stored in the storage unit, The event aggregating apparatus according to claim 1 or 2, wherein events occurring in a time zone when the system sketch management record is generated are aggregated as an event group corresponding to the system sketch. Event history information indicating an occurrence history of an event indicating a failure of the computer system or an indication of a failure, and metric history information indicating a resource usage state in the computer system as a measured value for each metric are acquired from the computer system,
From the event history information, in a time zone in which the measurement result of each metric indicated by the metric history information matches the state of each metric at the time of failure of the computer system defined in the system sketch stored in the storage unit An event aggregation method characterized by extracting generated events and aggregating each extracted event as an event group corresponding to the system sketch. The event aggregation method according to claim 4, wherein screen information for displaying the aggregated event group is generated. For each predetermined period, generate a system sketch management record including a set of metric history information acquired during the predetermined period,
When the measurement result of each metric indicated by the set of metric history information included in the system sketch management record matches the state of each metric indicated by any one of the system sketches stored in the storage unit, the system sketch management concerned The event aggregation method according to claim 4 or 5, wherein events occurring in a time zone when the record is generated are aggregated as an event group corresponding to the system sketch. On the computer,
Processing for acquiring event history information indicating an occurrence history of an event indicating a failure or an indication of a failure of the computer system, and metric history information indicating a resource usage state in the computer system as a measured value for each metric from the computer system When,
From the event history information, in a time zone in which the measurement result of each metric indicated by the metric history information matches the state of each metric at the time of failure of the computer system defined in the system sketch stored in the storage unit An event aggregation program for extracting generated events and executing the process of aggregating each extracted event as an event group corresponding to the system sketch. On the computer,
The event aggregation program according to claim 7, wherein a process of generating screen information for displaying the aggregated event group is executed. On the computer,
For each predetermined period, a process of generating a system sketch management record including a set of metric history information acquired during the predetermined period;
When the measurement result of each metric indicated by the set of metric history information included in the system sketch management record matches the state of each metric indicated by any one of the system sketches stored in the storage unit, the system sketch management concerned The event aggregation program according to claim 7 or 8, wherein the event aggregation program executes a process of aggregating events that occurred in a time zone when a record is generated as an event group corresponding to the system sketch.

Images