JP2018160186A - Monitoring program, monitoring method, and monitoring device - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a monitoring device capable of selectively suppressing notification of information related to an event occurring as a result of processing related to a business server group.SOLUTION: A monitoring device 10 has a communication part 11, a storage part 12, and a control part 15. The communication part receives a monitor event from a business server group, receives a filter from an operation management device, and transmits the collected monitor event to the operation management device. A monitor event DB 13 stores the monitor event detected by the business server group, and a filtering DB 14 stores a filter for filtering the monitor event. The control part has a monitor event management part 16 and a filtering part 17. The monitor event management part detects a monitor event occurring in each server and registers it in the monitor event DB. The filtering part uses the filter stored in the filtering DB to determine whether or not the monitor event is to be output, and in a case where the monitor event is not to be output, suppresses notification of information related to the monitor event.SELECTED DRAWING: Figure 4

Description

  The present invention relates to a monitoring program, a monitoring method, and a monitoring apparatus.

  In large-scale IT (Information Technology) systems such as data centers, monitoring products are introduced to monitor the stable operation of business servers. For example, when an abnormality occurs in a business server, a monitoring event is issued by the monitoring product, and the operator determines the countermeasure after confirming the contents of the monitoring event. Further, for example, even in an environment where a plurality of business applications are aggregated and operated on middleware by server aggregation, each business application is monitored by a monitoring product.

  In such an IT system and the like, the number and number of operations management operations such as maintenance may increase, and each operation management operation is automated as a workflow. On the other hand, when a server is shut down for maintenance, a large number of monitoring events are notified, so the operator must check all the monitoring events one by one and respond to other failures. There is a high possibility of delays and oversights. In recent years, when performing maintenance or the like, the monitoring product function has been configured to suppress monitoring event notification by setting monitoring suppression for the maintenance target server.

JP 2012-234382 A JP 2014-32598 A International Publication No. 2004/061681

  However, when maintenance is performed without setting monitoring suppression, a situation may occur in which an obvious monitoring event due to an operation management operation and a monitoring event due to a failure occur. As a result, there is a high possibility that delays in overcoming other failures and oversight will occur. For example, if the monitoring suppression setting by the person in charge of monitoring is not in time for emergency maintenance, or if the affected range of maintenance is not correctly understood, notification of a trivial monitoring event is executed.

  Also, automation of operation management operations is performed with priority on the effective part, and not all are automated automatically, so there is a mixture of areas that are automated as workflows and areas that are not automated. The state is increasing. In such a situation, if the monitoring suppression is set, not only the obvious monitoring event generated by the workflow but also the monitoring event not related to the workflow generated during that time is suppressed.

  In one aspect, an object is to provide a monitoring program, a monitoring method, and a monitoring apparatus that can selectively suppress notification of information related to an event caused by processing related to operation.

  In the first proposal, when the monitoring program acquires an event related to server monitoring, the monitoring program causes the terminal to execute processing for notifying the terminal of the acquired information related to the event. The monitoring program causes the computer to execute processing for acquiring the identification information of the processing related to the server operation and the event that occurred during the execution of the processing related to the server operation among the events related to the server monitoring. The monitoring program refers to a storage unit that stores an event generated due to a process related to server operation in association with the identification information of the process, and is associated with the acquired identification information of the process. Causes the event to be identified. The monitoring program causes the computer to execute processing for suppressing notification of information related to the identified event among the acquired events.

  According to one embodiment, it is possible to selectively suppress notification of information related to an event caused by processing related to operation.

FIG. 1 is a diagram illustrating an example of the overall configuration of a system according to the first embodiment. FIG. 2 is a schematic diagram illustrating a system configuration tree according to the first embodiment. FIG. 3 is a schematic diagram illustrating a workflow according to the first embodiment. FIG. 4 is a functional block diagram of the functional configuration of the monitoring apparatus according to the first embodiment. FIG. 5 is a diagram illustrating an example of monitoring events stored in the monitoring event DB. FIG. 6 is a functional block diagram of the functional configuration of the operation management apparatus according to the first embodiment. FIG. 7 is a diagram illustrating an example of a workflow stored in the workflow management DB. FIG. 8 is a diagram illustrating an example of variables stored in the variable management DB. FIG. 9 is a diagram illustrating an example of instances stored in the instance management DB. FIG. 10 is a diagram illustrating an example of event patterns stored in the event pattern management DB. FIG. 11 is a diagram illustrating an example of a transition route stored in the transition route management DB. FIG. 12 is a diagram illustrating an example of pattern data stored in the pattern data management DB. FIG. 13 is a diagram illustrating an example of filters stored in the filtering management DB. FIG. 14 is a flowchart showing the flow of workflow execution processing. FIG. 15 is a flowchart showing the overall flow of event pattern update processing. FIG. 16 is a diagram for explaining division of event grouping. FIG. 17 is a diagram for explaining generation of an event group. FIG. 18 is a diagram for explaining an event group group. FIG. 19 is a diagram for explaining the generated event pattern. FIG. 20 is a flowchart showing the flow of the matching process. FIG. 21 is a flowchart showing the flow of the matching process. FIG. 22 is a diagram for explaining the result of the coincidence determination. FIG. 23 is a diagram for explaining filtering. FIG. 24 is a flowchart showing the flow of event pattern update processing. FIG. 25 is a flowchart showing a flow of event pattern regeneration processing. FIG. 26 is a diagram illustrating a hardware configuration example.

  Hereinafter, embodiments of a monitoring program, a monitoring method, and a monitoring device disclosed in the present application will be described in detail with reference to the drawings. Note that the present invention is not limited to the embodiments. In addition, the embodiments can be appropriately combined within a consistent range.

