JP7697982B2 - Log analysis device, log analysis method, and log analysis program - Google Patents

Description

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

For example, in a system running on a computer, a log including event results or messages is output. When an abnormality occurs in the system, a user identifies the cause of the abnormality by analyzing the output log. A conventional device for analyzing logs is disclosed in, for example, Patent Document 1.

International Publication No. 2017/169949

However, Patent Document 1 does not mention anything about improving the efficiency and accuracy of log analysis and shortening the time it takes to resolve issues by approximately converting the logs output from the monitored object from detailed information, such as traces, to summary information, such as metrics, and visualizing information of different granularities in a unified data format to facilitate comparison.

The present invention has been made in consideration of the above, and aims to provide a log analysis device, a log analysis method, and a log analysis program that can improve the efficiency and accuracy of log analysis and shorten the time it takes to solve problems by approximately converting logs output from a monitored object from detailed information, such as traces, to summary information, such as metrics, and visualizing information of different granularities in a unified data format to facilitate comparison.

To solve the above problems and achieve the objective, the present invention is characterized by comprising an acquisition means for acquiring metrics for checking the overview of the log output from the monitored object and a trace for checking the details, a conversion means for converting the trace to approximate the data format of the metrics to be compared, and an output means for displaying and outputting the metrics to be compared and the converted trace on a comparison analysis screen.

According to one aspect of the present invention, the trace includes information on a process, which is a unit that records the log to be converted or a unit that logically aggregates the callers of that process, the end time, the processing time, and a weight, which is an index of the conversion source that corresponds to the metric to be compared.

According to one aspect of the present invention, the process may include a screen name or a job name in an application log, a URI of a web server, or a stored procedure or a function name in a database log, and the weight may include CPU time, which is a CPU load, physical reads, which is a memory load, physical reads and writes, which is a disk load, or the number of data rows retrieved and the number of rows to be updated, which are network loads.

According to one aspect of the present invention, the conversion means may calculate the start time of the trace from the end time and processing time, calculate the average weight per acquisition interval of the metric to be compared, map the calculated weight per time into a time series table, generate a stacked graph with the horizontal axis representing time and the vertical axis representing the magnitude of the weight, and treat the waveform of the stacked graph as an approximation of the metric to be compared.

According to one aspect of the present invention, the conversion means may be provided with a load ranking generation function that generates a load ranking for each process for a specific period based on a table that maps the calculated weights per unit time to a time series.

According to one aspect of the present invention, the conversion means may have a simulation function that changes the processing weights for each time period through user operation and generates a stacked graph of the changed weights with the horizontal axis representing time and the vertical axis representing the magnitude of the weights.

In order to solve the above-mentioned problems and achieve the object, the present invention is a log analysis method executed by an information processing device having a control unit, and is characterized by including an acquisition step of acquiring metrics for checking an overview of a log output from a monitoring target and a trace for checking details, a conversion step of converting the trace to approximate the data format of the metrics to be compared, and an output step of displaying and outputting the metrics to be compared and the converted trace on a comparison analysis screen.

In order to solve the above-mentioned problems and achieve the object, the present invention provides a log analysis program to be executed by an information processing device having a control unit, the program comprising: an acquisition step of acquiring metrics for checking an overview of a log output from a monitoring target and a trace for checking the details; a conversion step of converting the trace so as to approximate a data format of the metrics to be compared;
and an output step of displaying and outputting the metrics to be compared and the converted trace on a comparison analysis screen.

According to the present invention, by performing an approximate conversion of logs output from monitored objects, from detailed information (traces) to summary information (metrics), and visualizing information of different granularities in a unified data format to facilitate comparison, it is possible to improve the efficiency and accuracy of log analysis.

