JP2024015673A - Monitoring support device, monitoring support method, and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a technique capable of supporting monitoring of a service being achieved by coordination of a plurality of applications.

SOLUTION: A monitoring support device of an aspect of the present disclosure is a monitoring support device which supports monitoring of an abnormality sign of a service to be achieved by coordination of a plurality of applications, and includes: an accepting unit which is configured to accept an object service indicating a service being an object of the monitoring and an object period indicating a period being an object of monitoring; a requesting unit which is configured to request logs in the object period to the plurality of applications achieving the object service; and a visualizing unit which is configured to visualize information for monitoring presence and absence of the abnormality sign of the object service in the object period by using the logs returned from the plurality of applications as a response to the request.

SELECTED DRAWING: Figure 10

COPYRIGHT: (C)2024,JPO&INPIT

Description

The present disclosure relates to a monitoring support device, a monitoring support method, and a program.

Generally, applications output various logs. For example, operation information for the application, operation information of the application (internal operation, external operation), information regarding abnormal events such as errors and failures, etc. are output as a log. These logs are often used for investigation work after an abnormality occurs, such as identifying the cause of the abnormality and analyzing the range of influence when an abnormality occurs in an application (see, for example, Patent Document 1). It can also be used for monitoring work before an abnormality occurs, such as detecting symptoms.

JP2019-46215A

If multiple applications are working together to provide a specific service, logs from each application providing that service are required for monitoring before an error occurs. It may happen. However, each application may output only a part of the log (for example, a log when an abnormality occurs) to the outside, for example, to prevent the log from becoming large. In this case, necessary logs cannot be obtained, making monitoring work to detect signs of abnormality difficult.

The present disclosure has been made in view of the above points, and aims to provide technology that can support monitoring of services realized by cooperation of multiple applications.

A monitoring support device according to an aspect of the present disclosure is a monitoring support device that supports monitoring of abnormality signs of a service realized by cooperation of a plurality of applications, and includes a target service representing a service to be monitored; a reception unit configured to receive a target period representing a period to be monitored; and configured to request logs for the target period from a plurality of applications that implement the target service. Visualization configured to visualize information for monitoring the presence or absence of abnormality signs in the target service during the target period using a request unit and logs returned from the plurality of applications in response to the request. It has a section and a.

A technology is provided that can support monitoring of services realized by linking multiple applications.

FIG. 2 is a diagram for explaining an example of a service realized by cooperation of multiple applications. FIG. 1 is a diagram showing an example of the overall configuration of a log management system according to a first embodiment. 1 is a diagram showing an example of a functional configuration of an application processing device according to a first embodiment; FIG. FIG. 1 is a diagram showing an example of a functional configuration of a monitoring support device according to a first embodiment. FIG. 3 is a diagram for explaining an example of the relationship between services, applications, and service types. It is a figure showing an example of a service type table. FIG. 3 is a diagram for explaining an example of an individual log creation and storage process according to the first embodiment. It is a figure which shows an example of an individual log. FIG. 3 is a diagram for explaining an example of log visualization processing according to the first embodiment. FIG. 2 is a diagram (part 1) for explaining an example of log visualization. FIG. 2 is a diagram (part 2) for explaining an example of log visualization. FIG. 2 is a diagram (part 1) for explaining an example of a method for detecting abnormality signs. FIG. 2 is a diagram (part 2) for explaining an example of a method for detecting abnormality signs; FIG. 7 is a diagram (part 3) for explaining an example of a method for detecting abnormality signs; FIG. 3 is a diagram showing an example of a functional configuration of a monitoring support device according to a second embodiment. It is a figure which shows an example of a standard time table. FIG. 7 is a diagram for explaining an example of log visualization processing according to the second embodiment. FIG. 7 is a diagram (part 3) for explaining an example of log visualization; 1 is a diagram showing an example of a hardware configuration of a computer.

Hereinafter, a first embodiment and a second embodiment will be described as one embodiment of the present invention.

[First embodiment]
In this embodiment, by acquiring the logs of each application that implements the services, it is possible to support monitoring work to detect signs of abnormality, targeting services that are realized by linking multiple applications. The log management system 1 will be explained. Note that an abnormality sign is an event that has not yet led to the occurrence of an abnormality, but has a high probability that an abnormality will occur in the future. Hereinafter, the application will also be referred to as an "app".

<Service realized by linking multiple applications>
FIG. 1 shows an example of a service realized by cooperation of multiple applications. FIG. 1 shows a service X realized by cooperation between application A1, application B, and application C, and service Y realized by cooperation among application A2, application B, and application C.

As shown in Figure 1, service X is realized by processing application A1, then processing application B using the processing result, and then processing application C using the processing result. This is a service that provides Similarly, service Y is a service that is realized by processing application A2, then processing application B using the processing result, and then processing application C using the processing result. .

