ANALYSIS APPARATUS, ANALYSIS METHOD, AND PROGRAM

Provided is a service graph analysis device 10 which detects anomalies of a monitored service 100 that implements specific features by a chained operation of multiple components. The service graph analysis device 10 includes an extraction unit 11 configured to extract a processing start event and a processing end event from monitoring data and generate a firing sequence arranging the events in chronological order, the monitoring data including information on a series of processing in the monitored service 100; and a detection unit 12 configured to determine whether the event arranged in the firing sequence can be fired in a service graph illustrating a dependency between components constituting the monitored service 100, and detect anomalies in a case where there is a non-fired event.

TECHNICAL FIELD

The present invention relates to an analysis device, an analysis method and a program.

BACKGROUND ART

In recent years, a microservice architecture has been widely provided in which applications for providing services such as web or ICT services are divided for each feature as components and the components communicate with each other to make a chained operation. For microservice management, not only metric or log monitoring at a resource level but also monitoring at an application level is required. For example, event logs occurred while running an application and the metrics in the application (including the number of HTTP requests, the number of transactions and the waiting time for each request) are aggregated and monitored in the application, whereby it is possible to support anomaly detection and root cause analysis in a complicated microservice.

As an example of an application-level monitoring scheme, visualization of component traces for one request to the application has been proposed. This is called tracing. Non Patent Literatures 1 and 2 respectively disclose black box-based tracing software that acquires operation history data without modifying the application itself. Non Patent Literatures 3 and 4 respectively disclose annotation-based tracing software that acquires operation history data by modifying the application. By visualizing of various microservice traces as a series of flows and displaying to a maintenance engineer or a developer, it is possible to help discover unusual traces and root causes of anomalies.

CITATION LIST

Non Patent Literature

SUMMARY OF INVENTION

Technical Problem

Application-level monitoring data keeps accumulating every time an application runs, and thus it is not practicable for a person to check each piece of data in real time.

The inventors have proposed a method of estimating an inter-component dependency and creating a service graph representing dependencies between all components across the service by a Petri net in “Proposal of Service Graph Buildup based on Trace Data of Multiple Services” (IEICE Journal, Vol. 119, No. 438). Accordingly, it is possible to construct the service graph representing the inter-component dependency using the monitoring data.

Abnormal behaviors can be discovered by detecting monitoring data that does not follow the constructed service graph, and it is impossible to manually check a myriad pieces of monitoring data piece by piece to find anomalies.

The present invention is intended to deal with the problems stated above, and an object thereof is to extract abnormal monitoring data.

Solution to Problem

According to one aspect of the present invention, provided is an analysis device for detecting anomalies in a service that implements specific features by means of a chained operation of multiple components, the analysis device including: an extraction unit configured to extract a processing start event and a processing end event from monitoring data and generate a firing sequence arranging the events in chronological order, the monitoring data including information on a series of processing in the service; and a detection unit configured to determine whether the event arranged in the firing sequence can be fired in a service graph illustrating a dependency between components constituting the service, and detect anomalies in a case where there is a non-fired event.

Advantageous Effects of Invention

According to the present invention, it is possible to extract abnormal monitoring data.

DESCRIPTION OF EMBODIMENTS

Hereinbelow, the present embodiment will be described with reference to drawings.

Referring toFIG.1, an overall configuration of a maintenance control system including a service graph analysis device10of the present embodiment will be described. The maintenance control system shown inFIG.1includes a service graph analysis device10, a service monitoring device20, a monitoring data distribution device30, a service graph generation device40, a service graph retention device50, and a control device60.

A monitored service100includes a plurality of components and implements specific features by a chain operation of the multiple components. A component is a program that has an interface capable of exchanging requests and responses with other components and is implemented in various program languages.

The service monitoring device20is a device for monitoring the monitored service100at an application level, and for visualizing traces of the components for one request. The service monitoring device20can adopt technologies described in Non Patent Literatures 1 to 4. For example, the service monitoring device20records processing in each component of the monitored service100as a span element, and visualizes a flow of operations in the monitored service100for one request as trace data (hereinafter sometimes also referred to as “monitoring data”). A code for carrying a label is embedded in each component of the monitored service100to acquire the span element. The service monitoring device20displays the visualized trace data to a maintenance engineer. The maintenance engineer can check application-level behaviors of the monitored service100with the visualized trace data.