FIG. 1 is a diagram for explaining the background of the problem. FIG. 2 is a diagram for explaining the background of the problem. FIG. 3 is a block diagram showing an example of a configuration of a log analysis device according to the present embodiment. FIG. 4A is a diagram for explaining an overview of log conversion. FIG. 4B is a diagram for explaining an overview of the log conversion. FIG. 5A is a diagram for explaining a specific example of log conversion. FIG. 5B is a diagram for explaining a specific example of log conversion. FIG. 6 is a diagram for explaining an advanced application example (1). FIG. 7 is a diagram for explaining an advanced application example (2).

An embodiment of the present invention will be described in detail with reference to the drawings. Note that the present invention is not limited to this embodiment.

[1. Overview]
For example, in software monitoring, a log output from a monitoring target contains multiple pieces of information, such as metrics (summary information) for monitoring an overview and traces (detailed information) for monitoring the details.

Traces contain detailed information, but the problem is that the amount of data is large and analysis takes a long time. For this reason, traditionally, anomalies were detected based on aggregated information such as metrics, and the analysis target was narrowed down by investigating traces from the relevant time period. In other words, it was necessary to detect anomalies from an overview and then check the detailed information again.

However, this method requires a human to determine the connections between data, which can result in time-consuming analysis and lead to incorrect judgments. In addition, development and operations teams are typically separate, and different people review each piece of information, meaning there are few opportunities for them to check each other's information.

In this embodiment, we focused on the fact that as the importance of software in society increases, the number of things to be monitored increases, making it urgent to reduce the operational burden, and that since development, operation, and maintenance are all done in one stop, insights can be gained by checking various logs.

In this embodiment, detailed information, or traces, is approximated and converted into summary information, or metrics, and information of different granularity is visualized in a unified data format to facilitate comparison, thereby improving the efficiency and accuracy of analysis and shortening the time it takes to resolve issues.

The background to the issue will be explained in detail with reference to Figures 1 and 2. The logs required for software monitoring are provided by various systems such as the OS and MW (middleware), but it is difficult to respond without checking these systems. In addition, there are the following types of logs, and because the granularity differs, it is difficult to understand the correspondence between logs from the same period.

Metrics are logs that record and process activity. Generally, they are aggregated data over a certain period of time, and while it is possible to check the status with a small amount of data, it is difficult to perform detailed cause analysis. An example of a metric is a Windows (registered trademark) performance log (which records the average CPU usage in 1-second or 15-second intervals, etc.).

A trace is a log that records what happened in chronological order. Generally, it is data that sequentially records the processes that occur within a program, and although it is possible to analyze the causes, it has the characteristic that the data volume is large, which means that the storage capacity and analysis costs are high. An example of a trace is an extended event in SQL Server (which can record the start and end of a specific process, the resources consumed by that process, etc.).

Figure 1 shows an example of metrics (CPU usage obtained using the Windows (registered trademark) performance monitor). The horizontal axis is the time axis, and the vertical axis is a plot of CPU usage.

Figure 2 shows an example of a trace (SQL Server extended event). Processing time, CPU time, number of physical reads, etc. can be confirmed. The results of recording the completion of processing in the extended event were transcribed into Excel, and the horizontal axis is the time axis and the vertical axis is the cpu_time column.

Both of the above examples are indicators that focus on the CPU, but the log granularity is different, making it difficult to analyze causal relationships. With tracing, the time of completion is recorded, so the relationship with the start time of the process (= the time when CPU use began) or utilization rate is unclear.

Metrics records "utilization rate," while tracing records "CPU time," so a conversion is necessary. "CPU time" is the time the CPU is used for the relevant process. For simplicity's sake, on a server with only one CPU core, if a process that places a load on the CPU is executed, it will be recorded as shown below.

When process A, which can be completed in 10 seconds by itself, is executed, the processing time for process A is 10 seconds and the CPU time is 10 seconds. When process A and process B, which can be completed in 10 seconds by themselves, are executed simultaneously, the processing time for process A is 20 seconds and the CPU time is 10 seconds, and the processing time for process B is 20 seconds and the CPU time is 10 seconds.