[System configuration]
FIG. 1 is a diagram illustrating an example of the overall configuration of a system according to the first embodiment. As shown in FIG. 1, in this system, a business server group 1, a monitoring device 10, and an operation management device 50 are connected via a network N. The network N can employ various networks such as the Internet and a dedicated line regardless of wired or wireless. Further, the monitoring device 10 and the operation management device 50 can be realized by separate casings, or can be realized by the same casing.

  The business server group 1 is a business system composed of a plurality of business servers, such as a form management system. FIG. 2 is a schematic diagram illustrating a system configuration tree according to the first embodiment. As shown in FIG. 2, the business server group 1 is a form management system having a Web / AP server, a WF server, and a DB server. The Web / AP server provides a Web service and an AP service that is a business application to the client, the WF server provides a form service that is a form management to the client, and the DB server provides a DB such as a DB search. Provide services to clients.

  The monitoring device 10 is an example of a server that monitors the business server group 1. Specifically, the monitoring device 10 has a manager function of a monitoring application (monitoring product), and installs an agent function of the monitoring application on each server of the business server group 1 to monitor server stoppage and abnormality processing. Detect events. Then, the monitoring device 10 notifies the operator of the abnormality by displaying the detected monitoring event on a display or the like.

  As an example of the monitoring item, for example, the monitoring device 10 performs alive monitoring of each server, monitoring of the remaining disk capacity of each server, event log monitoring of each server, activation status monitoring of each service, and system operation monitoring. .

  The operation management device 50 is an example of a server that executes an operation management operation (operation product) such as maintenance on each server of the business server group 1. Specifically, the operation management apparatus 50 automates an operation management operation such as maintenance as a workflow, and automatically executes maintenance or the like for the business server group 1. Examples of maintenance include hardware replacement, patch application, and memory expansion. In this embodiment, a workflow is executed in which maintenance work is performed after the form service of the WF server that constitutes the form management system is stopped, and then the form service is started.

  FIG. 3 is a schematic diagram illustrating a workflow according to the first embodiment. As shown in FIG. 3, the workflow is executed by the operation product, and is controlled so that the nodes are shifted one by one from the START node to the END node. One “operation component” is set for each node, and transition to the next node is made when processing of the operation component is completed. For example, when the configuration information collection process of the node 1 ends, the service stop process of the node 2 is executed. Here, the workflow has no branching, but the processing can be branched depending on the execution result of the operation component and can be shifted to a different node.

[Functional configuration of monitoring device]
FIG. 4 is a functional block diagram of the functional configuration of the monitoring apparatus according to the first embodiment. As illustrated in FIG. 4, the monitoring device 10 includes a communication unit 11, a storage unit 12, and a control unit 15.

  The communication unit 11 is a processing unit that controls communication of other devices, and is, for example, a communication interface. For example, the communication unit 11 receives a monitoring event from the business server group 1 and receives a filter from the operation management apparatus 50. In addition, the communication unit 11 transmits the collected monitoring events to the operation management apparatus 50.

  The storage unit 12 is an example of a storage device that stores data and programs, and is, for example, a memory or a hard disk. The storage unit 12 stores a monitoring event DB 13 and a filtering DB 14.

  The monitoring event DB 13 is a database that stores monitoring events detected by the business server group 1. FIG. 5 is a diagram illustrating an example of monitoring events stored in the monitoring event DB 13. As shown in FIG. 5, each monitoring event is composed of “event number, level, source, event type, message, occurrence date and time, handling flag”.

  The “event No.” stored here is an identifier for identifying a monitoring event, and is uniquely given in the order of occurrence. “Level” is information indicating the urgency level of the monitoring event, and ERROR, WARNING, INFO, etc. are set in descending order of urgency level. “Source” is information indicating a server from which a monitoring event is generated, and a WF server, a DB server, or the like is set. Note that even an XX server that is not related to the workflow and not related to the form management system is included in the monitoring event to be detected in consideration of the case where noise is detected.

  “Event type” is information indicating the type of monitoring event. For example, event log monitoring, process monitoring, scenario monitoring, MIB (Management Information Base) monitoring, and the like are set. “Message” indicates an error message detected by the monitoring event. “Occurrence date and time” indicates the date and time when the monitoring event occurred. The “handling flag” is information indicating whether or not failure handling has been executed for the monitoring event.

  The monitoring event on the first line in FIG. 5 is a monitoring event of “ERROR” of “event log monitoring” output from “XX server”, and “September 3, 2016, 00:04:02” Action Indicates that the message "Log rotation failed." That is "unnecessary" has been output.

  The filtering DB 14 is a database that stores filters for filtering monitoring events. The filter stored here is generated by the operation management apparatus 50. Since the stored filter will be described later, a detailed description thereof will be omitted.

  The control unit 15 is a processing unit that controls the entire monitoring apparatus 10, and is, for example, a processor. The control unit 15 includes a monitoring event management unit 16, a filtering unit 17, and a screen output unit 18. The monitoring event management unit 16, the filtering unit 17, and the screen output unit 18 are an example of an electronic circuit included in the processor and an example of a process executed by the processor.

  The monitoring event management unit 16 is a processing unit that executes a monitoring function and monitors each server of the business server group 1. For example, the monitoring event management unit 16 detects a monitoring event that has occurred in each server and registers it in the monitoring event DB 13.

  The filtering unit 17 is a processing unit that performs filtering of detected monitoring events. Specifically, the filtering unit 17 performs filtering of the detected monitoring event using a filter stored in the filtering DB 14, and determines whether or not the monitoring event is an output target. The filtering unit 17 notifies the screen output unit 18 of information related to the monitoring event if it is an output target, and suppresses the notification of the information related to the monitoring event to the screen output unit 18 if it is not an output target. To do.

  The screen output unit 18 is a processing unit that displays a monitoring event on a display unit such as a display. For example, when the screen output unit 18 receives “event No” or the like as information related to the monitoring event to be output from the filtering unit 17, the screen output unit 18 reads the corresponding monitoring event from the monitoring event DB 13 and displays it on a display unit such as a display. .