A specific example of service can be mentioned. Similarly, as a specific example of service Y, for example, application A2 captures an image of an analog device, application B converts the image into a numerical value through image analysis, and application C stores the numerical data in a database. Services such as: However, these specific examples of services are just examples, and the present invention is not limited thereto.

Note that the method or architecture for realizing a service by linking multiple applications as described above is also called "microservice architecture." On the other hand, a method or architecture that realizes one service using one application is also called a "monolithic architecture." In a microservice architecture, each of a plurality of applications provides small services (that is, microservices), and various targeted services are realized by linking or combining these microservices.

<Example of overall configuration of log management system 1>
FIG. 2 shows an example of the overall configuration of the log management system 1 according to this embodiment. As shown in FIG. 2, the log management system 1 according to this embodiment includes one or more application processing devices 10, a log storage device 20, and a monitoring support device 30. Further, each of these devices is communicably connected via a communication network N such as a LAN (Local Area Network), for example.

The application processing device 10 has one or more applications 100 and executes processing of these applications 100. By executing the processing of a plurality of applications 100 by one or more application processing devices 10, services based on a microservice architecture such as the above-mentioned service X and service Y are realized. Here, it is assumed that each application 100 outputs logs (hereinafter referred to as individual logs) that are graded into levels according to importance.

The log storage device 20 stores individual logs of the application 100. The log storage device 20 includes an individual log storage unit 210 in which individual logs of a certain level or higher (for example, individual logs representing occurrence of an abnormality) among the individual logs output from the application 100 are stored.

The monitoring support device 30 has a monitoring support program 300, which creates logs called comprehensive logs, and visualizes these comprehensive logs for each service. More specifically, when conditions for a comprehensive log to be visualized (hereinafter also referred to as visualization target conditions) are given, the monitoring support program 300 acquires individual logs that satisfy the visualization target conditions and also performs comprehensive log processing. Create logs and visualize those comprehensive logs for each service. This visualization allows a user (for example, an operator who monitors each service) to refer to the comprehensive log of a desired service and check whether or not there are signs of abnormality in that service.

Note that the overall configuration of the log management system 1 shown in FIG. 1 is an example, and is not limited to this, and other configurations may be used. For example, the log storage device 20 and the monitoring support device 30 may be configured as one unit. More specifically, for example, the monitoring support device 30 has the individual log storage unit 210, and the log storage device 20 may not be provided.

<Example of functional configuration of application processing device 10 and monitoring support device 30>
An example of the functional configuration of the application processing device 10 and the monitoring support device 30 according to this embodiment will be described.

≪Application processing device 10≫
FIG. 3 shows an example of the functional configuration of the application processing device 10 according to this embodiment. As shown in FIG. 3, the application processing device 10 according to this embodiment includes an application processing section 101, an individual log management section 102, and an internal log storage section 103. The application processing unit 101 and the individual log management unit 102 are realized by, for example, processing that the application 100 causes a calculation device such as a CPU (Central Processing Unit) to execute. Further, the internal log storage unit 103 is realized by, for example, an auxiliary storage device such as an SSD (Solid State Drive) or an HDD (Hard Disk Drive).

The application processing unit 101 executes processing specific to the application 100. Here, the unique processing of the application 100 (hereinafter also referred to as unique processing) means the processing for providing microservices of the application 100.

Further, the application processing unit 101 transmits a log storage request to the individual log management unit 102 when an event for which an individual log is to be saved occurs.

In response to a log storage request from the application processing unit 101, the individual log management unit 102 creates an individual log of events that occur in the specific processing of the application 100, and stores it in the internal log storage unit 103. Here, at least the log level, service type, and message are specified in the log storage request, and the individual log management unit 102 saves the individual log by adding the current date and time to the log level, service type, and message. create.

The log level is a level determined in advance according to the importance of an event represented by an individual log. As an example, the log level includes "INFO" indicating that the event is occurring during normal processing, "NOTICE" indicating that the event is occurring during exception processing, and "WARN" indicating that the event is a warning event. , "ERROR" indicating an abnormal event. However, this is just an example, and the log level can be arbitrarily defined depending on the importance of the event. Note that "INFO", "NOTCE", "WARN", and "ERROR" may be expressed numerically, for example, as "0", "1", "2", and "3", respectively.

What types of events exist as events during normal processing, events during exception processing, warning events, and abnormal events may differ depending on the application 100 that provides microservices. Examples of events during steady processing include events such as login, logout, screen display, device recovery, alarm suppression/cancellation, and the like. Examples of events during exception processing include events such as a target value change operation and a system stop operation. Examples of events that should be warned include events such as missing data, minor or medium errors, minor or medium failures, and exceeding upper or lower limits. Examples of abnormal events include, for example, events such as a serious error leading to system stoppage or data abnormality, and a serious failure.