In this invention, by converting traces (detailed information) into metrics (summary information) format, the time required from understanding the situation to analyzing the cause is shortened.

The log analysis device of the present invention can be applied to all business types and industries.

2. Configuration
An example of the configuration of the log analysis device 100 according to this embodiment will be described with reference to Fig. 3. Fig. 3 is a block diagram showing an example of the configuration of the log analysis device 100.

The log analysis device 100 is, for example, a commercially available desktop personal computer or a workstation.

The log analysis device 100 includes a control unit 102, a communication interface unit 104, a memory unit 106, and an input/output interface unit 108. Each unit included in the log analysis device 100 is connected to each other so as to be able to communicate with each other via any communication path.

The communication interface unit 104 communicatively connects the log analysis device 100 to the network 300 via a communication device such as a router and a wired or wireless communication line such as a dedicated line. The communication interface unit 104 has a function of communicating data with other devices via the communication line. Here, the network 300 has a function of communicatively connecting the log analysis device 100, the server 200, and a system to be monitored (not shown) to each other, and is, for example, the Internet or a LAN (Local Area Network).

An input device 112 and an output device 114 are connected to the input/output interface unit 108. The output device 114 may be a monitor (including a home television), a speaker, or a printer. The input device 112 may be a keyboard, a mouse, a microphone, or a monitor that works with a mouse to achieve a pointing device function. In the following, the output device 114 may be referred to as the monitor 114, and the input device 112 may be referred to as the keyboard 112 or the mouse 112. Displaying information on the monitor 114 and the user operating the input device 112 may be referred to as "user operation via a UI."

The storage unit 106 stores various databases, tables, files, and the like. The storage unit 106 records computer programs that work with the OS (Operating System) to give instructions to the CPU (Central Processing Unit) to perform various processes. As the storage unit 106, for example, a memory device such as a RAM (Random Access Memory) or a ROM (Read Only Memory), a fixed disk device such as a hard disk, a flexible disk, an optical disk, and the like can be used. The storage unit 106 stores information such as traces and metrics.

The control unit 102 is a CPU or the like that performs overall control of the log analysis device 100. The control unit 102 has an internal memory for storing control programs such as an OS, programs that define various processing procedures, required data, etc., and executes various information processing operations based on these stored programs.

The control unit 102 is configured to be able to access information such as traces and metrics stored in the memory unit 106. Note that information such as traces and metrics may be stored elsewhere (e.g., in the server 200) as long as it is accessible by the control unit 102.

The control unit 102 conceptually comprises an acquisition unit 102a, a conversion unit 102b, and an output unit 102c.

The acquisition unit 102a acquires metrics for checking the overview of the logs output from the monitored system and traces for checking the details, and stores them in the memory unit 106.

The conversion unit 102b converts the trace to approximate the data format of the metric to be compared.

In this case, the "trace" may include information on the process, which is the unit that records the log to be converted or the unit that logically aggregates the callers of that process, the end time, the processing time, and the weight, which is the index of the conversion source that corresponds to the metric to be compared.

"Processing" may include the screen name or job name in the application log, the URI of the web server, or the stored procedure or function name in the database log. "Weight" may include CPU time, which is the CPU load, physical reads, which is the memory load, physical reads and writes, which are the disk load, or the number of rows of data retrieved or the number of rows to be updated, which are the network load.

The conversion unit 102b may also calculate the start time of a trace from the end time and processing time, calculate the average weight per acquisition interval of the metric to be compared, map the calculated weight per time into a time series table, generate a stacked graph with the horizontal axis representing time and the vertical axis representing the magnitude of the weight, and treat the waveform of the stacked graph as an approximation of the metric to be compared.

The conversion unit 102b may also be provided with a load ranking generation function that generates a load ranking for each process for a specific period based on a table that maps the calculated weights per time to a time series.