The monitoring data distribution device30receives the monitoring data from the service monitoring device20, and distributes the monitoring data to the service graph generation device40or to the service graph analysis device10according to an operation phase of the maintenance control system. More particularly, the monitoring data distribution device30distributes the monitoring data to the service graph generation device40in a learning phase, and to the service graph analysis device10in a detection phase. A service graph is updated based on the monitoring data from the service graph generation device40in the learning phase. The monitoring data is checked in the service graph by the service graph analysis device10in the detection phase. A service graph is a graph structure representing dependencies between components constituting the monitored service100. The service graph can be used to represent a state transition of flows of operations in the monitored service100. The monitoring data distribution device30switches distribution destinations of the monitoring data based on an instruction from the control device60.

The service graph generation device40receives the monitoring data in the learning phase, estimates inter-component dependencies from the monitoring data, updates the service graph based on the estimated dependencies, and stores the service graph in the service graph retention device50.

The service graph retention device50retains the service graph. The service graph retained by the service graph retention device50is displayed to the maintenance engineer, or used by the service graph analysis device10to analyze the monitoring data. A normal label is given to the service graph retained by the service graph retention device50in the detection phase, and is removed from the service graph in the learning phase. The service graph to which the normal label is given corresponds to a normal model in which the graph update converges and is determined.

The developer develops and updates the monitored service100in development environment110. When updating the monitored service100, the development environment110sends an update timing notification to the control device60.

The control device60switches between the learning phase and the detection phase on the basis of update information received from the development environment110and the convergence determination of the service graph. Specifically, when receiving a notification indicating that the monitored service100has been updated from the development environment110during the detection phase, the control device60shifts to the learning phase and issues an instruction to switch a distribution destination of the monitoring data to the service graph generation device40. The control device60determines the update convergence of the service graph retained by the service graph retention device50during the learning phase, shifts to the detection phase when determining that the service graph update has converged, and issues an instruction to switch the distribution destination of the monitoring data to the service graph analysis device10.

The service graph analysis device10receives the monitoring data in the detection phase, and determines whether a behavior is abnormal by checking executability of a state transition of the monitoring data in the service graph. When the abnormal behavior is detected, the service graph analysis device10presents the analysis result to the maintenance engineer.

A configuration of the service graph analysis device10will be described with reference toFIG.2. The service graph analysis device10illustrated inFIG.2includes an extraction unit11, a detection unit12, and a display unit13.

The extraction unit11extracts all the processing start and processing end events from the monitoring data, and sorts the extracted events in chronological order to create a firing sequence to be checked.

In a case where a suspicious event in which the anomaly is detected is received from the detection unit12, the extraction unit11lists resources used by the suspicious event from the monitoring data as suspicious resources.

The detection unit12checks whether each event in the firing sequence created from the monitoring data in the service graph retained by the service graph retention device50can be fired, determines that the abnormal behavior has occurred in a case where there is a non-fired event in the firing sequence, and extracts the suspicious event leading to a failure cause state.

When the detection unit12detects the abnormal behavior, the display unit13presents the analysis result obtained by visualizing the suspicious event and the suspicious resources to the maintenance engineer.

The service graph generated from the trace data (monitoring data) will be described below. The service graph analysis device10checks the firing sequence generated from the monitoring data using the service graph.

The trace data is a set of span elements constituting a series of processing from a request for the monitored service100to a response. For example, one piece of trace data from one request made by an end user to the monitored service100to a response is obtained. The span element is data in which time data of processing of each component and a parent-progeny relationship are recorded.FIG.3illustrates one example of the visualized trace data. InFIG.3, a horizontal axis represents time, and a processing period of the component is represented by a rectangular width. Each of the five rectangles with letters A to E indicates the span element of each component. Arrows indicate exchanges of requests and responses between components. The span element includes, for example, information on a component name (Name), a trace ID (TraceID), a processing start time (StartTime), a processing period (Duration), and a relationship (Reference).

Referring toFIGS.4to7, a method of representing a service graph based on inter-component dependencies will be described.