[Functional configuration of operation management device]
FIG. 6 is a functional block diagram of the functional configuration of the operation management apparatus according to the first embodiment. As illustrated in FIG. 6, the operation management apparatus 50 includes a communication unit 51, a storage unit 52, and a control unit 70.

  The communication unit 51 is a processing unit that controls communication of other devices, and is, for example, a communication interface. For example, the communication unit 51 receives a monitoring event from the monitoring device 10 and transmits a filter to the monitoring device 10.

  The storage unit 52 is an example of a storage device that stores data and programs, and is, for example, a memory or a hard disk. The storage unit 52 stores a workflow management DB 53, a variable management DB 54, an instance management DB 55, a monitoring event management DB 56, an event pattern management DB 57, a transition route management DB 58, a pattern data management DB 59, and a filtering management DB 60.

  The workflow management DB 53 is a database that stores the execution content of an automated workflow. FIG. 7 is a diagram illustrating an example of a workflow stored in the workflow management DB. As shown in FIG. 7, the workflow management DB 53 stores “workflow No., component No., operation component name, operation target, operation service / resource, next component No.” for each workflow. The information stored here is set by a maintenance person or the like.

  “Workflow No.” is an identifier for identifying a workflow. “Part No.” is an identifier of a part constituting the workflow. “Operation target” is information indicating an operation target of a component, and “operation service / resource” is information indicating a service and a resource operated by the component. “Next part number” indicates a part to be executed next.

  In the example of FIG. 1 is composed of parts from 0 to 99, and the first part has a part name “acquisition of operation target / resource”, and indicates that the second part is executed after this part. In addition, part no. The part name “service stop confirmation” of No. 3 is executed for the variable 2 of the variable 1, and the part number “No. 4 and part no. 5 indicates separation.

  The variable management DB 54 is a database that manages variables read in the workflow. FIG. 8 is a diagram illustrating an example of variables stored in the variable management DB. As illustrated in FIG. 8, the variable management DB 54 stores “variable No, instance No, node No, variable name, variable value” in association with each other. The information stored here is set by a maintenance person or the like.

  “Variable No” is an identifier for identifying a variable, and “Instance No.” is an identifier for identifying an instance such as an event or a case. “Node No.” is an identifier for identifying a node executed in the workflow. “Variable name” is a name of a variable read by each component of the workflow, and “Variable value” is a value set to the variable name. In the example of FIG. 1 as an instance number. 1 node no. 0 indicates that the variable 1 of the variable value (hostA) is set.

  The instance management DB 55 is a database that stores instances executed in each workflow for each workflow. FIG. 9 is a diagram illustrating an example of instances stored in the instance management DB 55. As shown in FIG. 9, the instance management DB 55 associates “instance number, workflow number, node position, node transition source, start date / time, end date / time, execution result (standard output), execution result (return value)”, and the like. Remember. The information stored here is stored by the workflow execution unit 71 every time the workflow is executed.

  In the example of FIG. 1 is a workflow number. Indicates that the instance is executed in one workflow. The first line in FIG. 9 is executed from 00:04:00 on September 3, 2016 to 00:04:02 on September 3, 2016 in node 1 that has transitioned from node 0. “Successful acquisition of configuration information” is acquired, and the execution result is “0 (normal)”.

  The monitoring event management DB 56 is a database that stores monitoring events that have occurred in the business server group 1. The information stored here is information acquired from the monitoring device 10 and is the same as the information managed by the monitoring device 10, and thus detailed description thereof is omitted.

  The event pattern management DB 57 is a database that stores the total results of monitoring events that have occurred during the execution of a workflow. FIG. 10 is a diagram illustrating an example of event patterns stored in the event pattern management DB. As shown in FIG. 10, the event pattern management DB 57 stores “pattern No., workflow No., node No., operation target, operation resource, number of executions, data No., transition route, update date / time” and the like in association with each other.

  “Pattern No” is an identifier for identifying an event pattern, “Workflow No” is an identifier for identifying a workflow in which the event pattern has occurred, and “Node No” is an identifier for identifying the node that issued the event pattern It is. “Operation target” is an identifier of the server operated when the event pattern is generated, and “Operation resource” is an identifier of the service operated when the event pattern is generated. “Execution count” is the event pattern execution count, and “Data No.” is an identifier used when specifying the detailed contents. The “transition route” is information indicating the order of event patterns, and the “update date / time” is the latest update date / time (occurrence date / time).

  In the example of FIG. 2 is a workflow number. This is a monitoring event that occurs when it is executed for the Web service of the AP server in node 1 of FIG. This monitoring event has occurred 14 times in the past, corresponds to transition route 1, and data No. This corresponds to the detailed event content specified in 2-4, and the update date and time is 00:04:00 on September 3, 2016.

  The transition route management DB 58 is a database that stores transition routes of nodes at the time of workflow execution. FIG. 11 is a diagram illustrating an example of a transition route stored in the transition route management DB. As shown in FIG. 11, the transition route management DB 58 stores “transition route No., workflow No., transition source node, transition destination node” in association with each other. The information stored here is set by a maintenance person or the like.

  “Transition route No.” is an identifier for identifying a transition route, and “Workflow No.” is an identifier for identifying a workflow. The “transition source node” is an identifier for identifying the transition source node, and the “transition destination node” is an identifier for identifying the transition destination node. The example of the first line in FIG. 1 is information indicating a transition route of 1 and a transition from node 0 to node 1.

  The pattern data management DB 59 is a database that manages detailed information on patterns generated in event patterns. FIG. 12 is a diagram illustrating an example of pattern data stored in the pattern data management DB. As shown in FIG. 12, the pattern data management DB 59 stores “data No., event type, message, source, level, occurrence time, reliability, margin” and the like in association with each other.

  “Data No” is an identifier for identifying pattern data. “Event type” is information indicating the type of monitoring event. “Message” is the content of the message output by the monitoring event. “Source” is information indicating the server that issued the monitoring event. “Level” is information indicating the risk level of the issued monitoring event. “Occurrence time” is the occurrence time of the monitoring event. “Reliability” is information indicating whether the monitoring event is caused by a workflow. “Margin” is information indicating an allowable range of the occurrence time of the monitoring event.

  In the example of FIG. 2 is a monitoring event of event log monitoring issued by the AP server. The message “˜Service is stopped” is issued at “00:00:02” with the risk “INFO”. Show. In addition, data No. In the pattern data 2, “2” is set as the margin and “80” is set as the reliability. That is, the data No. 2 output between “00:00:02” and before and after 2 seconds. The monitoring event having the same content as that in FIG. Indicates that it is treated as 2.

  The filtering management DB 60 is a database that manages information related to filters that filter monitoring events. FIG. 13 is a diagram illustrating an example of filters stored in the filtering management DB. As illustrated in FIG. 13, the filtering management DB 60 stores “filter No., event type, message, source, level, time condition, action, repetition” and the like in association with each other.

  “Filter No.” is an identifier for identifying a filter. “Event type” is information indicating the type of monitoring event. “Message” is the content of the message output by the monitoring event. “Source” is information indicating the server that issued the monitoring event. “Level” is information indicating the risk level of the issued monitoring event. The “time condition” is a time zone in which the monitoring event is expected to be output. “Action” is the content of the action corresponding to the issue of the monitoring event. “Repetition” indicates the number of repetitions of control by the filter.

  In the case of FIG. 1 is an event log corresponding to “˜Service will be stopped” and “INFO” issued from the AP server between 00:04:01 and 00:04:05 on September 3, 2016. Indicates to suppress display.

  The control unit 70 is a processing unit that controls the entire operation management apparatus 50, and is, for example, a processor. The control unit 70 includes a workflow execution unit 71 and a filtering processing unit 80. The workflow execution unit 71 and the filtering processing unit 80 are an example of an electronic circuit included in the processor and an example of a process executed by the processor.