The conversion unit 102b may also have a simulation function that changes the processing weight for each time period in response to user operations and generates a stacked graph of the changed weight with the horizontal axis representing time and the vertical axis representing the magnitude of the weight.

The output unit 102c displays and outputs the metrics to be compared and the converted trace on the comparison analysis screen of the monitor 114, visualizing the two for easy comparison.

3. Specific Examples
A specific example of the process of the control unit 102 of the log analysis device 100 in this embodiment will be described with reference to Fig. 3 to Fig. 7. Fig. 4 to Fig. 7 are diagrams for explaining a specific example of the process of the control unit 102 of the log analysis device 100 in this embodiment.

(3-1. Overview of log transformation)
An overview of the log conversion executed by the conversion unit 102b will be described with reference to Figures 4A and 4B. Figures 4A and 4B are diagrams for explaining an overview of the log conversion executed by the conversion unit 102b.

The conversion unit 102b converts point information called traces into line information called metrics. Here, the definitions of "processing" and "weight" are as follows:

"Processing" refers to the unit that records the log that is the source of conversion, such as a trace, or the unit that logically aggregates the callers of that processing. For example, "processing" could be an application log: screen name or job name, a web server: URI, or a database log (extended events, etc.): stored procedure or function name.

"Weight" is the original index (explained here based on extended events) that corresponds to the metric to be compared. For example, "weight" is CPU load: CPU time, memory load: physical read (read from disk occurs when data is not present in the cache), disk load: physical read/write, network load: number of rows retrieved, number of rows to be updated.

(1) In tracing, point information is recorded as described above. FIG. 4A (A) is a diagram showing an example of recorded trace information. In this example, process A has an end time of "09:40", a processing time of "0:20", and a weight of "60", process B has an end time of "10:00", a processing time of "0:50", and a weight of "50", and process C has an end time of "10:40", a processing time of "1:10", and a weight of "70".

(2) The start time is calculated from the end time and processing time. Figure 4A (B) shows an example of calculated start times. Process A has a start time of "09:20 (=09:40-0:20)", process B has a start time of "09:10 (=10:00-0:50)", and process C has a start time of "09:30 (=10:40-1:10)".

(3) Calculate the average weight per acquisition interval (10 minutes in this example) of the metrics to be compared. Figure 4B (C) is a diagram showing an example of calculating the weight per hour. For process A, the weight per hour is "3 (=60÷20)", for process B, the weight per hour is "1 (=50÷50)", and for process C, the weight per hour is "1 (=70÷70)".

(4) The calculated hourly weights are mapped onto a time series table. Figure 4B (D) shows an example of the calculated hourly weights mapped onto a time series table (10-minute intervals).

(5) A stacked graph is generated with the horizontal axis representing time and the vertical axis representing the magnitude of weight. Fig. 4B (E) shows the weights versus time for each of processes A, B, and C. Fig. 4B (F) shows an example of a stacked graph for processes A, B, and C with the horizontal axis representing time and the vertical axis representing the magnitude of weight.
The waveform of this stacked graph is an approximation of the metric.

(3-2. Specific examples of log transformation)
A specific example of the log conversion described in the overview of log conversion will be described with reference to Figures 5A and 5B. Figures 5A and 5B are diagrams for explaining a specific example of log conversion by the conversion unit 102b. In the following, a case where trace is an extended event (SQL Server log), process is a stored procedure, and weight is CPU time will be described.

(1) In a trace, point information is recorded as described above. FIG. 5A (A) is a diagram showing an example of recorded trace information. In this example, stored procedure A has a finish time of "09:40", a processing time of "0:20", and a CPU time of "1:00", stored procedure B has a finish time of "10:00", a processing time of "0:50", and a CPU time of "0:50", and stored procedure C has a finish time of "10:40", a processing time of "1:10", and a CPU time of "1:10".