The service type is information for identifying a service realized by specific processing of the application 100. As a result, even if, for example, a plurality of services are realized by the unique processing of a certain application 100, which service's individual log belongs to can be identified based on the service type. For example, in the example shown in FIG. 1, since application B and application C can implement both service X and service Y through their unique processing, the individual log of which service is identified by the service type.

A message is a string of characters that concisely represents the event represented by the individual log (for example, a string of characters that summarizes the event).

Further, the individual log management unit 102 stores individual logs of a certain log level (hereinafter also referred to as “setting log level”) or higher in the individual log storage unit 210. Here, it is possible to arbitrarily set which log level is to be set as the set log level, but in the following, "ERROR" is set as the set log level as an example. As a result, individual logs with “ERROR” or higher are stored in the individual log storage unit 210.

Furthermore, when the individual log management unit 102 receives an individual log acquisition request, which will be described later, from the monitoring support device 30, the individual log management unit 102 acquires the individual log requested by the individual log acquisition request from the internal log storage unit 103, and responds to the individual log acquisition request. It is sent back to the monitoring support device 30 as a response.

The internal log storage unit 103 is, for example, a folder given the name of the application 100, etc., and stores individual logs created by the individual log management unit 102.

Note that when one application processing device 10 has a plurality of applications 100, the application processing device 10 has an application processing unit 101, an individual log management unit 102, and an internal log storage unit 103 for each application 100. It has

≪Monitoring support device 30≫
FIG. 4 shows an example of the functional configuration of the monitoring support device 30 according to this embodiment. As shown in FIG. 4, the monitoring support device 30 according to the present embodiment includes a condition reception unit 301, an individual log request unit 302, a comprehensive log management unit 303, a log visualization unit 304, and a service type table storage unit 305. and a comprehensive log storage unit 306. The condition reception unit 301, the individual log request unit 302, the comprehensive log management unit 303, and the log visualization unit 304 are realized by, for example, processing that the monitoring support program 300 causes a computing device such as a CPU to execute. Further, the service type table storage unit 305 and the comprehensive log storage unit 306 are realized by, for example, an auxiliary storage device such as an SSD or an HDD.

The condition receiving unit 301 receives the given visualization target condition as input. The visualization target conditions include a target period representing the period of the comprehensive log to be visualized, and a target service representing the service of the comprehensive log to be visualized. Note that the visualization target conditions may be given, for example, by an input operation by a user or the like, by another program, or by another terminal connected to the monitoring support device 30 via the communication network N. Alternatively, it may be given from a device or the like.

The individual log request unit 302 refers to the service type table stored in the service type table storage unit 305 and identifies each application 100 that realizes the target service included in the visualization target condition and the target service in the application 100. Identify the service type. Then, the individual log request unit 302 transmits an individual log acquisition request to the specified application 100. Here, the service type by which the destination application 100 identifies the target service and the target period included in the visualization target condition are specified in the individual log acquisition request.

The comprehensive log management unit 303 creates a comprehensive log from the individual logs returned from each application 100 in response to the individual log acquisition request, and then stores the comprehensive logs in the comprehensive log storage unit 306 in date and time order for each service. . The comprehensive log is a log to be visualized by the log visualization unit 304. For example, the individual log itself may be used as the comprehensive log, or some information (for example, the individual log may be sent as a reply) to the individual log. The name of the application 100, an identifier, etc.) may be added thereto.

The log visualization unit 304 visualizes the comprehensive log stored in the comprehensive log storage unit 306 for each service.

The service type table storage unit 305 stores a service type table for specifying the application 100 and service type from the target service. Here, as an example, there are service X and service Y shown in FIG. 1, and as shown in FIG. 5, application A1 identifies service X with service type "a1", and application B identifies service X with service type "b1". It is assumed that service X is identified, and application C identifies service X with service type "c1". Similarly, app A2 identifies service Y with service type "a2," app B identifies service Y with service type "b2," and app C identifies service Y with service type "c2." shall be. At this time, an example of the service type table is shown in FIG. In the service type table shown in FIG. 6, service X is associated with application A1 and service type a1, application B and service type b1, and application C and service type c1. Similarly, application A2 and service type a2, application B and service type b2, and application C and service type c2 are associated with service Y.

In this way, in the service type table, for each service, the application 100 that implements that service and the service type that identifies the service in that application 100 are associated. This makes it possible to specify the application 100 that implements the target service and the service type that identifies the target service using the application 100.

The comprehensive log storage unit 306 stores the comprehensive log stored by the comprehensive log management unit 303.

<Creating and saving individual logs>
An example of the individual log creation and storage processing according to this embodiment will be described with reference to FIG. 7. The following steps S101 to S105 are repeatedly executed in each application processing device 10 each time a log storage request is sent from the application processing unit 101.