The service graph generation device40estimates an inter-component dependency from time information of each span element of the trace data, and represents a component-level service graph of the entire monitored service100by a Petri net on the basis of the estimated dependency. The Petri net is a two-part directed graph having two types of nodes, place and transition, connected by arcs. A variable called a token is given to the place. A state of the entire Petri net represented by the number of tokens held by each place is referred to as a marking. In particular, a marking in the initial state of the Petri net is referred to as an initial marking. The transition transfers tokens of all the places existing before a certain place to all the successive places by firing. The transition firing causes the Petri net to transition from the initial marking to the next marking.

In the present embodiment, a Petri net of one component is defined as illustrated inFIG.4.

Specifically, three types of states taken by the component include “unprocessed”, “in-process”, and “processed”, which are associated with places. A state transition of the component is represented by moving a token by firing (processing start or processing end) of the inter-place transition. The token is a black circle arranged at the unprocessed place inFIG.4. When the component shown inFIG.4starts processing, the token is moved to the in-process place.

The inter-component dependency can be represented by adding an arc and a place to the Petri net of the components illustrated inFIG.4. Specifically, as illustrated inFIGS.5to7, a parent-progeny relationship, an order relation, and an exclusive relationship between components are expressed. The parent-progeny relationship is a relationship in which one component calls the other component. The order relation is a relationship in which one component is always executed after processing of the other component. The exclusive relationship is a relationship in which components never run in parallel.

A parent-progeny relationship between components A and B can be represented as illustrated inFIG.5. An arc connects from a transition of processing start of the parent component A to an unprocessed place of the progeny component B, and another arc connects from a processed place of the progeny component B to a transition of processing end of the parent component A. It shows that the processing of the component B starts after the processing start of the component A, the component B enters a processed state after the processing end of the component B, and then the processing of the component A ends.

An order relation between the components A and B can be represented as illustrated inFIG.6. New arc and new place are arranged at the transition of processing end of the component A, and another arc connects from the new place to a transition of processing start of the component B. It shows that the processing of the component B starts after the processing end of the component A.

An exclusive relationship between the components A and B can be represented as illustrated inFIG.7. A new place indicating a state in which both the component A and the component B are not being processed is arranged, and a token is arranged at the new place. Arcs respectively connect from transitions of processing end of the components A and B to the new place, and the other arcs respectively connect from the new place to transitions of processing starts of the components A and B. It shows that the processing of the component C or the component B starts after the processing end of the component B or the component C.

FIG.8illustrates one example of a service graph of the monitored service100. All components constituting the monitored service100and inter-component dependencies are represented in the service graph ofFIG.8. When the monitoring data is distributed to the service graph generation device40, the service graph generation device40compares the time data between span elements of sibling components with respect to each piece of the trace data included in the monitoring data, estimates the order relation or the exclusive relationship between the components, and updates the service graph. The service graph generation device40adds a graph representing a dependency by the method above for a newly discovered inter-component dependency, and removes a graph representing a dependency for a lost dependency.

The service graph analysis device10extracts processing start and processing end events from the trace data to create a firing sequence, sets an initial marking of the service graph, and checks whether events in the firing sequence can be sequentially fired. If there is a non-fired event, it is determined as an abnormal behavior.

A flow of processing of the maintenance control system will be described with reference to a sequence diagram shown inFIG.9.

When receiving the monitoring data from the monitoring data distribution device30in step S1, the extraction unit11extracts processing start and processing end events from the monitoring data, creates a firing sequence sorted in chronological order, and transmits the firing sequence to the detection unit12in step S2.

The detection unit12acquires a service graph from the service graph retention device50in step S3, and the detection unit detects an anomaly by sequentially shifting the service graph from an initial marking according to the firing sequence in step S4.

The detection unit12transmits the check result of the firing sequence to the extraction unit11in step S5. In a case where the anomaly is detected, the detection unit12notifies the extraction unit11of a suspicious event.

In a case where the detection unit12detects the anomaly, in step S6, the extraction unit11extracts suspicious resources corresponding to the suspicious event from the monitoring data, and transmits anomaly occurrence information including the suspicious event and the suspicious resources to the display unit13.

The display unit13presents the analysis result including the suspicious event and the suspicious resources to a maintenance engineer in step S7.

In a case where the detection unit12detects no anomaly, the processing of steps S6and S7is not performed.