(2) The start time is calculated from the end time and processing time. Figure 5A (B) shows an example of calculated start times. Stored procedure A has a start time of "09:20 (=09:40-0:20)," stored procedure B has a start time of "09:10 (=10:00-0:50)," and stored procedure C has a start time of "09:30 (=10:40-1:10)."

(3) Calculate the average number of CPU cores used per interval (10 minutes in this example) for obtaining the metrics to be compared. Note that if the CPU time is greater than the processing time, it is assumed that parallel processing is being performed using multiple cores.

Figure 5A (C) shows an example of calculating the average number of CPU cores in use. For stored procedure A, the number of CPU cores in use per hour is "3 (=60÷20)", for stored procedure B, the number of CPU cores in use per hour is "1 (=50÷50)", and for stored procedure C, the number of CPU cores in use per hour is "1 (=70÷70)".

(4) The calculated weight per hour is mapped to a time series table. Figure 5A (D) shows an example of mapping the calculated number of CPU cores used per hour to a time series table (10-minute intervals).

(5) A stacked graph is generated with the horizontal axis representing time and the vertical axis representing the number of CPU cores in use. FIG. 5B (E) shows the weights for each of stored procedures A, B, and C with respect to time. FIG. 5B (F) shows an example of a stacked graph (approximate values) for stored procedures A, B, and C with the horizontal axis representing time and the vertical axis representing the number of CPU cores in use. FIG. 5B (G) shows an example of a metrics graph with the horizontal axis representing time and the vertical axis representing CPU usage. The metrics to be compared in FIGS. 5B (E) and (F) and the converted trace are displayed and visualized on a comparison display screen by the output unit 102c.

As shown in Figures 5B (F) and (G), the cause of the abnormal value detected by monitoring the metrics can be identified as stored procedure A (processing A) by comparing it with the converted trace.

In this example, CPU time was used as the criterion for "weight," making it possible to analyze processes where the CPU is a bottleneck. In addition, if physical reads were used as the criterion for "weight," it would be possible to analyze processes where disk IO is a bottleneck, and if network transfer volume, such as the number of retrieved rows, is used as the criterion, it would be possible to analyze processes where network IO is a bottleneck.

In this way, according to this embodiment, general-purpose log conversion is possible by changing the "weight" criteria depending on the viewpoint you want to analyze.

(3-3. Advanced application example (1))
An advanced application example (1) will be described with reference to FIG. 6. FIG. 6 is a diagram for explaining the advanced application example (1). The conversion unit 102b may have a load ranking generation function that generates a load ranking of each process for a specific period based on a table in which the calculated weight per unit time is mapped in a time series, and displays and outputs the load ranking on a load ranking screen (not shown). By using a table of calculation results for finding an approximate value of the metrics based on the weight of the unit time value (FIG. 4B(D)), a ranking of the processes that applied the most load in a specific period can be generated.

As shown in Figures 6(A) to 6(D), a load ranking for a specific period is generated. Specifically, for example, processes are sorted in descending order of load for each specific period.

Figure 6 (A) shows the load rankings as of 09:10. Process B is the process that is exerting the most load as of 09:10.

Figure 6 (B) shows the load rankings as of 09:20. Process A is the process that is exerting the most load as of 09:20.

Figure 6 (C) shows the load rankings at 10:00. Process C is the process with the highest load at 10:00.

Figure 6 (D) shows the load ranking for the entire period. Process C is the process that exerts the greatest load over the entire period.

This makes it easier to triage issues, such as prioritizing processes that are important for business purposes, even if different processes are the cause at different times of the day.

(3-4. Advanced application example (2))
An advanced application example (2) will be described with reference to Fig. 7. Fig. 7 is a diagram for explaining the advanced application example (2). The conversion unit 102b may have a simulation function for changing the weight of the process in each time period in response to a user operation on a simulation screen (not shown) and generating a stacked graph of the changed weight with the horizontal axis representing time and the vertical axis representing the magnitude of the weight. That is, a simulation function for the load improvement effect is provided, and by manually changing the weight in each time period, it becomes possible to simulate in advance the effect of tuning the process on the metrics.