The individual log management unit 102 of the application processing device 10 receives a log storage request specifying a log level, service type, and message (step S101).

Next, the individual log management unit 102 of the application processing device 10 creates an individual log by adding the current date and time to the log level, service type, and message specified in the log storage request received in step S101 above. (Step S102). Here, an example of the individual log is shown in FIG. As shown in FIG. 8, the individual log includes date and time, log level, service type, and message.

Next, the individual log management unit 102 of the application processing device 10 stores the individual log created in step S102 above in the internal log storage unit 103 (step S103).

Next, the individual log management unit 102 of the application processing device 10 determines whether the log level of the individual log created in step S102 above is equal to or higher than the set log level (step S104).

If it is not determined in step S104 that the log level of the individual log is equal to or higher than the set log level, the application processing device 10 ends the individual log creation and storage process. On the other hand, if it is determined in the above step S104 that the log level of the individual log is equal to or higher than the set log level, the individual log management unit 102 of the application processing device 10 converts the individual log created in the above step S102 into an individual log. The information is stored in the storage unit 210 (step S105). In this way, the individual log storage unit 210 stores only individual logs with a log level equal to or higher than the set log level. As a result, only individual logs with "ERROR" or higher are stored in the individual log storage unit 210, and the logs are prevented from becoming enlarged.

<Log visualization processing>
An example of the log visualization process according to this embodiment will be described with reference to FIG. 9. Note that when the visualization target condition is given to the monitoring support device 30, execution of the following processes from step S201 to step S207 is started.

The condition receiving unit 301 of the monitoring support device 30 receives the given visualization target condition as input (step S201). Note that, for example, there may be cases where either the target period or the target service is not included in the visualization target conditions. Therefore, if the target period is not included in the visualization target conditions, the condition reception unit 301 may accept a predetermined period (for example, the entire period or a predetermined period in the past from the current time) as the target period, for example. . Similarly, if the target service is not included in the visualization target conditions, the condition reception unit 301 accepts predetermined services (for example, all services, one or more predetermined specific services, etc.) as the target service. That's fine.

Next, the individual log request unit 302 of the monitoring support device 30 refers to the service type table stored in the service type table storage unit 305, and selects the target service included in the visualization target condition received in step S201 above. The application 100 to be implemented and the service type that identifies the target service in the application 100 are specified (step S202). That is, the individual log requesting unit 302 refers to the service type table and identifies the application 100 and service type associated with the target service.

For example, assume that the target services included in the visualization target conditions accepted in step S201 above are "service X" and "service Y" and that the service type table is as shown in FIG. 6. In this case, regarding service X, application "A1" and service type "a1", application "B" and service type "b1", and application "C" and service type "c1" are specified. Similarly, regarding service Y, application "A2" and service type "a2", application "B" and service type "b2", and application "C" and service type "c2" are specified.

Next, the individual log request unit 302 of the monitoring support device 30 requests a service corresponding to each application 100 (more precisely, the application processing device 10 having the application 100) identified in step S202 above. By type, an individual log acquisition request for the target period included in the visualization target condition accepted in step S201 above is transmitted (step S203).

That is, the individual log request unit 302 first creates an individual log acquisition request specifying each service type and target period. For example, the application 100 and service type specified in step S202 above are, for service X, application "A1" and service type "a1", application "B" and service type "b1", application "C" and service Assume that the type is "c1", and for service Y, it is assumed that the application is "A2" and the service type is "a2", the application is "B" and the service type is "b2", and the application is "C" and the service type is "c2". . Further, it is assumed that the target period is [t1, t2]. In this case, the individual log request unit 302 outputs (a1, t1, t2), (b1, t1, t2), (c1, t1, t2), (a2, t1, t2), (b2, t1, t2), Create six individual log acquisition requests such as (c2, t1, t2). Then, the individual log request unit 302 sends the individual log acquisition requests (a1, t1, t2) and (a2, t1, t2) to the application "A1", and the individual log acquisition requests (b1, t1, t2) and (b2, t1). , t2) to the application "B", and the individual log acquisition requests (c1, t1, t2) and (c2, t1, t2) to the application "C".

When the individual log management unit 102 of the application processing device 10 receives an individual log acquisition request from the monitoring support device 30, the individual log management unit 102 of the application processing device 10 receives the individual log acquisition request from the monitoring support device 30, and the individual log Individual logs within the target period specified in the request are acquired from the internal log storage unit 103 (step S204).

Then, the individual log management unit 102 of the application processing device 10 returns the individual log acquired in step S204 above to the monitoring support device 30 as a response to the individual log acquisition request (step S205).