(1. Workflow execution)
The workflow execution unit 71 is a processing unit that executes a workflow. Specifically, the workflow execution unit 71 selects a corresponding workflow from the workflows stored in the workflow management DB 53 shown in FIG. 7 when a predetermined time is reached or when a start is instructed by a maintenance person. Are sequentially executed from the Start node to the END node.

  FIG. 14 is a flowchart showing the flow of workflow execution processing. As shown in FIG. 14, the workflow execution unit 71 starts from the Start node (S101), and executes the loop processing from S102 to S107 up to the END node. Specifically, the workflow execution unit 71 acquires the operation target and the operation content from the workflow management DB 53 (S103), and executes the process set in the operation component (S104). When the workflow execution unit 71 receives a notification of the completion of the processing of the node (S105), the workflow execution unit 71 transitions to the next node (S106) and executes the next processing.

(2. Filtering control)
The filtering processing unit 80 is a processing unit that generates a filter that suppresses output of a monitoring event caused by execution of a workflow. The filtering processing unit 80 includes an event pattern reading unit 81, an event pattern generation unit 82, a match processing unit 83, a reliability determination unit 84, a match determination unit 85, and a filtering update unit 86, and an event pattern update unit 87.

  Here, after describing the overall flow of processing, the details of each processing will be described. FIG. 15 is a flowchart showing the overall flow of event pattern update processing. As shown in FIG. 15, the filtering processing unit 80 reads the corresponding event pattern from the event pattern management DB 57 (S201), and matches the event pattern of the already created monitoring event with the monitoring event newly output this time. The matching process is executed (S202).

  Thereafter, when the reliability of the corresponding event pattern is greater than or equal to the threshold (S203: Yes), the filtering processing unit 80 executes event pattern matching determination (S204). When the similarity is equal to or higher than the threshold (S205: Yes), the filtering processing unit 80 updates the filtering (S206) and updates the event pattern (S207). When the reliability is less than the threshold (S203: No), the filtering processing unit 80 updates the event pattern without executing S204 to S206 (S207). In addition, when the similarity is less than the threshold (S205: No), the filtering processing unit 80 updates the event pattern without executing S206 (S207).

(2-1. Event pattern reading)
The event pattern reading unit 81 is a processing unit that reads an event pattern from the event pattern management DB 57. Specifically, the event pattern reading unit 81 searches the instance management DB 55 and the variable management DB 54 from the specified workflow No., instance No., and node position, and transitions nodes and set variables (target server and Get resources to be controlled).

  Thereafter, the event pattern reading unit 81 searches the event pattern management DB 57 and acquires an event pattern having a condition that matches the acquired instance information. Here, the event pattern reading unit 81 sets the reliability to 0 when there is no event pattern, for example, at the first activation. Then, the event pattern reading unit 81 generates an event pattern and outputs an instruction to the event pattern generation unit 82.

  On the other hand, the event pattern reading unit 81 acquires the reliability from the pattern data management DB 59 when the event pattern exists. Then, the event pattern reading unit 81 performs control so as not to make a coincidence determination when the obtained reliability is below a user-specified threshold.

(2-2. First generation of event pattern)
The event pattern generation unit 82 is a processing unit that generates an event pattern at the first time when there is no event pattern to be read by the event pattern reading unit 81. Specifically, the event pattern generation unit 82 generates an event group that groups monitoring events that have occurred from the start to the end of the workflow, and generates an event group that is based on the monitoring events that have occurred during the past workflow execution. Run.

  First, the event pattern generation unit 82 generates an event group. For example, the event pattern generation unit 82 divides a monitoring event generated from the start to the end of the workflow for each node as shown in FIG. At this time, the start time of each node can be expressed by the elapsed time of the workflow. FIG. 16 is a diagram for explaining division of event grouping. As shown in FIG. 16, the event pattern generation unit 82 divides, for each node, the elapsed time of the workflow (start time is Tf = 0) and the elapsed time of each node (start time is Tnx = 0, x is a node). To do.

  3 will be described as an example. The event pattern generation unit 82 divides node 1 from start to end, node 2 from start to end, node 3 from start to end, and node 4 from start to end. Then, the event pattern generation unit 82 arranges the monitoring events occurring in the sections in time series in each divided section. In consideration of a case where a monitoring event unrelated to the workflow is detected, a monitoring event generated in another XX server unrelated to the form management system is included.

  FIG. 17 shows a collection result of monitoring events that have occurred in each node. FIG. 17 is a diagram for explaining generation of an event group. As shown in FIG. 17, when a workflow is executed, an event log is generated in the XX server at node 1 when Tn1 = 1.0, and an event log is generated at the WF server at Tn2 = 3.0 in node 2. When Tn2 = 5.0, a monitoring event by the monitoring product is detected. In node 3, an event log is generated in the DB server when Tn3 = 1.0, an event log is generated in the AP server when Tn3 = 2.0, and Tn3 = 10.0, 55.5, A monitoring event is detected by the monitoring product at 115.0, an event log is generated at the XX server when Tn3 = 20.0 and 80.0, and an event log is generated at the WF server when Tn3 = 60.0. Occurred. In the node 4, an event log is generated in the WF server when Tn4 = 3.0.

  Next, event pattern generation will be described. The event pattern generation unit 82 generates as many event groups as the number of execution histories from the monitoring events that occurred during the past workflow execution (see FIG. 10). By obtaining a statistical occurrence pattern from these event group groups, it is possible to create an event pattern that occurs when a specific workflow is executed. An event pattern is created for each node, and a set of event patterns of all the nodes becomes a workflow event pattern.

  In the event pattern of FIG. 10, the operation component set in each node can be referred to by referring to the workflow management DB 53 storing the workflow definition from the workflow No. and node position information. The pattern data in FIG. 12 is obtained by storing the time series data in FIG. 17 as an array. The actual state of reliability is a value held for each array element of pattern data, in other words, for each monitoring event unit.

  Next, an event pattern generation procedure will be described. First, the event pattern generation unit 82 analyzes the specified workflow No. definition information and acquires a list of nodes to be executed. In the example of FIG. 3, the event pattern generation unit 82 acquires four nodes: node 1 (acquires configuration information), node 2 (stops the service), node 3 (Activity), and node 4 (starts the service).

  Secondly, the event pattern generation unit 82 searches the execution log of the workflow (operation product) from the acquired workflow No. and node number, and acquires the date, operation target, operation resource, and the like when the corresponding node was executed in the past. . Thirdly, the event pattern generation unit 82 repeats the following processing 1-2 as many times as the number of histories that match conditions such as the operation target and operation resources in the acquired execution log. Process 1: A process of searching all monitoring events that occurred during the period from the start of the execution date and time to the start of the next node from the log of the monitoring product. Process 2: Event group generation process.

  Finally, the event pattern generation unit 82 obtains a statistical pattern from a plurality of event groups, and generates an event pattern for each node. FIG. 18 is a diagram for explaining an event group group. FIG. 18 shows occurrence events in time series with the horizontal axis as elapsed time. Also, shading is distinguished by event type.

  (A) in FIG. It is a figure explaining the event group of 100 nodes2. Even if there are seven event groups for “stop service” of node 2, data for five times for the form service is used because of the difference in parameters (operation target and operation resource) at the time of calling. 18A shows a workflow No. in the past. When No. 100 is executed several times, the instance No. The monitoring event output in each of 10, 20, 30, 40, and 50 is represented.

  FIG. 18B shows an event pattern created for the “stop service” of node 2 using the remaining two data. FIG. 18B shows a workflow No. in the past. When No. 100 is executed several times, the instance No. The monitoring event output in each of 35 and 45 is represented.

  As a result of generating the event pattern shown in FIG. 18, it is possible to determine that a monitoring event that exists only in a specific event group as indicated by a dotted frame (×) is not generated by the operation component processing. it can. That is, it is not included in the event pattern as noise. About this noise, the influence which it has on the whole by repeating a frequency | count becomes small.

  In addition, monitoring events that are located at node boundaries, as indicated by dotted lines (arrows), may be included in the “stop service” component side node or the next node depending on the event pattern. It is done. This occurs because different log information is used for each of the operation product and the monitoring product. For such a monitoring event in the vicinity of the boundary, a margin section is provided so that determination is made so as not to be divided at the boundary. Although only the next node is shown in FIG. 18, the margin with the previous node is actually considered in the same manner.

  Then, the event pattern generation unit 82 creates an event pattern considering the caller workflow and the target server for each node. FIG. 19 is a diagram for explaining the generated event pattern. FIG. 19 shows an event pattern generated based on the event group shown in FIG. As shown in FIG. 19, for the form service, two monitoring events common to the instance ID = 10, 20, 30, 40, 50 are registered in the event pattern, and for the Web service, the instance ID = 35, 45. Six common monitoring events are registered in the event pattern. That is, these event patterns are display events to be suppressed.