A processing flow of the service graph analysis device10will be described below with reference to flowcharts shown inFIGS.10and11.

When the extraction unit11receives the monitoring data in step S11of the flowchart shown inFIG.10, all processing start and processing end events are extracted from the monitoring data to create a firing sequence sorted in chronological order for further check in step S12. When creating the firing sequence, the extraction unit11checks the naming rule and appropriately processes an event name included in the firing sequence such that the event name matches a name of the transition in the service graph. For example, “_ start” indicating the processing start or “_ end” indicating the processing end is added to a “processing name” of the event.

In step S13, the detection unit12checks the type of a root span and sets the initial marking of the service graph. The root span is a span element at which processing is initiated first. The initial marking is, for example, a state in which one token is placed at an unprocessed place in a subgraph corresponding to the root span.

All the events in the firing sequence are processed in chronological order, and the detection unit12searches, from the service graph, for a transition corresponding to a processed event and checks a firing availability of the transition in step S14. In a case where all the input places of the transition have tokens, the processed event can be fired.

In a case where the processed event can be fired, the detection unit12updates the marking of the service graph in step S15.

If all the events in the firing sequence can be fired, the detection unit12determines that normal operations are detected from the monitoring data, and notifies the extraction unit11that only the normal operations are discovered in the monitoring data in step S16.

In a case where the firing sequence includes a non-fired event, the detection unit12determines that the monitoring data contains an abnormal operation and advances the processing to the flowchart shown inFIG.11.

In step S21of the flowchart shown inFIG.11, the detection unit12extracts a marking that fails to transition without firing as a failure cause state, and extracts an event related to the failure cause state as a suspicious event in step S22. A span element including a place having a token in a marking of the failure cause state is a span element in which the processing has been performed until immediately before, and is included as a suspicious portion. For example, a subgraph (span element) indicated by a reference numeral200is a suspicious portion in the service graph ofFIG.12. The detection unit12acquires a union of transitions before the place having the token in the failure cause state, and lists all events corresponding to the transitions included in the union as suspicious events. In the service graph ofFIG.12, a transition before the place having the token is taken as a suspicious event. In a case where a plurality of places have tokens, a plurality of events may be listed as suspicious events. In a case where there are a plurality of transitions before the place, a plurality of events may be listed as suspicious events.

In step S23, the extraction unit11refers to the monitoring data corresponding to the suspicious event and extracts suspicious resources. The monitoring data may include resource information such as IP address of a virtual machine executing the processing. The extraction unit11lists a union of resources used by the suspicious event as suspicious resources. A cause event and a cause resource can be identified in a simple case. However, in a case where there is a plurality of waiting processes and there are many suspicious events that can be causes, cause resources may not be identified.

The display unit13visualizes and presents the suspicious event and the suspicious resources to a maintenance engineer in step S24. The display unit13may visualize and present the monitoring data determined to be abnormal to the maintenance engineer.

As described above, the service graph analysis device10according to the present embodiment includes the extraction unit11configured to extract the processing start event and the processing end event from the monitoring data and generate the firing sequence arranging the events in chronological order, the monitoring data including information on a series of processing in the monitored service100; and the detection unit12configured to determine whether the event arranged in the firing sequence can be fired in the service graph illustrating the dependency between the components constituting the monitored service100, and detect anomalies in a case where there is the non-fired event. In the service graph, states before, during, and after processing of the components are represented as places in a Petri net, processing start and processing end of the components are expressed as transitions in the Petri net, and inter-component dependencies are denoted by arranging new nodes and arcs between the Petri nets of the components. In the service graph having a non-fired event in a firing sequence, the detection unit12detects, as a component in which an anomaly has occurred, a component corresponding to a subgraph including a place in which a token is arranged. Accordingly, the abnormal monitoring data can be extracted using the service graph.

As the service graph analysis device10described above, a general-purpose computer system can be used, for example, including a central processing unit (CPU)901, a memory902, a storage903, a communication device904, an input device905, and an output device906as illustrated inFIG.13. In this computer system, the CPU901executes a predetermined program loaded on the memory902, thereby implementing the service graph analysis device10. This program can be recorded on a computer-readable recording medium such as a magnetic disk, an optical disk, or a semiconductor memory, or can be distributed via a network.

REFERENCE SIGNS LIST