When the responses from all the applications 100 identified in step S202 above are completed, the comprehensive log management unit 303 of the monitoring support device 30 creates a comprehensive log from the individual logs returned as these responses, and then Each service is stored in the comprehensive log storage unit 306 in date and time order (step S206). Note that the service is identified from the service type and service type table included in the individual log.

Thereby, the comprehensive log is stored in the comprehensive log storage unit 306 in date and time order for each service. Note that the comprehensive log may be the individual log itself that is returned as a response from each application 100, or it may contain some information about the individual log (for example, the name or identifier of the application 100 that returned the individual log, etc.). ) may be added.

Then, the log visualization unit 304 of the monitoring support device 30 visualizes the comprehensive log stored in the comprehensive log storage unit 306 for each service (step S207). Note that the log visualization unit 304 may, for example, visualize the comprehensive log on a display provided in the monitoring support device 30, or may visualize the comprehensive log on a display provided in a terminal or device connected to the monitoring support device 30 via a communication network. The comprehensive log may also be visualized.

<Log visualization example>
An example of visualizing the comprehensive log in step S207 in FIG. 9 will be described below. Below, as an example, when realizing service X, application A1 outputs "log A1-1" and "log A1-2" as individual logs, and application B outputs "log B-1" and "log B-1". It is assumed that application C outputs "log C-1" and "log C-2" as individual logs. Similarly, when realizing service Y, application A2 outputs "log A2-1" and "log A2-2" as individual logs, and application B outputs "log B-1" and "log B-2". It is assumed that "log B-3" is output as an individual log, and application C outputs "log C-1" and "log C-2" as individual logs. Furthermore, for the sake of simplicity, it is assumed that the general log is the individual log itself.

Further, it is assumed that the individual logs shown in the upper diagram of FIG. 10 are stored in the comprehensive log storage unit 306 as a comprehensive log. In the upper diagram of FIG. 10, the vertical axis represents the name of the individual log, and the horizontal axis represents the date and time t.

At this time, an example of visualization of the comprehensive log in step S207 of FIG. 9 is shown in the lower diagram of FIG. As shown in the lower part of FIG. 10, the comprehensive log is divided and visualized for each service. Moreover, in service X, log A1-1 and log A1-2, log A1-2 and log B-1, log B-1 and log B-2, log B-2 and log B-3, log B-3 and log C-1, and log C-1 and log C-2 are connected by line segments. Similarly, for service Y, log A2-1 and log A2-2, log A2-2 and log B-1, log B-1 and log B-2, log B-2 and log B-3, log B- 3 and log C-1, and log C-1 and log C-2 are connected by line segments. That is, for each service, integrated logs with adjacent dates and times t from the start to the end of the process for realizing that service are connected by line segments. Hereinafter, a comprehensive log connected by line segments in this manner will be referred to as a "log graph." Note that the log graph represents a set of comprehensive logs output in processing per service.

In the lower diagram of FIG. 10, the log graph of service X and the log graph of service Y are visualized in the same area so that they can be distinguished, but the log graph of service It may be visualized. For example, in the example shown in FIG. 11, log graphs 1001 to 1003 of service X and log graphs 2001 to 2003 of service Y are visualized in different areas.

<Example of abnormality sign detection>
By visualizing the comprehensive logs as shown in the lower diagram of FIG. 10 and FIG. 11, the user can refer to these comprehensive logs and confirm whether or not there are abnormal signs in the target service.

For example, if the service is the same and there are no signs of abnormality in the service, the time intervals of the comprehensive logs output in one service process are generally not considered to be significantly different. Therefore, for example, if there are no signs of abnormality in service Y, log graphs 2001 to 2003 have shapes that are similar to each other, as shown in FIG.

Similarly, even if only the general log of a certain application in the log graph is extracted, the extracted portions have shapes that are similar to each other. For example, if there are no signs of abnormality in service Y, the portions of log graphs 2001 to 2003 from which the comprehensive log of application B is extracted have shapes that are similar to each other, as shown in FIG.

Therefore, when the shape of the entire log graph or a portion thereof becomes dissimilar, the user can detect an abnormality sign of the service represented by the log graph. For example, as shown in FIG. 14, it is assumed that log graphs 2101 to 2103 of service Y are visualized. In the example shown in FIG. 14, the time between log B-1 and log B-2 (that is, the processing time during this period) gradually becomes longer, and compared to log graph 2101, log graph 2102 to log graph 2102 The shapes of the whole and its parts gradually become dissimilar. In other words, in the example shown in FIG. 14, it can be said that the shapes of the log graphs 2102 to 2102 change over time. Thereby, the user can detect signs of abnormality in the service Y represented by these log graphs 2101 to 2103.