(2-3. Matching process)
Returning to FIG. 6, when the event pattern is read by the event pattern reading unit 81, the matching processing unit 83 matches the information stored in the workflow management DB 53 with the information stored in the monitoring event management DB 56, and performs an operation operation. It is a processing unit that acquires a list of monitoring events that occurred during execution. Specifically, the matching processing unit 83 starts the date and time when the operation operation is performed, matches the workflow with the generated monitoring event, and generates an event group.

  FIG. 20 is a flowchart showing the flow of the matching process. As shown in FIG. 20, the matching processing unit 83 calculates a start time (S301). For example, the matching processing unit 83 searches the workflow management DB 53 using the specified workflow No, instance No, and node position, and acquires the start date / time of the corresponding node included in the instance information. Thereafter, the matching processing unit 83 acquires “the first monitoring event occurrence date and time margin value” included in the event pattern information, and sets a value including the margin.

  Subsequently, the matching processing unit 83 calculates an end time (S302). For example, the matching processing unit 83 searches the workflow management DB 53 using the specified workflow No, instance No, and node position, and acquires the end date and time of the corresponding node included in the instance information. Thereafter, the matching processing unit 83 obtains “the last monitoring event occurrence date and time margin value” included in the event pattern information, and sets a value including the margin.

  Then, the matching processing unit 83 searches for a monitoring event stored in the monitoring event management DB 56 by designating the date and time (S303). For example, the matching processing unit 83 acquires all the monitoring events that occur between the start date and time acquired in S301 and the end date and time acquired in S302.

  Thereafter, when there is a monitoring event (S304: Yes), the match processing unit 83 generates an event group (S305), and when there is no monitoring event (S304: No), the process ends. For example, the match processing unit 83 creates an array of monitoring events in which the monitoring events are arranged in time series with the relative time from the start of the node, from the list of acquired monitoring events. Note that details of event group generation are the same as in FIGS. 16 to 18, and thus detailed description thereof is omitted.

(2-4. Reliability determination processing)
The reliability determination unit 84 is a processing unit that determines whether the reliability of the event pattern read by the event pattern reading unit 81 is equal to or higher than a threshold value. Specifically, the reliability determination unit 84 specifies the data No set in the corresponding event pattern. Subsequently, the reliability determination unit 84 searches the pattern data management DB 59 for pattern data corresponding to the specified data No. And the reliability determination part 84 determines whether the reliability set to the searched pattern data is more than a threshold value.

  That is, only when the read event pattern is a highly reliable event pattern, it is determined whether the monitoring event can be suppressed or not. Here, although details will be described later, the reliability is information indicating a degree of trust as “statistical information” that “occurred during execution of a past workflow”. That is, the reliability is high when the event pattern for each execution count is correlated, and is low when there is no correlation. By considering this value, it is possible to prevent a case where an event pattern that has occurred only once is adopted. Due to the influence of noise, reliability decreases at the start of operation, but it improves by increasing the number of executions (the number of parameters) in the same environment.