Figure 7(A) shows an example of mapping the calculated hourly weights to a time series table (10-minute intervals), similar to Figure 4B(C). Figure 7(B) shows the case where the operator changes the weight of process A from "3" to "1".

Figure 7(C) shows a stacked graph when the weight of process A is "3", and is similar to Figure 4B(F). Figure 7(D) shows a stacked graph when the weight of process A is changed to "1". As shown in the figure, the maximum weight has been improved from "5" to "3".

This makes it possible to simulate in advance the investment effect of improving processing, making it easier to make investment decisions. Thus, according to this embodiment, by converting the display format of logs of different granularity and types, it becomes possible to quickly and reliably respond to abnormalities.

As described above, according to this embodiment, there is provided an acquisition unit 102a that acquires metrics for checking the overview of the log output from the monitored object and traces for checking the details, a conversion unit 102b that converts the traces to approximate the data format of the metrics of the comparison object, and an output unit 102c that displays and outputs the metrics of the comparison object and the converted traces on a comparison analysis screen. Therefore, for the log output from the monitored object, an approximate conversion is performed from the traces, which are detailed information, to metrics, which are summary information, and information of different granularities is visualized in a unified data format to facilitate comparison, thereby improving the efficiency and accuracy of log analysis and shortening the time to resolve the problem.

[4. Contribution to the United Nations-led Sustainable Development Goals (SDGs)]
This embodiment can contribute to improving business efficiency and promoting appropriate management decisions by companies, thereby making it possible to contribute to goals 8 and 9 of the SDGs.

In addition, this embodiment can contribute to reducing waste and promoting paperless and electronic systems, which can contribute to the achievement of SDGs goals 12, 13, and 15.

In addition, this embodiment can contribute to strengthening control and governance, making it possible to contribute to Goal 16 of the SDGs.

5. Other embodiments
The present invention may be embodied in various different embodiments other than those described above within the scope of the technical concept set forth in the claims.

For example, among the processes described in the embodiments, all or part of the processes described as being performed automatically can be performed manually, or all or part of the processes described as being performed manually can be performed automatically using a known method.

In addition, the processing procedures, control procedures, specific names, registered data for each process, information including parameters such as search conditions, screen examples, and database configurations shown in this specification and drawings may be changed as desired unless otherwise specified.

Furthermore, with regard to the log analysis device 100, each component shown in the figure is a functional concept, and does not necessarily have to be physically configured as shown in the figure.

For example, the processing functions of the log analysis device 100, particularly the processing functions performed by the control unit, may be realized in whole or in part by a CPU and a program interpreted and executed by the CPU, or may be realized as hardware using wired logic. The program is recorded on a non-transient computer-readable recording medium that contains programmed instructions for causing the information processing device to execute the processes described in this embodiment, and is mechanically read by the log analysis device 100 as necessary. That is, a computer program is recorded in a storage unit such as a ROM or HDD (Hard Disk Drive) for working with the OS to give instructions to the CPU and perform various processes. This computer program is executed by being loaded into RAM, and works with the CPU to form the control unit.

In addition, this computer program may be stored in an application program server connected to the log analysis device 100 via any network, and it is also possible to download all or part of it as needed.