In this way, the user focuses on the shape of the log graph expressed by the comprehensive log of the target service (or the part represented by the comprehensive log of a certain application within the log graph), and changes the shape over time. , it is detected that an abnormality sign exists in the target service. This makes it possible for users to know the signs of an abnormality before it actually occurs, and to take various measures to prevent the abnormality from occurring (for example, replacing equipment or parts). becomes possible.

[Second embodiment]
Next, a second embodiment will be described. In the first embodiment, the case where the user detects an abnormality sign from the change in the shape of the log graph over time was explained, but in this embodiment, information indicating whether an abnormality sign may exist from the shape of the log graph is explained. A case will be described in which a label (to be described later) is further visualized. This allows the user to more easily determine whether or not there is an abnormality sign in the target service.

Note that in this embodiment, differences from the first embodiment will be mainly explained, and components similar to those in the first embodiment will be given the same reference numerals and their explanation will be omitted. .

<Example of functional configuration of monitoring support device 30>
FIG. 15 shows an example of the functional configuration of the monitoring support device 30 according to this embodiment. As shown in FIG. 15, the monitoring support device 30 according to this embodiment further includes an index value calculation section 307 and a standard time table storage section 308. The index value calculation unit 307 is realized, for example, by a process that the monitoring support program 300 causes a calculation device such as a CPU to execute. Further, the standard time table storage unit 308 is realized by, for example, an auxiliary storage device such as an SSD or an HDD.

The index value calculation unit 307 refers to the standard time table stored in the standard time table storage unit 308 and determines whether or not an abnormality sign may exist in the target service for each adjacent log configuring each log graph. As an index value for determination, the difference between the processing time between adjacent logs and the standard processing time described later is calculated. Note that the adjacent log is a comprehensive log that has adjacent dates and times t from the start to the end of the process for realizing the target service.

The standard time table storage unit 308 stores a standard time table used for calculating and determining an index value for determining whether or not an abnormality sign may exist in the target service. Here, an example of the standard time table is shown in FIG. As shown in FIG. 16, in the standard time table, it is determined whether or not the difference between the standard processing time representing the standard processing time and the standard processing time is "normal" for each adjacent log. A first allowable time representing a threshold value for the difference is associated with a second allowable time representing a threshold value for determining whether the difference is a "warning" or "abnormality sign present". Here, "warning" means that there is no abnormality sign, but there is a risk that an abnormality sign will occur. Note that the first allowable time<the second allowable time.

For example, in the example shown in FIG. 16, the standard processing time S _m , the first allowable time α _m , and the second allowable time β _m correspond to “log B-1 to log B-2” between adjacent logs. It is attached. This is "normal" if the difference between the processing time from log B-1 to log B-2 and the standard processing time S _m is less than the first allowable time α _m , and the difference is within the first allowable time α m. This means that if the difference is greater than or equal to α _m and less than the second allowable time β _m , it is determined as a “warning”, and if the difference is greater than or equal to the second allowable time β _m , it is determined that there is an “abnormality sign”.

Similarly, for example, in the example shown in FIG. 16, for "log B-2 to log B-3" between adjacent logs, the standard processing time S _m+1 , the first allowable time α _m+1 , and the second allowable time β _m+1 is associated. This means that if the difference between the processing time from log B-2 to log B-3 and the standard processing time S _m+1 is less than the first allowable time α _m+1 , it is "normal", and the difference is within the first allowable time. This means that if the difference is greater than or equal to α _m+1 and less than the second allowable time β _m+1 , it is determined to be a “warning”, and if the difference is greater than or equal to the second allowable time β _m+1 , it is determined that there is an “abnormal sign”.

In the example shown in FIG. 16, "log B-1 to log B-2" and "log B-2 to log B-3" are illustrated as adjacent logs, but this is just an example. In the standard time table, a standard processing time, a first allowable time, and a second allowable time are associated with each other between adjacent logs.

In addition to visualizing the comprehensive log for each service as in the first embodiment, the log visualization unit 304 determines “normal”, “warning”, or “abnormality sign” from the index value calculated by the index value calculation unit 307. "Yes" is determined, and a label representing the determination result is further visualized.

<Log visualization processing>
An example of the log visualization process according to this embodiment will be described with reference to FIG. 17. Note that when the visualization target condition is given to the monitoring support device 30, execution of the following processes of steps S201 to S207 and steps S301 to S302 is started. Since the processing from step S201 to step S207 is the same as that in the first embodiment, the processing from step S301 to step S302 will be described below.

The index value calculation unit 307 of the monitoring support device 30 refers to the standard time table stored in the standard time table storage unit 308, and calculates the processing time between adjacent logs and the standard time for each adjacent log constituting each log graph. The difference from the processing time is calculated as an index value (step S301).