(2-5. Matching process)
The match determination unit 85 performs a match determination between the event group newly generated by the event pattern reading unit 81 and the event pattern read from the event pattern management DB 57 by the event pattern reading unit 81, and calculates similarity Part. Specifically, the coincidence determination unit 85 collates an event group generated by execution of the workflow with an event pattern registered in the event pattern management DB 57, and detects an event generated by a past operation operation. Since the event group is divided for each node, the coincidence determination unit 85 makes a coincidence determination with the event group of the operation component of each node. The coincidence determination unit 85 calculates the certainty of this determination as a similarity. If the data does not match the past data, the similarity is low.

  That is, the coincidence determination unit 85 determines whether or not each monitoring event included in the event group generated when the current workflow is executed is similar to the monitoring event detected when the past workflow is executed. If they are similar, the coincidence determination unit 85 determines that the cause of the monitoring event detected when the current workflow is executed is execution of the workflow. That is, the coincidence determination unit 85 can determine that the monitoring event is a display suppression target.

  FIG. 21 is a flowchart showing the flow of the matching process. As shown in FIG. 21, the coincidence determination unit 85 initializes a coincidence flag (S401). For example, the match determination unit 85 initializes an area for storing the event group comparison result of the event pattern.

  Subsequently, the match determination unit 85 executes a loop process from S402 to S405 for all the monitoring events of the event pattern. Specifically, the coincidence determination unit 85 determines whether or not the same monitoring event exists in the margin section (S403). If the same monitoring event exists (S403: Yes), the coincidence determination unit 85 turns on the matching flag (S404). If the same monitoring event does not exist (S403: No), the coincidence determination unit 85 determines the next monitoring event. Make a decision.

  Among monitoring events, there are events that are not determined to be coincident due to a change in the environment during operation or a shift in the detection timing of the monitoring product. Therefore, for event patterns in which the match flag remains, (1) a process for normalizing the time length of the event pattern, (2) a process for sliding the event occurrence time, and (3) an event that is repeatedly detected. Each process of the process integrated into one, (4) the process which excludes the event defined to be ignored by the user designation is executed. This loop processing is performed in the order of monitoring events with high reliability in the event pattern.

  When the loop process ends, the coincidence determination unit 85 calculates the similarity (S406). Specifically, the coincidence determination unit 85 corrects the monitoring event whose coincidence flag is ON so as to coincide with the corresponding event pattern. Then, the coincidence determination unit 85 compares the corrected event group with the event pattern, and calculates the similarity.

  The similarity is a value indicating the degree to which an event group is in common with past event patterns, and is high when there is a correlation between the generation source and timing of the monitoring event, and low when there is no correlation. For example, the coincidence determination unit 85 calculates the correlation coefficient by “Si = 100 × (f (Ai, Ap (i−1)) + 1) / 2” using the correlation coefficient.

  Here, Si is the similarity between the i-th event group and the i-1th event pattern, f is a correlation function, and returns a value in the range of -1 to 1. Ai is the i-th event group, and Api is the i-th event pattern. For the i-th event group, a group that has been subjected to a predetermined correction in consideration of a deviation for each execution count can be used. As an example of the predetermined correction, normalization of the time from node start to end (scaled to match the event pattern), monitoring event occurrence time slide, integration of a plurality of monitoring events occurring, and other user-defined For example, exclusion of judgment-unnecessary events.

(2-6. Filter update processing)
Returning to FIG. 6, the filtering update unit 86 is a processing unit that creates or updates filtering data (filter) that executes display suppression of a monitoring event that occurs in accordance with an operation operation by matching determination. Specifically, the filtering update unit 86 suppresses the display of the event pattern of the monitoring event in which the reliability is determined to be greater than or equal to the threshold by the reliability determination unit 84 and the similarity is determined to be greater than or equal to the threshold by the match determination unit 85. Filter rules for generating a filter rule or adding the filter rule to an existing filter.

  FIG. 22 is a diagram for explaining the result of the coincidence determination. FIG. 22 shows 12 monitoring events displayed at the timing when the workflow is executed. Among these, it is assumed that it is determined that the event patterns other than the three monitoring events detected in the event log of the XX server match the event pattern output when the past work group is executed. In this case, the filtering update unit 86 generates a filter that displays only three monitoring events detected by the XX server and suppresses other displays. That is, only the monitoring events of Tn1 = 1.0, Tn3 = 20.0, and Tn3 = 80.0 are displayed and output.

  That is, only when the reliability and the similarity are equal to or greater than the threshold value, it is determined that they match. This means that there is a high correlation between the event pattern created from reliable past data and the event group that occurred. In this case, the filtering update unit 86 automatically takes measures such as suppressing monitoring events in accordance with measures taken in the past. This threshold can also be set by the user.

  It should be noted that only monitoring events that are in the event pattern and that do not require handling in the past are suppressed. In the case of FIG. 22, since the monitoring event generated by the “service stop” component matches the event pattern, it is correctly suppressed. In addition, other operation components are also monitored events generated from the monitoring settings, and are included in the event pattern, and thus are also suppressed. In FIG. 22, monitoring events to be suppressed in this way are indicated by “x” marks. On the other hand, “acquisition of component” parts and maintenance work are not included in the event patterns of the respective operation parts, in other words, are caused by factors other than this workflow operation. Such noise is not suppressed as intended.

  And the filtering update part 86 transmits the produced | generated filter to the monitoring apparatus 10, and the monitoring apparatus 10 performs filtering with a filter. FIG. 23 is a diagram for explaining filtering. As shown in FIG. 23, the operation management apparatus 50 executes a workflow on a server group. Along with this execution, the monitoring device 10 has Tn1 = 1.0, Tn2 = 3.0, Tn2 = 5.0, Tn3 = 1.0, Tn3 = 2.0, Tn3 = 10.0, Tn3 = 20. Detect a monitoring event such as .0.

  In parallel with this, the operation management apparatus 50 uses the execution result and the detection result to generate and update the filtering based on the determination of matching with the event pattern, and transmits it to the monitoring apparatus 10. Then, the monitoring apparatus 10 applies the updated filtering, and detects Tn1 = 1.0, Tn2 = 3.0, Tn2 = 5.0, Tn3 = 1.0, Tn3 = 2.0, Tn3 = Of the monitoring events such as 10.0 and Tn3 = 20.0, only the monitoring events of Tn1 = 1.0 and Tn3 = 20.0 are displayed as requiring action. Alternatively, the monitoring device 10 displays a monitoring event other than Tn1 = 1.0 and Tn3 = 20.0 as no action is required.