In addition, the program for executing the processing described in this embodiment may be stored in a non-transitory computer-readable recording medium, and may also be configured as a program product. Here, the term "recording medium" refers to a memory card, a USB (Universal Serial Bus) memory, a SD (Secure Digital) card, a flexible disk, a magneto-optical disk, a ROM, an EPROM (Erasable Programmable Read Only Memory), an EEPROM (registered trademark) (Electrically Erasable and Programmable Read Only Memory), a CD-ROM (Compact Disk Read Only Memory), an MO (Magneto-Optical disk), a DVD (Digital Versatile This includes any "portable physical media" such as a DVD (registered trademark) or Blu-ray (registered trademark) Disc.

A "program" is a data processing method written in any language or description method, and may be in any format, such as source code or binary code. Note that a "program" is not necessarily limited to a single configuration, but also includes a distributed configuration consisting of multiple modules or libraries, and a program that works in conjunction with a separate program, such as an OS, to achieve its function. Note that the specific configuration and reading procedure for reading a recording medium in each device shown in the embodiments, as well as the installation procedure after reading, can use well-known configurations and procedures.

The various databases stored in the memory unit are storage devices such as RAM, ROM, etc., fixed disk devices such as hard disks, flexible disks, and optical disks, and store various programs, tables, databases, and web page files used for various processes and providing websites.

The log analysis device 100 may be configured as an information processing device such as a known personal computer or workstation, or may be configured as the information processing device to which any peripheral device is connected. The log analysis device 100 may be realized by implementing software (including programs or data, etc.) that causes the device to realize the processing described in this embodiment.

Furthermore, the specific form of distribution and integration of the devices is not limited to that shown in the figures, and all or part of them can be functionally or physically distributed and integrated in any unit depending on various additions or functional loads. In other words, the above-mentioned embodiments can be implemented in any combination, or the embodiments can be implemented selectively.

REFERENCE SIGNS LIST 100 Log analysis device 102 Control unit 102a Acquisition unit 102b Conversion unit 102c Output unit 104 Communication interface unit 106 Storage unit 108 Input/output interface unit 112 Input device 114 Output device 200 Server 300 Network

Claims (8)

A means for acquiring metrics to check the overview of logs output from the monitored object and traces to check the details;
A conversion means for converting the trace to approximate a data format of a metric to be compared;
an output means for displaying and outputting the metrics to be compared and the converted trace on a comparison analysis screen;
A log analysis device comprising: The log analysis device according to claim 1, characterized in that the trace includes information on a process that is a unit that records the log to be converted or a unit that logically aggregates the callers of that process, an end time, a processing time, and a weight that is an index of the conversion source corresponding to the metric to be compared. The process includes a screen name or a job name in an application log, a URI of a web server, or a stored procedure or a function name in a DB log,
The log analysis device according to claim 2, characterized in that the weighting includes CPU time, which is a CPU load, physical reads, which is a memory load, physical reads and writes, which is a disk load, or the number of data rows retrieved and the number of rows to be updated, which are network loads. The conversion means is
Calculating a start time for the trace from an end time and a processing time;
Calculate the average weight per interval of the metrics to be compared,
The calculated weights per hour are mapped onto a time series table.
4. The log analysis device according to claim 3, wherein a stacked graph is generated with the horizontal axis representing time and the vertical axis representing the magnitude of weight, and the waveform of the stacked graph is taken as an approximation value of the metric to be compared. The log analysis device according to claim 4, characterized in that the conversion means has a load ranking generation function that generates a load ranking of each process for a specific period based on a table that maps the calculated weight per time to a time series. The log analysis device according to claim 4, characterized in that the conversion means has a simulation function for changing the processing weight for each time period through a user operation and generating a stacked graph of the changed weight with the horizontal axis representing time and the vertical axis representing the magnitude of the weight. A log analysis method executed by an information processing device having a control unit,
An acquisition process for acquiring metrics to check an overview of logs output from the monitored object and traces to check details;
A conversion step of converting the traces to approximate a data format of a metric to be compared;
and an output step of displaying and outputting the metrics to be compared and the converted trace on a comparison and analysis screen. A log analysis program to be executed by an information processing device having a control unit,
An acquisition process for acquiring metrics to check an overview of logs output from the monitored object and traces to check details;
A conversion step of converting the traces to approximate a data format of a metric to be compared;
an output step of displaying and outputting the metrics to be compared and the converted trace on a comparison analysis screen;
A log analysis program that causes a computer to run the following:

Images