For example, if the date and time of the n-th comprehensive log that constitutes the k-th log graph of the target service is t _n ^(k) , the index value calculation unit 307 calculates |(t _n+1 ^(k) −t _n ^(k) )−S(k,n)| is calculated as the index value. However, S(k, n) is the standard processing time between the n-th comprehensive log and the n+1-th comprehensive log constituting the k-th log graph. Note that k and n are integers of 1 or more.

Then, using the index value calculated in step S301 above, the log visualization unit 304 of the monitoring support device 30 determines whether the adjacent logs corresponding to the index value are "normal", "warning", or "with signs of abnormality". It is determined which one is, and a label representing the determination result is further visualized (step S302).

For example, the log visualization unit 304 determines that if |(t _n+1 ^(k) −t _n ^(k) )−S(k, n)|<α(k, n), it is “normal” and α(k, n )≦|(t _n+1 ^(k) -t _n ^(k) )-S(k,n)|<β(k,n), "warning", |(t _n+1 ^(k) -t _n ^{( k)} )−S(k,n)|≧β(k,n), it is determined that “an abnormality sign exists”, and a label representing the determination result is further visualized. Here, α(k, n) is the first allowable time between the n-th comprehensive log and the n+1-th comprehensive log that constitute the k-th log graph, and β(k, n) is the k-th log graph. This is the second allowable time between the n-th comprehensive log and the n+1-th comprehensive log that make up the log.

<Log visualization example>
An example of label visualization in step S302 in FIG. 17 will be described below. Assuming a situation similar to the example shown in FIG. 14, FIG. 18 shows a case in which labels are also visualized. As shown in FIG. 18, a label 2201 representing "normal", a label 2202 representing "caution", and a label 2203 representing "sign of abnormality" are also visualized. This allows the user to more easily determine whether or not there is an abnormality sign in the target service.

Note that in addition to (or in place of) the above labels, the ratio between the index value and the first allowable time or the second allowable time may be further visualized. For example, in addition to (or in place of) a label representing "normal", |(t _n+1 ^(k) -t _n ^(k) )-S(k,n)|/α( k, n) may be visualized. Similarly, in addition to (or in place of) the label representing "warning", |(t _n+1 ^(k) -t _n ^(k) )-S(k,n)|/α (k, n) or |(t _n+1 ^(k) −t _n ^(k) )−S(k, n)|/β(k, n) or both may be visualized. Similarly, in addition to the label indicating "abnormality signs present" (or instead of the label indicating "abnormality indications present"), |(t _n+1 ^(k) -t _n ^(k) ) - S(k, n )|/β(k,n) may be visualized. This allows the user to understand whether or not an abnormality sign exists as a continuous numerical value in addition to (or instead of) a label with a discrete meaning. becomes.

[Hardware configuration example]
The application processing device 10, log storage device 20, and monitoring support device 30 according to the first and second embodiments are realized, for example, by the hardware configuration of a computer 500 shown in FIG. 19. The computer 500 shown in FIG. 19 includes an input device 501, a display device 502, an external I/F 503, a communication I/F 504, a RAM (Random Access Memory) 505, a ROM (Read Only Memory) 506, and an auxiliary memory. It has a device 507 and a processor 508. Each of these pieces of hardware is communicably connected via a bus 509.

The input device 501 is, for example, a keyboard, a mouse, a touch panel, a physical button, or the like. The display device 502 is, for example, a display, a display panel, or the like. Note that the computer 500 may not include at least one of the input device 501 and the display device 502, for example.

The external I/F 503 is an interface with an external device such as a recording medium 503a. The computer 500 can read from and write to the recording medium 503a via the external I/F 503. Note that examples of the recording medium 503a include a CD (Compact Disc), a DVD (Digital Versatile Disk), an SD memory card (Secure Digital memory card), and a USB (Universal Serial Bus) memory card.

Communication I/F 504 is an interface for connecting computer 500 to a communication network. The RAM 505 is a volatile semiconductor memory (storage device) that temporarily holds programs and data. The ROM 506 is a nonvolatile semiconductor memory (storage device) that can retain programs and data even when the power is turned off. The auxiliary storage device 507 is a storage device such as an HDD, SSD, or flash memory. The processor 508 is, for example, an arithmetic device such as a CPU.

The application processing device 10, log storage device 20, and monitoring support device 30 according to the first and second embodiments realize the various processes described above by having the hardware configuration of the computer 500 shown in FIG. 19, for example. can do. Note that the hardware configuration of the computer 500 shown in FIG. 19 is an example, and the application processing device 10, the log storage device 20, and the monitoring support device 30 may be realized by various other hardware configurations.

[summary]
As described above, the monitoring support device 10 according to the present embodiment collects and visualizes logs of a service realized by cooperation of multiple applications, thereby monitoring abnormality signs of the service. We can support you. Therefore, the user can know the signs of an abnormality before it actually occurs, and can take various measures to prevent the abnormality from occurring (for example, replacing equipment or parts). becomes possible.