(2-7. Event pattern update processing)
The event pattern update unit 87 is a processing unit that updates an event pattern using information on an event group that is a target of the current workflow. The event pattern does not necessarily have to be recreated with the start of the workflow. Since the event pattern that has been created in advance is registered in the event pattern management DB 57, the amount of calculation and the calculation time can be reduced by updating this event pattern. In the case of such a differential update, the event pattern is updated by comparing or integrating the created event pattern and the generated event group. In addition, it is usually possible to keep the latest “monitoring events that have occurred in the past” by calculating using registered event patterns and periodically recreating event patterns separately.

  FIG. 24 is a flowchart showing the flow of event pattern update processing. The event pattern update unit 87 reads an event group (S501) and reads an event pattern (S502). For example, the event pattern update unit 87 reads the update source event pattern from the event pattern management DB 57 and acquires the event group detected in the current maintenance from each processing unit.

  Subsequently, the event pattern update unit 87 executes a loop process from S503 to S507 for each monitoring event of the acquired event pattern. Specifically, when there is a matching monitoring event between the event pattern and the event group (S504: Yes), the event pattern update unit 87 updates the occurrence time and the margin (S505), and updates the reliability. (S506). If there is no matching monitoring event between the event pattern and the event group (S504: No), the event pattern update unit 87 executes S506 without executing S505.

  For example, the occurrence time is updated to the latest time. The update value of the margin is updated by “(execution count × event pattern value + event group value) / (execution count + 1)” in consideration of the influence on the past, with the execution count as a weight. Further, the event pattern update unit 87 updates the reliability of the event pattern for the monitoring events of all event groups. As in the case of occurrence time and margin, the update value is weighted by the number of executions, but basically increases if they match, and decreases if they do not match.

  Here, the reliability will be described. The event pattern is obtained by a recurrence process. That is, the i-th event pattern with the number of executions is obtained from the i-1th event pattern and the i-th event group. Further, the reliability of the entire event pattern is the average of the reliability of each monitoring event in the event pattern. The reliability of each monitoring event can be calculated by the number of appearances / number of trials. For example, when m times out of n times, it is “n / m × 100”, and when it occurs every time, it becomes 100. However, considering that the impact on the reliability varies depending on the number of executions, `` correction to reduce in a time-dependent manner so as to reduce the impact of data that occurred in the past '' and `` the impact when there is a user action '' It is also possible to execute “correction that increases or decreases depending on the countermeasure result so as to increase”.

(2-8. Event pattern generation processing)
The event pattern update unit 87 is a processing unit that executes recreation of the event pattern stored in the event pattern management DB 57 at a predetermined interval or an interval specified by the administrator without depending on the execution of the workflow.

  For example, the event pattern update unit 87 can perform processing in parallel with the execution of the workflow. A difference from the new creation is that notification is made every time a node transitions, and an event pattern is created for each node using the notification as a trigger. The difference in the reliability calculation method is that, when an event group is created, only monitoring events that have occurred up to that timing exist, but it is not possible to acquire the presence or absence of user actions such as no action required or already handled.

  FIG. 25 is a flowchart showing a flow of event pattern regeneration processing. As shown in FIG. 25, the event pattern update unit 87 executes the loop processing from S601 to S606 as many times as specified by the administrator or the like. Specifically, the event pattern update unit 87 executes loop processing with i as a variable, an initial value as a specified value, and the number of repetitions as the number of trials. For example, the event pattern update unit 87 generates the i-th event group (S602), executes a match determination between the i-th event group and the event pattern (S603), and calculates the reliability with correction (S604). The event pattern is updated (S605).

  More specifically, in the event pattern re-creation, “event group creation”, “match determination”, and “event pattern update” are repeated for the number of trials. Unlike the initial generation of the event pattern described above, the number of trials can be considered because it exists in the instance information of the workflow management DB 53 but does not exist in the monitoring event because of the relationship between the data retention periods of the operation management product and the monitoring product, or vice versa. The start timing is specified from how many months ago or from what time.

  In addition, corrections regarding past information can be added to the reliability. Therefore, the corrected reliability Ri ′ can be obtained by multiplying a predetermined coefficient when calculating the uncorrected reliability Ri. For example, “Kt (i)”, which is a coefficient of time and becomes a curve that attenuates as the past data from the present, is a coefficient of teaching by the user's handling, and the influence of the event group that the user does not need to deal with A coefficient such as “Ku (i)” that is set so as to reflect strongly is used.

[effect]
The operation management apparatus 50 can record a monitoring event generated by an operation operation such as maintenance as an event pattern. The operation management apparatus 50 can express the uncertainty of information unique to operation management by the reliability of the event pattern and the similarity indicating the correlation with the event pattern. The operation management apparatus 50 can generate a filtering rule that suppresses a monitoring event generated by a specified workflow without a pre-definition based on the event pattern.

  Since the operation management apparatus 50 automatically generates filtering rules from monitoring product and operation product logs, management by definition is not required and it can be applied to a large-scale environment. In addition, since a monitoring application agent is not required, the monitoring application agent can be applied even in an environment where the monitoring application agent cannot be installed on the business server. The operation management apparatus 50 can quantitatively indicate the operational stability of the workflow as “reliability”. If this value is low, the user can recognize that there is a problem with the environment or workflow.

  The operation management apparatus 50 can suppress only monitoring events that occur due to the workflow. There is no need to check for obvious and large number of monitoring events, and only events that occur due to manual operations or failures can be checked. The burden on the operator is reduced, and the possibility of missing a monitoring event or delaying the response can be reduced.

[Comparison]
In general, when an operation operation is performed in a workflow, a monitoring event that occurs is not only generated immediately after an operation from a target server, but also occurs in relation to a related server or a certain amount of time. For monitoring events that occur directly due to the execution of a component, the operations and phenomena are obvious, so the operator's burden is low and it can be determined that the monitoring is not performed, but it occurs indirectly due to the execution of the component. It is difficult for the operator to determine the monitoring event. Although the operation management apparatus 50 determines the monitoring event in an integrated manner by determining it as an event group, there is still a possibility that a different event group may occur every time the workflow is executed.

  In other words, noise such as presence or absence of monitoring events that occur from other servers, deviations in the timing of monitoring events due to retry or interval settings of monitored products, presence or absence of monitoring events that occur due to the status of target servers and related server applications Therefore, even if the same workflow is executed on the same target server with the same logical configuration, the same event pattern is not always obtained. As a result, the event pattern cannot be correctly created from the execution history, and it may be difficult to determine whether the event pattern has occurred in the past workflow execution period. In other words, monitoring events may not be correctly suppressed.

  However, the operation management apparatus 50 removes noise by indicating the correlation between event groups in the execution history as “reliability” and the correlation between event groups and event patterns as “similarity”. In addition, the reliability is calculated by allowing the variation of the event group that may occur in the same operation range, such as the change in the detection timing of the monitoring event by the monitoring product, to be allowed. Therefore, the operation management apparatus 50 can accurately identify the noise and exclude the event from the event pattern, so that the monitoring event can be correctly suppressed.

  Furthermore, since the operation management apparatus 50 does not perform the suppression by filtering unless the “reliability” is equal to or higher than the threshold, it is possible to reduce excessive suppression. Further, when evaluating the correlation between the event groups, the operation management apparatus 50 is configured so that the older event group in the execution history has a smaller influence so that the change in the event pattern of the monitoring event that occurs in the workflow converges earlier. It can also be derived.

  Although the embodiments of the present invention have been described so far, the present invention may be implemented in various different forms other than the embodiments described above. Therefore, different embodiments will be described below.

[Determination material]
In the above embodiment, the example using the reliability has been described. However, the present invention is not limited to this. For example, the number of executions in the past can be used, and only the event pattern can be used without using information such as the reliability. It can also be determined.

[system]
The processing procedure, control procedure, specific name, information including various data and parameters shown in the document and drawings can be arbitrarily changed unless otherwise specified. Note that the monitoring device 10 and the operation management device 50 can be realized by a single housing.

  Further, each component of each illustrated apparatus is functionally conceptual, and does not necessarily need to be physically configured as illustrated. That is, the specific form of distribution / integration of each device is not limited to that shown in the figure. That is, all or a part of them can be configured to be functionally or physically distributed / integrated in arbitrary units according to various loads or usage conditions. Further, all or any part of each processing function performed in each device may be realized by a CPU and a program analyzed and executed by the CPU, or may be realized as hardware by wired logic.

[Hardware configuration]
Since the operation management device 50 and the monitoring device 10 have the same hardware configuration, they will be described as the information processing device 100 here. FIG. 26 is a diagram illustrating a hardware configuration example. As illustrated in FIG. 26, the information processing apparatus 100 includes a communication interface 100a, an HDD (Hard Disk Drive) 100b, a memory 100c, and a processor 100d.

  The communication interface 100a is a network interface card that controls communication of other devices. The HDD 100b is an example of a storage device that stores programs, data, and the like.

  Examples of the memory 100c include a RAM (Random Access Memory) such as SDRAM (Synchronous Dynamic Random Access Memory), a ROM (Read Only Memory), a flash memory, and the like. Examples of the processor 100d include a central processing unit (CPU), a digital signal processor (DSP), a field programmable gate array (FPGA), and a programmable logic device (PLD).

  The information processing apparatus 100 operates as an information processing apparatus that executes a filtering method by reading and executing a program. That is, the information processing apparatus 100 executes a program that executes the same functions as the workflow execution unit 71 and the filtering processing unit 80. As a result, the information processing apparatus 100 can execute a process for executing functions similar to those of the workflow execution unit 71 and the filtering processing unit 80. Note that the program referred to in the other embodiments is not limited to being executed by the information processing apparatus 100. For example, the present invention can be similarly applied to a case where another computer or server executes the program or a case where these programs cooperate to execute the program.

  This program can be distributed via a network such as the Internet. The program is recorded on a computer-readable recording medium such as a hard disk, flexible disk (FD), CD-ROM, MO (Magneto-Optical disk), DVD (Digital Versatile Disc), and the like. It can be executed by being read.

50 Operation Management Device 51 Communication Unit 52 Storage Unit 53 Workflow Management DB
54 Variable management DB
55 Instance management DB
56 Monitoring event management DB
57 Event pattern management DB
58 Transition route management DB
59 Pattern data management DB
60 Filtering management DB
DESCRIPTION OF SYMBOLS 71 Workflow execution part 80 Filtering process part 81 Event pattern reading part 82 Event pattern production | generation part 83 Collision process part 84 Reliability determination part 85 Match determination part 86 Filtering update part 87 Event pattern update part

Claims (6)

When an event related to server monitoring is acquired, in a monitoring program for notifying the terminal of information related to the acquired event,
Obtaining the identification information of the process related to the operation of the server and the event that occurred during the execution of the process related to the operation of the server among the events related to the monitoring of the server;
With reference to a storage unit that stores an event generated due to a process related to server operation in association with the identification information of the process, the event associated with the acquired identification information of the process is identified,
Among the acquired events, suppress notification of information related to the specified event,
A monitoring program for causing a computer to execute processing. Collect a plurality of events that were output when operation processing that is processing related to the operation of the server was executed in the past,
According to the collected event types and occurrence times, the computer further executes a process of generating an output pattern of an event generated due to the operation process and storing the output pattern in the storage unit,
The monitoring program according to claim 1, wherein the specifying process specifies an event included in the output pattern among events associated with the acquired identification information of the operation process. The storing process calculates, for each event included in the output pattern, a reliability based on the number of times the event has been output when the operation process has been executed in the past, and calculates the calculated reliability. Store in the storage unit in association with each event of the output pattern,
The identifying process identifies an event that matches an event having a reliability equal to or higher than a threshold included in the output pattern, among events associated with the acquired identification information of the operation process. Item 3. The monitoring program according to item 2. Each time the operation process is newly executed, a plurality of events that occurred during the execution of the operation process are acquired, and the event occurs due to the operation process according to the types and occurrence times of the acquired events. Generate an event output pattern,
4. If the generated output pattern is not stored in the storage unit, the computer is further caused to execute a process of registering as a new output pattern of an event caused by the operation process. The monitoring program described in. In the monitoring method of notifying the terminal of information related to the acquired event when acquiring an event related to server monitoring,
Obtaining the identification information of the process related to the operation of the server and the event that occurred during the execution of the process related to the operation of the server among the events related to the monitoring of the server;
With reference to a storage unit that stores an event generated due to a process related to server operation in association with the identification information of the process, the event associated with the acquired identification information of the process is identified,
Among the acquired events, suppress notification of information related to the specified event,
A monitoring method, wherein a computer executes a process. When an event related to server monitoring is acquired, a monitoring device that notifies the terminal of information related to the acquired event,
An acquisition unit that acquires identification information of processing related to the operation of the server and an event that occurs during execution of processing related to the operation of the server among events related to monitoring of the server;
A specifying unit that identifies an event associated with the acquired identification information of the process with reference to a storage unit that stores the event generated due to the process related to server operation in association with the identification information of the process; ,
A monitoring apparatus comprising: a suppressing unit that suppresses notification of information related to the identified event among the acquired events.

Images