Note that the first and second embodiments above assume a case where the user monitors signs of abnormality in a service that is actually in operation, but these embodiments are also applicable not only to operation monitoring, but also to It can also be applied to situations such as debugging multiple applications that implement a service.

The present invention is not limited to the above-described specifically disclosed embodiments, and various modifications and changes, combinations with known techniques, etc. can be made without departing from the scope of the claims. be.

1 Log management system 10 Application processing device 20 Log storage device 30 Monitoring support device 100 Application 101 Application processing section 102 Individual log management section 103 Internal log storage section 210 Individual log storage section 300 Monitoring support program 301 Condition reception section 302 Individual log request section 303 General log management section 304 Log visualization section 305 Service type table storage section 306 General log storage section 307 Index value calculation section 308 Standard time table storage section 500 Computer 501 Input device 502 Display device 503 External I/F
503a Recording medium 504 Communication I/F
505 RAM
506 ROM
507 Auxiliary storage device 508 Processor 509 Bus N Communication network

Claims (12)

A monitoring support device that supports monitoring of signs of abnormality in a service realized by linking multiple applications,
a reception unit configured to receive a target service representing a service to be monitored and a target period representing a period to be monitored;
a request unit configured to request logs for the target period from a plurality of applications that implement the target service;
a visualization unit configured to visualize information for monitoring the presence or absence of abnormality signs of the target service during the target period using logs returned from the plurality of applications as a response to the request;
A monitoring support device with The requesting unit is
Referring to a table in which services and applications that implement the services are associated, multiple applications that implement the target service are identified, and logs for the target period are requested from the identified multiple applications. The monitoring support device according to claim 1, wherein the monitoring support device is configured to. The table further associates a service type with which the application identifies the service,
The requesting unit is
With reference to the table, a plurality of applications that realize the target service and a service type that identifies the target service in each of the plurality of applications are identified, and for the identified plurality of applications, The monitoring support device according to claim 2, wherein the monitoring support device is configured to request a log of a corresponding service type and of the target period. The visualization unit includes:
A comprehensive log is created from logs returned from the plurality of applications in response to the request, and the comprehensive log is visualized as information for monitoring the presence or absence of abnormality signs in the target service during the target period. The monitoring support device according to any one of claims 1 to 3. The visualization unit includes:
The monitoring support device according to claim 4, wherein the monitoring support device is configured to visualize the comprehensive log in chronological order for each comprehensive log of a process for realizing one target service. The comprehensive log is
The monitoring support device according to claim 5, wherein the monitoring support device is either a log returned from the plurality of applications as a response to the request, or information obtained by adding information regarding the reply source application to the log. further comprising an index value calculation unit configured to calculate a predetermined index value from the comprehensive log,
The visualization unit includes:
The monitoring support device according to claim 6, further configured to visualize a label indicating the presence or absence of the abnormality sign determined from the index value. The index value calculation unit includes:
A difference between a time width between temporally adjacent comprehensive logs in a process for realizing one target service and a preset standard time width between the comprehensive logs is calculated as the index value. It is configured,
The visualization unit includes:
The monitoring support device according to claim 7, wherein the monitoring support device is configured to determine the value of the label based on a magnitude relationship between the difference and a preset allowable time width, and to visualize a label having the determined value. . The visualization unit includes:
The monitoring support device according to claim 8, further configured to visualize a ratio between the difference and the allowable time width. The permissible time width includes a first permissible time width and a second permissible time period that is larger than the first permissible time width,
The visualization unit includes:
If the difference is less than the first allowable time width, determine a value indicating that there is no abnormality sign as the value of the label,
If the difference is greater than or equal to the first permissible time range and less than the second permissible time range, determine a value representing that there is a risk that the abnormality sign will occur as the value of the label;
The monitoring support device according to claim 8, wherein when the difference is equal to or larger than the second allowable time width, a value indicating that the abnormality sign exists is determined as the value of the label. A monitoring support device that supports monitoring of signs of abnormality in services realized by linking multiple applications.
a reception procedure for receiving a target service representing a service to be monitored and a target period representing a period to be monitored;
a request procedure for requesting logs for the target period from a plurality of applications that implement the target service;
a visualization procedure for visualizing information for monitoring the presence or absence of abnormality signs in the target service during the target period using logs returned from the plurality of applications in response to the request;
Monitoring support method to perform. A monitoring support device that supports monitoring of signs of abnormality in services realized by linking multiple applications.
a reception procedure for receiving a target service representing a service to be monitored and a target period representing a period to be monitored;
a request procedure for requesting logs for the target period from a plurality of applications that implement the target service;
a visualization procedure for visualizing information for monitoring the presence or absence of abnormality signs in the target service during the target period using logs returned from the plurality of applications in response to the request;
A program to run.

Images