JP5440164B2 - Analysis program and control program - Google Patents

Description

The invention analysis program for analyzing the transaction relates min析方method及beauty analysis device.

  Computer systems using recent IT (information and communication technology) often have large-scale and complicated configurations. For example, an increasing number of business services such as online banking payment and transfer processing are provided by a Web three-tier system including a Web server / application server / database (DB) server. Such a system has a large-scale and complicated configuration for reasons such as operational efficiency and security measures. In addition, there are many business services that require immediacy, and service suspension and response deterioration are major problems. Therefore, it is essential to grasp the operational status for large-scale systems in detail and to quickly solve performance problems.

  In addition, in a complex system (such as a Web three-tier system) in which multiple applications work together, in order to determine the cause of performance degradation and failure, not only the behavior of each server but also the performance of the entire system is observed and analyzed. It is necessary to. For example, in a Web three-tier system, a processing request to an application server may occur with a processing request to a Web server. The same applies to the application server / DB server. Such a call relationship of processing between applications is indispensable for investigating the spread of performance problems into the system.

  Therefore, a function for tracking the processing of each application from a user request to a response is desired. If such tracking becomes possible, it becomes easy to analyze problems existing in the system.

  As a technique for tracking the delivery of processing between servers, for example, there is a technique in which an agent is installed in each server, and the agent analyzes and reports the operation status of each server (see, for example, Non-Patent Document 1).

  A technique for grasping an operation state by an agent and reporting the result has been put into practical use (for example, see Non-Patent Documents 2 and 3).

"Technical Standard Application Response Measurement (ARM) Issue 4.0-C Binding", THE OPEN GROUP, October 2003, Figure 2 "IBM Tivoli Monitoring for Transaction Performance helps maximize performance of your applications.", "IBM Corporation Software Group", September 2003 "IBM Tivoli Monitoring for Transaction Performance, Version 5.2", "IBM Corporation Software Group", September 2003

  However, in the conventional technology, when acquiring detailed information for each application, it is necessary to incorporate some application such as an agent into each server. Therefore, it is difficult to analyze the performance of existing systems. In particular, recent systems are created by different companies for each application. Therefore, it is difficult to improve all applications so as to exchange information with agents.

The present invention has been made in view of these points, analysis program that can analyze transactions without touching the service providing function of the system, aims to provide a partial析方method及beauty analysis device And

In the present invention, in order to solve the above-mentioned problem, in an analysis program for analyzing a transaction executed in a system in which a plurality of servers are arranged, the analysis program is delivered to a computer via a network connecting the plurality of servers. A procedure for collecting messages, a storage procedure for analyzing the contents of the collected messages and storing information about a message pair of a request message and a response message in a storage means, and reading the information from the storage means to obtain a call relationship An analysis program for executing a model generation procedure for generating a transaction model having the obtained calling relationship is provided.

In addition, in order to solve the above-described problem, an analyzer for analyzing transactions executed in a system in which a plurality of servers are arranged collects messages passed through a network connecting the plurality of servers. Means for analyzing the contents of the collected messages, storing means for storing information on a message pair of a request message and a response message in the storage means, and reading the information from the storage means when a model generation instruction is input There is provided an analyzer having model generation means for determining a call relationship and generating a transaction model having the determined call relationship .

Further, in order to solve the above problem, in an analysis method for analyzing a transaction executed in a system in which a plurality of servers are arranged, a message passed by a computer via a network connecting the plurality of servers And analyzing the contents of the collected message, storing information about the message pair of the request message and the response message in the storage means, and reading the information from the storage means when a model generation instruction is input An analysis method for obtaining a call relationship and generating a transaction model having the found call relationship is provided.

In the present invention, it is possible to generate a transaction model from message set.

It is a conceptual diagram of the invention applied to embodiment. It is a figure which shows the system configuration | structure which concerns on 1st Embodiment. It is a figure which shows the hardware structural example of a system analyzer. It is a figure which shows the functional block of a system analyzer. It is a flowchart which shows the procedure of a system analysis process. It is a conceptual diagram which shows a message observation condition. It is a figure which shows the example of a data structure of a packet data storage part. It is a figure which shows the information contained in a packet. It is a figure which shows the detail of an IP header. It is a figure which shows the detail of a TCP header. It is a block diagram which shows the function of a message analysis part. It is an example of a reconfigured session. It is a 1st figure which shows the example of a message reconstruction. It is a figure which shows the example of matching of the response message to a request. It is a figure which shows the example of assignment of an object name. It is a figure which shows assignment of the object name of each message which comprises one transaction, and a message analysis result. It is a figure which shows the example of a protocol log. It is a figure which shows the example of the protocol log stored in the protocol log memory | storage part. It is a flowchart which shows a transaction model production | generation process. It is a figure which shows the message for model generation selected. It is a figure which shows the model generation example of a "balance confirmation" transaction. It is a figure which shows the example of model generation of a "deposit" transaction. It is a flowchart which shows the procedure of an analysis process. It is a figure which shows the example of the message input into an analysis part. It is a 1st figure which shows the example of a message analysis. It is a 2nd figure which shows the example of a message analysis. It is a 3rd figure which shows the example of a message analysis. It is a 4th figure which shows the example of a message analysis. It is a 5th figure which shows the example of a message analysis. It is a 6th figure which shows the example of a message analysis. It is a 7th figure which shows the example of a message analysis. It is an 8th figure which shows the example of a message analysis. It is a 9th figure which shows the example of a message analysis. It is a 10th figure which shows the example of a message analysis. It is a figure which shows the example of a display of the average processing time of a server. It is a figure which shows the example of a display of the processing time according to transaction, and a breakdown. It is a figure which shows the example of a display of a processing time histogram. It is a figure which shows the example of a screen at the time of displaying a some information simultaneously. It is a figure which shows the mode of the cooperation between display object elements. It is a figure which shows the example of the message input into an analysis part. It is a figure which shows the process recognized from the message input into the model production | generation part. It is a figure which shows the calling relationship between the processes which satisfy | fill restrictions. It is a figure which shows the example of a call frequency matrix. It is a figure which shows the result of having calculated | required the probability of a call candidate. It is a figure which shows the number-of-calls matrix after an update. It is a figure which shows the result of having calculated | required the probability of a call candidate by the process of the 2nd time. It is a figure which shows the number-of-calls matrix after the 2nd update. It is a figure which shows the call frequency matrix finally obtained, and the transaction model produced | generated. It is a flowchart which shows the transaction model production | generation procedure in 2nd Embodiment. It is a 1st figure which shows the calling pattern from the process classification A, and its probability. It is a 1st figure which shows the calling pattern from the process classification B, and its probability. It is a 2nd figure which shows the calling pattern from the process classification A, and its probability. It is a 2nd figure which shows the calling pattern from the process classification B, and its probability. It is a figure which shows a model production | generation result. It is a flowchart which shows the transaction model production | generation procedure in 3rd Embodiment.

Hereinafter, embodiments of the present invention will be described with reference to the drawings.
First, the outline of the invention applied to the embodiment will be described, and then the specific contents of the embodiment will be described.

  FIG. 1 is a conceptual diagram of the invention applied to the embodiment. The system analysis device 1 is connected to clients 3a, 3b,... And servers 4a, 4b,. The servers 4a, 4b,... Provide services in response to requests from the clients 3a, 3b,. Service provision is performed in cooperation with each other by a plurality of servers 4a, 4b,. At this time, the system analysis apparatus 1 acquires the message 5 transmitted / received via the network 2 and analyzes the operation mode of the network 2. In order to perform analysis, the system analysis apparatus 1 has the functions shown in FIG.

The message observing means 1a collects the messages 5 delivered via the network 2. The collected message 5 is transferred to the message analysis unit 1b.
The message analysis unit 1b analyzes the contents of the collected message to determine the processing type requested by the message and whether it is a request message or a response message (message direction). For example, if the protocol applied to the message is HTTP (HyperText Transfer Protocol), the processing type can be determined by a URL (Uniform Resource Locator) specified in the processing request. Then, the message analysis unit 1b stores the determined information in the protocol log storage unit 1c as a protocol log.

  When the model generation instruction is input, the model generation unit 1d performs each process corresponding to the process type based on the correspondence between the request message and the response message for each process type in the protocol log stored in the protocol log storage unit 1c. recognize. Then, the model generation unit 1d generates a transaction model that satisfies the constraint condition regarding the call relationship between processes based on the message set selected according to the selection criterion based on the probability of the call relationship between processes. The model generation unit 1d stores the generated transaction model in the transaction model storage unit 1e.

  As a selection criterion, for example, it is determined to select a set of messages in a non-multiple transaction time zone whose processing time zone does not overlap with other transactions. The constraint condition is, for example, a condition that the processing time zone of the call source includes the processing time zone of the call destination.

  When the analysis instruction is input, the analysis unit 1f extracts from the protocol log storage unit 1c a protocol log that matches the call relationship indicated by the transaction model stored in the transaction model storage unit 1e. Analyze the processing state of the transaction consisting of the indicated message. For example, the processing time at each server in the transaction is analyzed.

The output unit 1g outputs the analysis result by the analysis unit 1f to a monitor or the like as statistical information that is easily visually recognized, such as a graph.
In the case of such a system analyzing apparatus 1, the message 5 passed through the network 2 is collected by the message observation unit 1a. Then, the content of the collected message is analyzed by the message analysis unit 1b, and the time of occurrence of the message, the processing type requested by the message, and whether it is a request message or a response message are determined, and the determined information is used as a protocol log. It is stored in the protocol log storage means 1c.

  At this time, when a model generation instruction is input, each model corresponding to the processing type is determined by the model generation unit 1d according to the correspondence between the request message and the response message for each processing type in the protocol log stored in the protocol log storage unit. Processing is recognized. Then, a transaction model that satisfies the constraint condition is generated based on the message set selected according to the selection criterion based on the probability of the call relationship between the processes. The generated transaction model is stored in the transaction model storage unit 1e.

  When an analysis instruction is input, a protocol log that matches the calling relationship indicated by the transaction model stored in the transaction model storage unit 1e is extracted from the protocol log storage unit 1c by the analysis unit 1f, and the extracted protocol is extracted. The processing state of the transaction consisting of the message shown in the log is analyzed. The analysis result is output by the output unit 1g and presented to the user.

  As described above, a transaction model is generated from a message set selected according to a selection criterion based on the probability of a call relationship between processes from the message 5 delivered via the network 2. That is, a relationship having a high probability of occurrence is selected as a call relationship between processes, and a transaction established by the relationship is modeled. By detecting a message that matches the transaction model generated in this way from the protocol log, it is possible to identify a set of messages that constitute a common transaction without adding a function to the servers 4a and 4b. Analysis is possible.

Hereinafter, embodiments of the present invention will be described in detail.
[First Embodiment]
The first embodiment is an example in the case where two services of “balance check” and “payment” are provided in a Web three-tier system that provides Internet banking business services.

In the first embodiment, there are “session”, “message”, “object”, and “transaction” as elements to be managed.
A “session” is a set of data transmitted and received on a communication path determined by an IP (Internet Protocol) address and a port number on the transmission / reception side.

  The “message” is a minimum unit of data exchanged by a plurality of devices on a TCP (Transmission Control Protocol) session. For example, an HTTP request or a response to the request corresponds to the message.

  The “object” is a virtual collection of single or plural processes performed from when the server receives a message to when a response is transmitted and input data. The processing referred to here includes calculation in a CPU (Central Processing Unit), input / output of data, waiting time for each, and the like.

A “transaction” is a set of object processes generated by a request to the system.
FIG. 2 is a diagram illustrating a system configuration according to the first embodiment. In the example of FIG. 2, clients 21, 22, 23, Web server 31, application server 32, database (DB) server 33, and system analysis apparatus 100 are connected via the switch 10. The Web server 31, application server 32, and DB server 33 provide services in response to requests from the clients 21, 22, and 23.

  In a transaction for providing a service, a message may be transmitted and received between the Web server 31, the application server 32, and the DB server 33 via the switch 10. The system analysis apparatus 100 monitors messages sent and received via the switch 10 to analyze the system operating state.

  FIG. 3 is a diagram illustrating a hardware configuration example of the system analysis apparatus. The entire system analyzer 100 is controlled by the CPU 101. A random access memory (RAM) 102, a hard disk drive (HDD) 103, a graphic processing device 104, an input interface 105, and a communication interface 106 are connected to the CPU 101 via a bus 107.

  The RAM 102 temporarily stores at least part of an OS (Operating System) program and application programs to be executed by the CPU 101. The RAM 102 stores various data necessary for processing by the CPU 101. The HDD 103 stores an OS and application programs.

  A monitor 11 is connected to the graphic processing device 104. The graphic processing device 104 displays an image on the screen of the monitor 11 in accordance with a command from the CPU 101. A keyboard 12 and a mouse 13 are connected to the input interface 105. The input interface 105 transmits a signal transmitted from the keyboard 12 or the mouse 13 to the CPU 101 via the bus 107.

The communication interface 106 is connected to the switch 10. The communication interface 106 transmits / receives data to / from another computer via the switch 10.
With the hardware configuration as described above, the processing functions of the present embodiment can be realized. FIG. 3 shows an example of the hardware configuration of the system analysis apparatus 100, but the clients 21, 22, 23, the Web server 31, the application server 32, and the DB server 33 are also realized with the same hardware configuration. Can do.

  FIG. 4 is a diagram illustrating functional blocks of the system analysis apparatus. The system analysis apparatus 100 includes a packet data storage unit 111, a protocol log storage unit 112, a model storage unit 113, an analysis result storage unit 114, a message observation unit 120, a message analysis unit 130, a model generation unit 140, an analysis unit 150, and an output Part 160.

  The packet data storage unit 111 is a storage device for storing packets constituting messages transmitted / received via the switch 10. The protocol log storage unit 112 is a storage device for storing message information acquired by analyzing a packet. The model storage unit 113 is a storage device that stores a list (transaction model) of messages that are transmitted and received until a transaction is completed. The analysis result storage unit 114 is a storage device that stores message analysis results.

The message observation unit 120 observes a message transmitted / received via the switch 10 and stores a packet constituting the message in the packet data storage unit 111.
The message analysis unit 130 analyzes the contents of the packet stored in the packet data storage unit 111 and stores the analysis result in the protocol log storage unit 112.

The model generation unit 140 generates a transaction model based on the information stored in the protocol log storage unit 112 and stores it in the model storage unit 113.
The analysis unit 150 compares the information stored in the protocol log storage unit 112 with the transaction model stored in the model storage unit 113, and analyzes statistical information such as the processing time of each transaction. Then, the analysis unit 150 stores the analysis result in the analysis result storage unit 114.

The output unit 160 outputs the analysis result stored in the analysis result storage unit 114 to the monitor 11 or the like as a graph or the like.
The system analysis apparatus 100 configured as described above executes the following system analysis processing.

FIG. 5 is a flowchart showing a procedure of system analysis processing. Hereinafter, the process illustrated in FIG. 5 will be described in order of step number.
[Step S11] The message observation unit 120 observes the message flowing through the switch 10 and stores it in the packet data storage unit 111.

[Step S12] The message analysis unit 130 analyzes the message stored in the packet data storage unit 111.
[Step S13] Thereafter, the model generation unit 140 determines whether or not a model generation instruction is input, and the analysis unit 150 determines whether or not an analysis instruction is input. The model generation instruction and the analysis instruction are given by, for example, an operation input using the keyboard 12 or the like by the administrator of the system analysis apparatus 100. If a model generation instruction has been input, the process proceeds to step S14. If an analysis instruction has been input, the process proceeds to step S15.

  [Step S14] When a model generation instruction is input, the model generation unit 140 refers to the information stored in the protocol log storage unit 112 and generates a transaction model. Then, the model generation unit 140 stores the generated transaction model in the model storage unit 113. Thereafter, the process ends.

  [Step S15] When an analysis instruction is input, the analysis unit 150 is executed with reference to the transaction model stored in the model storage unit 113 and the information stored in the protocol log storage unit 112. Analyze information about transactions. Then, the analysis unit 150 stores the analysis result in the analysis result storage unit 114.

[Step S16] The output unit 160 outputs statistical information and the like to the monitor 11 based on the analysis result stored in the analysis result storage unit 114. Thereafter, the process ends.
System analysis is performed in such a procedure. Hereinafter, the process of each step shown in FIG. 5 will be described in detail.

First, message observation processing will be described.
FIG. 6 is a conceptual diagram showing a message observation situation. In this example, the Web server 31, application server 32, and DB server 33 are monitored. Each server is connected to an individual port 11, 12, 13 of the switch 10. Further, the system management apparatus 100 is connected to the port 14 of the switch 10.

  The switch 10 has a function of mirroring data passing through the switch 10. Mirroring is a function for outputting the same data as data output to a certain port from other ports.

  In the example of FIG. 6, the port to which the system analysis apparatus 100 is connected as a mirroring destination of the port 11 to which the Web server 31 is connected, the port 12 to which the application server 32 is connected, and the port 13 to which the DB server 33 is connected. 14 is designated. Thereby, the packet addressed to each server is input to the destination server and also input to the system analysis apparatus 100.

  For example, it is assumed that the Web server 31, the application server 32, and the DB server 33 provide services in response to a request from the client 21. In this case, first, a packet 41 (for example, an HTTP packet) is transmitted from the client 21 to the Web server 31. At this time, a packet 51 having the same contents as the packet 41 is input to the system analysis apparatus 100. Next, when a packet 42 (for example, an IIOP (Internet Inter-ORB Protocol) packet) is transmitted from the Web server 31 to the application server 32, a packet 52 having the same contents as the packet 42 is input to the system analysis apparatus 100. . Further, when a packet 43 (for example, a DB access packet) is transmitted from the application server 32 to the DB server 33, a packet 53 having the same contents as the packet 43 is input to the system analysis apparatus 100.

  Packets 51, 52, 53 input to the system analysis apparatus 100 are acquired by the message observation unit 120 directly connected to the switch 10 and stored in the packet data storage unit 111. Specifically, the message observation unit 120 captures the packets 51, 52, and 53 sent from the switch 10, and stores them in the packet data storage unit 111 together with the reception time.

  Note that the message observation unit 120 may send the captured packets 51, 52, and 53 to the message analysis unit 130 at the same time as observation without accumulating the captured packets 51, 52, and 53. Further, the message observation unit 120 can also capture only necessary packets in the message observation means. Furthermore, only necessary data can be selected and mirrored in the switch 10.

  FIG. 7 is a diagram illustrating an example of the data structure of the packet data storage unit. The packet data storage unit 111 stores a plurality of packets 551 to 558. The packet data storage unit 111 stores time information 61 to 68 indicating reception times of the packet data 551 to 558.

  FIG. 8 is a diagram illustrating information included in a packet. The packet 551 stored together with the time information 61 includes an Ethernet header (Ethernet header) (Ethernet: registered trademark) 551a, an IP header 551b, a TCP header 551c, and TCP data 551d.

  FIG. 9 is a diagram showing details of the IP header. The IP header 551b includes version information (version), header length, service type (Type of Service), data length, identifier (ID), flag (Flag), fragment offset (Fragment Offset), lifetime (Time Of Live), The protocol (Protocol), header checksum (Header Checksum), transmission side IP address, reception side IP address, option (Option), and padding (Padding).

  FIG. 10 is a diagram showing details of the TCP header. The TCP header 551c includes a transmission side port, a reception side port, a transmission sequence number (Sequence Number), a response acknowledgment number (Acknowledge Number), a header length, a reserved (Reserved), a flag, a window (Window), and a checksum (Checksum). , An urgent pointer (Urgent Pointer), and an option (Option). The flag is further composed of URG (Urgent Flag), ACK (Acknowledgement Flag), PSH (Push Flag), RST (Reset Flag), SYN (Synchronize Flag), and FIN (Fin Flag).

The packet acquired by the message observation unit 120 is analyzed by the message analysis unit 130.
FIG. 11 is a block diagram illustrating functions of the message analysis unit. The message analysis unit 130 includes a TCP / UDP (User Datagram Protocol) session reconfiguration unit 131, a message reconfiguration unit 132, an object name assignment unit 133, and a log output unit 134.

  The TCP / UDP session reconfiguration unit 131 distributes the packets 551 to 558 to the sessions 71 to 73 to which the packets 551 to 558 belong. The message reconstructing unit 132 extracts predetermined data from the packets 551 to 558 distributed to the sessions 71 to 73, and reconstructs the message pairs 81 to 83. The object name assigning unit 133 determines object names corresponding to the message pairs 81 to 83. The log output unit 134 outputs the processing result to the protocol log storage unit 112.

  When the packets 551 to 558 are input from the message observation unit 120 to the message analysis unit 130, the processing is performed in the order of the TCP / UDP session reconfiguration unit 131, the message reconfiguration unit 132, the object name allocation unit 133, and the log output unit 134. Is executed. Note that the packets 551 to 558 delivered from the message observation unit 120 may be a packet stored in advance in the packet data storage unit 111 or a packet observed by the message observation unit 120 may be transferred.

Hereinafter, processing executed by each element in the message analysis unit 130 will be described in detail.
The packets 551 to 558 passed to the message analysis unit 130 are first input to the TCP / UDP session reconfiguration unit 131. The TCP / UDP session reconfiguration unit 131 distributes the input packets 551 to 558 by session.

  Specifically, the TCP / UDP session reconfiguration unit 131 first acquires the transmission / reception side IP address (see FIG. 9) from the IP header 551b of the packet 551. Next, the TCP / UDP session reconfiguration unit 131 acquires the transmission side port number and the reception side port number from the TCP header 551c (see FIG. 10). Then, the TCP / UDP session reconfiguration unit 131 uses the acquired set of four values as a session identifier. At this time, a unique number can be assigned to the identifier.

  The TCP / UDP session reconfiguration unit 131 generates identifiers for the packets 551 to 558, and sorts packets having the same identifier as packets sent in the same session.

  Next, in the case of TCP, the TCP / UDP session reconfiguration unit 131 reads a flag included in the TCP header 551c and acquires a session state such as start / establish / disconnect (see FIG. 10). For example, the start of a session is recognized by detecting a packet of SYN “1”, the establishment of the session is recognized by a response of ACK “1” to the packet, and data transmission and a response of ACK “1” to the data transmission in the session establishment state Is repeatedly performed, and finally the disconnection of the session is recognized by detecting the FIN “1” packet.

  Also, the TCP / UDP session reconfiguration unit 131 acquires the data length and header length included in the IP header 551b / TCP header 551c, and subtracts each header length from the data length to obtain the length of the data portion (data size ) To get.

  Furthermore, by giving the IP address of each server to the TCP / UDP session reconfiguration unit 131 in advance, the transmission direction of each packet can be determined from the set of IP addresses.

  Also, the TCP / UDP session reconfiguration unit 131 reads, for example, the transmission side port number if the server address is in the transmission address and the reception side port number if the server address is in the destination address, from the IP header of the packet. Then, the TCP / UDP session reconfiguration unit 131 can check which service the session is for by using the port number as an identifier. For example, when the port on the server side is No. 80, it is determined that the communication is with the Web server (HTTP).

  FIG. 12 is an example of a reconfigured session. The TCP / UDP session reconfiguration unit 131 reconfigures TCP sessions 71 to 73 from the packets 551 to 558. In FIG. 12, the vertical axis represents the time axis (time progresses from top to bottom in the figure).

  The number on each axis represents the IP address of each device. Packets are distributed according to a set of IP addresses. In FIG. 12, the flag or data size acquired from each packet is displayed in a time-series sequence.

In this way, the packet distributed for each of the sessions 71 to 73 is transferred to the message reconstructing unit 132.
The message reconstruction unit 132 reconstructs a message from the data portion of the packet distributed for each of the sessions 71 to 73. In the message reconstruction unit 132, first, a data portion is extracted from a collection of packets transmitted and received in the same session 71 to 73 and arranged. Then, the message reconstructing unit 132 divides the message by acquiring the size of the message in the aligned data portion according to the protocol format. At this time, if the message is divided and transmitted in a plurality, a plurality of data portions may be connected to cut out one message. Alternatively, when a plurality of concatenated messages are transmitted, a plurality of messages may be cut out from a single data part. Each message may be assigned a unique number on the session.

FIG. 13 is a first diagram illustrating an example of message reconstruction. FIG. 13 shows that the transmission side IP address is 10.25.21 4 . 10 is an example of analyzing a message on the session 71 having an identifier with a receiving side IP address of 10.25.214.105, a transmitting side port number of 3449, and a receiving side port number of 80.

  Since the receiving port number of the session to which the packet 554 belongs is 80, the message reconstruction unit 132 determines that the data part of the packet 554 is a request from the client 21 to the Web server 31 using HTTP, and the HTTP message Carve as

  In the case of HTTP, the message reconstruction unit 132 searches for a specific combination of octets (0x0D0A0D0A = \ r \ n \ r \ n) from the data, and sets the header part (HTTP header) up to that position. Next, when the data part (HTTP data) exists, the length of the data part is acquired from the Content-Length field included in the header part, the message is cut out, and the first packet 554 constituting the message is received. The time “00.00.00: 100” is set as the reception time of the message. Then, the message reconstruction unit 132 acquires the message type, the requested URL, and response result data.

  For example, information acquired from an HTTP message includes a header length, a data length, a message type, a URL, and individual parameters. For example, information acquired from an IIOP message includes a header length, a data length, a message type, a method name, and individual parameters. Further, for example, information acquired from a DB message includes a header length, a data length, a message type, a SQL (Structured Query Language) statement, a SQL statement parameter, and the like.

  In the example of FIG. 13, the header of the HTTP request message starts with POST, and immediately after is / corba / servlet / Balance, the message type is POST, and the URL representing the object is / corba / servlet / Balance. I understand. Further, since the value of the Content-Length field is 29, it can be seen that the length of the data part is 29 bytes. Therefore, the message reconstruction unit 132 cuts out 29 bytes from the end of the header as a message.

  Further, the message reconstructing unit 132 associates the request message with respect to the execution subject with the response message as a response, and calculates the time taken for the response. For example, in the case of HTTP, a request message is associated with a response message that appears immediately after the same session. Further, the response time of the message pair is obtained by subtracting the reception time of the request message from the reception time of the response message. At this time, a unique number may be assigned to the associated message pair.

  FIG. 14 is a diagram illustrating an example of associating a response message with a request. The example of FIG. 14 shows a case where an HTTP response message is associated with an HTTP request message.

The message acquired from the packet 554 in FIG. 13 and the message acquired from the packet 556 in FIG. 14 include a transmission side IP address 10.25.214.105, a reception side IP address 10.25.21 4 . 10. Since the message is exchanged on the session of the transmission side port number 80 and the reception side port number 3449, the message acquired from the packet 556 in FIG. 14 is the same as the message acquired from the packet 554 in FIG. It is determined that the messages are continuously transmitted. Since the transmission directions of the two messages are opposite, a message pair is generated by associating these two messages. The message reconstruction unit 132 calculates the response time of the message pair and assigns a common identification number 1 to these two messages.

  In this way, the message pair is passed to the object name assignment unit 133. Then, the object name assigning unit 133 determines an object name corresponding to the message pair.

  Note that the object name may be changed according to the content to be analyzed by the subsequent apparatus. Further, the same object name may be assigned to different messages, or a plurality of object names may be assigned to a single message. Alternatively, all pieces of information that can be acquired may be assigned as temporary object names, and the object names may be determined again in subsequent devices.

For example, a URL is assigned as an object name to an HTTP message pair. This is because information for associating a process to be executed with a message is included in the URL.
Also, for example, a method name is assigned as an object name to an IIOP message pair. This is because the IIOP method name represents a single process on the server.

  Further, for example, a pair of a SQL operator type such as Select, Insert, Update, and Fetch and a database table name is assigned to a DB message pair as an object name. This is for distinguishing the amount and time of different processing depending on the presence / absence of writing by database operation and the size of the database table to be operated.

  FIG. 15 is a diagram illustrating object name assignment and message analysis results. In this example, an object name 81c is assigned to the message pair 81 associated in FIG. 14 of HTTP. The object name 81c is a URL specified by the request message. The message 81a is an HTTP request message reconstructed from the packet 554 in FIG. 13, the message 81b is an HTTP response message reconstructed from the packet 556 in FIG. 14, and the message pair 81 associates these messages. .

  FIG. 16 is a diagram illustrating assignment of object names and message analysis results of each message constituting one transaction. In this example, similar to HTTP protocol messages, messages are reconfigured for other protocols such as IIOP and DB, and object names are assigned.

  Therefore, the HTTP messages 81a and 81b (identification number 1 on the HTTP session) and the request message 82a (object name: object name: having the identification number 1 on the IIOP session) associated with each other in FIGS. Mbalance) and a response message 82b corresponding to the request having the identification number 1 on the DB session (object name: Fetch Account) are reconfigured. These messages are displayed as a sequence diagram together with the extracted object names.

  The object name of the message 81a is / corba / servlet / Balance. The object name of the message 82a is Mbalance. The object name of the message 83a is Fetch Account.

  Such message pairs 81 to 83 to which object names are assigned are input to the log output unit 134 (see FIG. 11). Then, the log output unit 134 outputs information obtained by the TCP / UDP session reconfiguration unit 131, the message reconfiguration unit 132, and the object name allocation unit 133 as a protocol log. At this time, the output protocol log may be in a text format or a binary format.

FIG. 17 is a diagram illustrating an example of a protocol log. In this example, protocol logs 112a to 112f output in a text format are shown.
The protocol logs 112a to 112f include, for each message, time (message reception time), identification number, protocol (protocol name), direction (request or response), and object / response time (object name for request, Response time is set for the response.

  For example, in the case of an HTTP session, the reception time “00.00.00.100”, the identification number “1”, and the object name “/ corba / servlet / Balance” are set in the protocol log 112a indicating the request message. ing. In the protocol log 112f indicating the response message, the reception time “00.00.00.290”, the identification number “1”, and the response time “0.190 (second)” are set.

  Each time such a service is provided to the clients 21, 22, and 23, protocol logs 112 a to 112 f as shown in FIG. 17 are sequentially accumulated in the protocol log storage unit 112 by the message analysis unit 130. . As a result, the protocol log storage unit 112 stores a plurality of protocol logs related to a plurality of transactions.

  FIG. 18 is a diagram illustrating an example of a protocol log stored in the protocol log storage unit. The protocol log storage unit 112 stores protocol logs of messages related to different transactions in time series. FIG. 18 shows a protocol log based on messages generated during processing of a “balance check” transaction and a “deposit” transaction in the Internet banking service.

  The protocol log stored in the protocol log storage unit 112 is input to the model generation unit 140 when a model generation instruction is input. Then, the model generation unit 140 generates a transaction model.

  The model generation unit 140 acquires a transaction model based on the protocol log stored in the protocol log storage unit 112. Note that the protocol log as shown in FIG. 18 is a complex mixture of HTTP protocol, IIOP protocol, and DB protocol messages. Note that each protocol request and the corresponding response message have the same identification number generated by the message reconstruction unit 132.

  Therefore, in the first embodiment, the model generation unit 140 employs the following criteria as selection criteria based on the likelihood of the call relationship between processes. That is, a model is obtained by extracting only a portion (that is, a portion of non-multiplex (multiplicity 1)) where each transaction does not overlap with other transactions (from a client request to a response). In the case of a non-multiplex transaction, there is a call relationship between the processes in the time zone in which the transaction is being executed (the probability is high).

  Accordingly, the model generation unit 140 first detects a request / response pair group of the HTTP protocol having the same identification number. Next, the model generation unit 140 checks whether there is an HTTP message having another identification number between the HTTP protocol message pairs. If not, the model generation unit 140 selects a request / response pair of the HTTP protocol and all requests in between. That is, transactions that are not in a cross relationship are extracted.

Specifically, the following processing is performed.
FIG. 19 is a flowchart showing the transaction model generation process. In the following, the process illustrated in FIG. 19 will be described in order of step number.

[Step S21] The model generation unit 140 initializes parameters. Specifically, multiplicity = 0 and duplication flag = 0.
[Step S22] The model generation unit 140 reads a message from the protocol log storage unit 112.

  [Step S23] The model generation unit 140 determines whether there is a message. If there is a message, the process proceeds to step S24. If there is no message, the process ends.

  [Step S24] The model generation unit 140 determines whether the protocol of the read message is HTTP. If it is HTTP, the process proceeds to step S25. If not HTTP, the process proceeds to step S22.

  [Step S25] The model generation unit 140 determines the message direction (request or response). If it is a request message, the process proceeds to step S26. If it is a response message, the process proceeds to step S30.

  [Step S26] The model generation unit 140 determines whether multiplicity = 0. If the multiplicity is 0, the process proceeds to step S27. If the multiplicity is not 0, the process proceeds to step S29.

[Step S27] The model generation unit 140 increments (adds 1) the multiplicity.
[Step S28] The model generation unit 140 stores the start position. Specifically, information for specifying the position of the processed message (for example, a pointer indicating the corresponding protocol log) is stored. Thereafter, the process proceeds to step S22.

[Step S29] The model generation unit 140 increments the multiplicity (adds 1) and sets the value of the duplication flag to 1. Thereafter, the process proceeds to step S22.
[Step S30] If it is determined in step S25 that the message is a response message, the model generation unit 140 determines whether multiplicity = 1. If the multiplicity is 1, the process proceeds to step S31. If the multiplicity is other than 1, the process proceeds to step S22.

  [Step S31] The model generation unit 140 determines whether the duplication flag = 0. If the duplication flag is 0, the process proceeds to step S32. If the duplication flag is 1, the process proceeds to step S33.

[Step S32] The model generation unit 140 selects a message from the start position to the current position as a model generation message. Thereafter, the process proceeds to step S34.
[Step S33] The model generation unit 140 sets the value of the duplication flag to 0.

[Step S34] The model generation unit 140 decrements (subtracts 1) the multiplicity. Thereafter, the process proceeds to step S22.
In this way, a message constituting a transaction that does not overlap with other transactions can be identified and selected as a model generation message.

  FIG. 20 is a diagram showing a model generation message to be selected. FIG. 20 shows a set of messages extracted from the protocol log as shown in FIG. 18 for model generation.

  For example, when an HTTP request / response pair is searched from the protocol log of FIG. 20, an HTTP request / response pair 91 with identification number = 1, an HTTP request / response pair 92 with identification number = 2, and an identification number = First, an HTTP request / response pair 93 of 3 and an HTTP request / response pair 94 of identification number = 4 are detected. However, an HTTP request message with an identification number = 3 exists between the HTTP protocol request / response pair 92 with the identification number = 2. Therefore, only the pair of identification number = 1 and identification number = 4 is finally extracted from the four HTTP request / response pairs 91-94. That is, a message between HTTP request / response pairs 91 and 94 with identification number = 1 and identification number = 4 is used for model generation.

  FIG. 21 is a diagram illustrating a model generation example of the “balance confirmation” transaction. FIG. 21 shows a “balance confirmation” transaction model 203 generated from the message set 201 between the HTTP request / response pair 91 of identification number = 1 in FIG.

  The model generation unit 140 uses a restriction that upper processing (on the user side) calls lower processing, but not the other way around. This restriction is a general restriction in a system having a hierarchical configuration. Specifically, the processing of the Web server 31 is called from the client 21, the processing of the application server 32 is called from the Web server 31, and the processing of the DB server 33 is called from there.

  The model generation unit 140 analyzes the message set 201 in accordance with specified restrictions, and creates a processing sequence 202. Specifically, the model generation unit 140 analyzes the contents of each message in the message set 201 along a time series. The contents of each message in the message set 201 are as follows.

  First, an HTTP protocol request message with identification number = 1 indicates a processing request from the client 21 to the Web server 31. In this case, the object processing of / corba / servlet / Balance is charged. Next, the IIOP protocol request message with the identification number = 1 requests processing of the Mbalance method from the Web server 31 to the application server 32. Further, the DB protocol request message with the identification number = 1 requests an operation process called Fetch Account from the application server 32 to the DB server 33. Thereafter, DB, IIOP, and HTTP protocol response messages are transmitted from the DB server 33, the application server 32, and the Web server 31, respectively. A processing sequence 202 corresponding to this content is generated.

  The processing sequence 202 includes a response time in each session. The session time is indicated in the response message. In the example of FIG. 21, the response times from the request to the response of the DB server 33, the application server 32, and the Web server 31 are 10 msec, 90 msec, and 190 msec, respectively.

  In the “balance check” processing sequence 202, the / corba / servlet / Balance object is processed by the Web server 31, the Mbalance object is processed by the application server 32, and the Fetch Account object is processed by the DB server 33. . Therefore, the model generation unit 140 calculates the processing time of the object in each server.

  The processing time of the DB server 33 is 10 msec of the DB response time from the DB request to the response. The processing time of the application server 32 is 80 msec (= 90-10) obtained by subtracting the response time of the DB server 33 from 90 msec of the response time of the response from the IIOP request. The processing time of the Web server 31 is 100 msec (= 190−90) obtained by subtracting the response time of the application server from the response time 190 msec of the response from the HTTP request.

Then, the model generation unit 140 generates a transaction model 203 that defines the object processing call relationship and the processing time of each object.
FIG. 22 is a diagram illustrating a model generation example of the “deposit” transaction. FIG. 22 shows a “deposit” transaction model 213 generated from the message set 211 between the HTTP request / response pair 94 of identification number = 4 in FIG.

  Similar to the processing in FIG. 21, the model generation unit 140 analyzes the message set 211 according to a predetermined constraint, and creates a processing sequence 212. The contents of each message in the message set 211 are as follows.

  First, an HTTP protocol request message with identification number = 4 requests processing from the client 21 to the Web server 31. In this case, the URL is / corba / servlet / Deposit. Next, the IIOP protocol request message with identification number = 4 requests processing of the Mdeposit method from the Web server 31 to the application server 32. Next, the DB protocol request message with the identification number = 5 requests an operation process called Fetch Account from the application server 32 to the DB server 33. As can be seen from the response message of the DB response with identification number = 5 corresponding to this DB request, the Fetch Account processing took 10 msec by the DB server 33.

  Thereafter, an operation process called Update Account from the application server 32 to the DB server 33 is further requested as a DB protocol request message of identification number = 6. Thereafter, a DB protocol response with identification number = 6, an IIOP protocol response with identification number = 4, and an HTTP protocol response message with identification number = 4 are transmitted from the DB server 33, application server 32, and web server 31.

  A transaction model 213 is generated from such a message flow and stored in the model storage unit 113. It can also be seen from the response message that the response times from the request to the response were 20 msec, 120 msec, and 240 msec. This response time is also set in the transaction model 213.

  In the “deposit” transaction model 213, the / corba / servlet / Deposit object is processed by the Web server 31, the Mdeposit object is processed by the application server 32, and the Fetch Account and Update Account objects are processed by the DB server 33. . Accordingly, the model generation unit 140 calculates object processing time information in each server. The respective processing times are 10 msec and 20 msec for the DB server 33, 90 msec (= 120− (10 + 20)) for the application server 32, and 120 msec (= 240−120) for the Web server 31.

Then, the model generation unit 140 generates a transaction model 213 that defines the object processing call relationship and the object processing time in each server.
Note that there may be a case where a message at the time of “balance confirmation” or “payment” transaction processing is input again from the message analysis unit 130 to the model generation unit 140, and these are multiplicity 1. In this case, those messages may be ignored. Similarly, a model can be generated and reflected in the processing time of each server for the same type of transaction that has already been generated (for example, using an average time).

  In addition, by using the matching method between the existing transaction model executed by the analysis unit 150 and the message, a message set of transactions having a multiplicity of 1 or more is extracted based on the multiplicity of 1 model. A model can also be generated by obtaining the application processing time.

  Next, processing executed by the analysis unit 150 will be described in detail. The analysis unit 150 compares the protocol log stored in the protocol log storage unit 112 with the transaction model stored in the model storage unit 113 to identify the messages constituting each transaction. Then, the analysis unit 150 analyzes the state of the system based on the message processing time for each transaction. Specifically, the following processing is performed.

FIG. 23 is a flowchart showing the procedure of the analysis process. In the following, the process illustrated in FIG. 23 will be described in order of step number.
[Step S51] The analysis unit 150 reads an unprocessed protocol log from the protocol log storage unit 112.

  [Step S52] The analysis unit 150 determines whether there is an unprocessed protocol log. If there is an unprocessed protocol log, the process proceeds to step S53. If there is no unprocessed protocol log, the process ends.

  [Step S53] The analysis unit 150 determines the protocol of the message indicated in the read protocol log. If the protocol is HTTP, the process proceeds to step S54. If the protocol is IIOP, the process proceeds to step S59. If the protocol is DB, the process proceeds to step S62.

  [Step S54] When the protocol is HTTP, the analysis unit 150 determines the message direction (request or response). In the case of a request message, the process proceeds to step S55. In the case of a response message, the process proceeds to step S57.

  [Step S <b> 55] In the case of a request message, the analysis unit 150 detects a transaction model corresponding to the object (URL) of the message from the model storage unit 113. Then, the contents of the corresponding transaction generated by the HTTP request are recognized.

[Step S56] The analysis unit 150 registers a new transaction and an HTTP identification number in the processing table. Thereafter, the process proceeds to step S51.
[Step S57] In the case of a response message, the analysis unit 150 searches for the corresponding transaction and HTTP from the processing table using the identification number, and calculates the processing time in the Web server 31. The calculated processing time is registered in association with the corresponding transaction in the processing table.

[Step S58] The analysis unit 150 outputs the end transaction information to the output unit 160 and deletes it from the processing table. Thereafter, the process proceeds to step S51.
[Step S59] When the protocol is IIOP, the analysis unit 150 determines the direction of the message (request or response). In the case of a request message, the process proceeds to step S60. In the case of a response message, the process proceeds to step S61.

  [Step S60] In the case of a request message, the analysis unit 150 uses the message object (method) to retrieve the corresponding transaction from the in-treatment table, and registers the IIOP identification number. Thereafter, the process proceeds to step S51.

  [Step S61] In the case of a response message, the analysis unit 150 searches the corresponding transaction from the processing table using the identification number, and calculates the processing time in the application server 32. The calculated processing time is registered in association with the corresponding transaction in the processing table. Thereafter, the process proceeds to step S51.

  [Step S62] If the protocol is DB, the analysis unit 150 determines the message direction (request or response). In the case of a request message, the process proceeds to step S63. In the case of a response message, the process proceeds to step S64.

  [Step S63] In the case of a request message, the analysis unit 150 uses the message object (command + table name) to search for the corresponding transaction from the in-treatment table, and registers the DB identification number. Thereafter, the process proceeds to step S51.

  [Step S64] In the case of a response message, the analysis unit 150 searches the corresponding transaction from the processing table using the identification number, and calculates the processing time in the DB server 33. The calculated processing time is registered in association with the corresponding transaction in the processing table. Thereafter, the process proceeds to step S51.

By performing such processing, the processing time in each server can be recorded for each type of transaction.
FIG. 24 is a diagram illustrating an example of a message input to the analysis unit. After an analysis instruction is issued by a user operation input or the like, the protocol logs 221 to 242 output from the message analysis apparatus and stored in the protocol log storage unit 112 are sequentially input to the analysis unit 150.

  The analysis unit 150 matches these protocol logs 221 to 242 with the “balance confirmation” and “payment” transaction models (shown in FIGS. 21 and 22) obtained by the model generation unit 140. Then, the analysis unit 150 extracts a transaction that matches the transaction model. Hereinafter, an analysis example of the protocol logs 221 to 242 illustrated in FIG. 24 will be described with reference to FIGS. 25 to 34 show transaction state transitions that can be confirmed by analyzing the protocol logs 221 to 242 in order from the top. In FIG. 25 to FIG. 34, among the transactions whose occurrence has been confirmed, objects whose processing has been started are indicated by solid ellipses, and objects whose processing has not been started are indicated by dashed ellipses.

  FIG. 25 is a first diagram illustrating an example of message analysis. First, the message indicated by the first protocol log 221 is an HTTP protocol with an identification number = 100, and is a request message for / corba / servlet / Balance object processing from the client 21 to the Web server 31. As shown in the first state (ST1), this message matches the call to the Web server 31 processing of the transaction model 203 (“balance confirmation” transaction) shown in FIG. This means the start of processing in the Web server 31.

  The message shown in the next protocol log 222 is a request message for processing the Mbalance object to the application server 32 in the IIOP protocol with the identification number = 200. As shown in the second state (ST2), this message coincides with a call to the application server 32 process of the transaction model 203 of “balance confirmation”. This means the start of processing in the application server 32.

  The HTTP request message with the identification number = 101 shown in the next protocol log 223 is a request for processing of the / corba / servlet / Deposit object to the Web server 31. As shown in the third state (ST3), this message matches the call to the Web server 31 process of the “deposit” transaction model 213 shown in FIG. This means the start of processing in the Web server 31.

  The DB protocol request message with identification number = 500 shown in the next protocol log 224 is a processing request for a command called Fetch Account from the application server 32 to the DB server 33. This message matches the call to the DB server 33 process of the “balance check” transaction model 203 as shown in the fourth state (ST4). This means the start of processing in the DB server 33.

  FIG. 26 is a second diagram illustrating an example of message analysis. The IIOP request message with identification number = 201 indicated in the next protocol log 225 is an Mdeposit processing request to the application server 32. This message matches the call to the application server 32 process of the “deposit” transaction model 213, as shown in the fifth state (ST5). This means the start of processing in the application server 32.

  The HTTP request message with identification number = 102 shown in the next protocol log 226 is a request for processing of the / corba / servlet / Deposit object to the Web server 31. As shown in the sixth state (ST6), this message matches the call to the Web server 31 process of the “deposit” transaction model 213. This means the start of processing in the new Web server 31.

  FIG. 27 is a third diagram illustrating an example of message analysis. The DB protocol response message of identification number = 500 shown in the next protocol log 227 is a response message from the DB server 33 to the application server 32. As shown in the seventh state (ST7), this message means that it takes 20 msec to process the “balance check” transaction in the DB server 33. In the “balance check” transaction model 203 of FIG. 21, the processing time of the Fetch Account command in the DB server 33 is 10 msec. Therefore, the difference from the model is 10 msec.

  The DB protocol request message with the identification number = 501 indicated in the next protocol log 228 is a processing request for a command called Fetch Account from the application server 32 to the DB server 33. As shown in the eighth state (ST8), this message matches the call to the process of the DB server 33 of the “deposit” transaction model 213. This means the start of processing in the DB server 33.

  FIG. 28 is a fourth diagram illustrating an example of message analysis. The DB protocol response message of identification number = 501 shown in the next protocol log 229 is a response message from the DB server 33 to the application server 32. As shown in the ninth state (ST9), this message means that it takes 20 msec to process the “deposit” transaction in the DB server 33. Since the processing time of the Fetch Account command of the DB server 33 in the “deposit” transaction model 213 in FIG. 22 is 10 msec, the difference from the model is 10 msec.

  The DB protocol request message of identification number = 502 shown in the next protocol log 230 is a processing request for a command called Update Account from the application server 32 to the DB server 33. As shown in the tenth state, this message matches the call to the processing of the DB server 33 of the “deposit” transaction model 213. This means the start of processing in the DB server 33.

  FIG. 29 is a fifth diagram illustrating an example of message analysis. The IIOP request message with identification number = 202 shown in the next protocol log 231 is an Mdeposit processing request to the application server 32. This message matches the call to the application server 32 process of the “deposit” transaction model 213 as shown in the eleventh state (ST11). This means the start of processing in the application server 32.

  The IIOP protocol response with identification number = 200 shown in the next protocol log 232 is a response message from the application server 32 to the Web server 31. As shown in the twelfth state (ST12), this message means the end of processing in the application server 32 of the “balance check” transaction. As shown in the response message, the response time from the IIOP request to the response is 100 msec. However, when the actual processing time in the application server 32 is considered, it is 80 msec excluding the processing (20 msec) in the DB server 33 during that time. Become. This value is the same as the processing time of the application server 32 in the “balance check” transaction model 203 of FIG.

  FIG. 30 is a sixth diagram illustrating an example of message analysis. The DB protocol response message of identification number = 502 shown in the next protocol log 233 is a response message from the DB server 33 to the application server 32. As shown in the thirteenth state (ST13), this message means that the processing of the “deposit” transaction in the DB server 33 has been completed in 50 msec. In the “deposit” transaction model 213 in FIG. 22, the processing time of the Update Account command in the DB server 33 is 20 msec, so the difference from the model is 30 msec.

  The DB protocol request message with identification number = 503 shown in the next protocol log 234 is a processing request for a command called Fetch Account from the application server 32 to the DB server 33. As shown in the 14th state (ST14), this message matches the call to the process in the DB server 33 of the “deposit” transaction model 213. This means the start of processing in the DB server 33.

  FIG. 31 is a seventh diagram illustrating an example of message analysis. The HTTP protocol response message of identification number = 100 shown in the next protocol log 235 is a response message from the Web server 31 to the client. As shown in the fifteenth state (ST15), this message means the end of the processing in the Web server 31 of the “balance check” transaction. As shown in the response message, the response time from the request to the response is 190 msec, but when considering the actual processing time in the Web server 31, it is 90 msec excluding the response processing (100 msec) of the application server 32 during that time. . In the “balance check” transaction model 203 in FIG. 21, the processing time in the Web server 31 is 100 msec, and therefore, the process ends 10 msec earlier than the model. At this point, all the processes of one “balance check” transaction are completed and output to the output unit 160.

  The DB protocol response message of identification number = 503 shown in the next protocol log 236 is a response message from the DB server 33 to the application server 32. This message means that the processing in the DB server 33 of the “deposit” transaction has been completed in 20 msec as shown in the 16th state (ST16). In the “deposit” transaction model 213 in FIG. 22, the processing time of the Fetch Account command in the DB server 33 is 10 msec, so the difference from the model is 10 msec.

  FIG. 32 is an eighth diagram illustrating an example of message analysis. The DB protocol request message with identification number = 504 shown in the next protocol log 237 is a processing request for a command called Update Account from the application server 32 to the DB server 33. This message matches the call to the DB server 33 process of the “deposit” transaction model 213 as shown in the seventeenth state (ST17). This means the start of processing in the DB server 33.

  The response of the IIOP protocol with identification number = 201 shown in the next protocol log 238 is a response message from the application server 32 to the Web server 31. As shown in the 18th state (ST18), this message means the end of processing in the application server 32 of the “deposit” transaction. As shown in the response message, the response time from the request to the response is 180 msec. However, when the actual processing time in the application server 32 is considered, the processing time (70 msec = 20 msec + 50 msec) of the two commands in the DB server 33 during that time. 110 msec excluding). In the “deposit” transaction model 213 in FIG. 22, the processing time in the application server 32 is 90 msec, and therefore the difference from the model is 20 msec.

  FIG. 33 is a ninth diagram illustrating an example of message analysis. The HTTP protocol response message of identification number = 101 shown in the next protocol log 239 is a response message from the Web server 31 to the client. As shown in the 19th state (ST19), this message means the end of processing in the Web server 31 of the “deposit” transaction. As shown in the response message, the response time from the request to the response is 310 msec. However, when the actual processing time in the Web server 31 is considered, it is 130 msec excluding the response time (180 msec) of the application server 32 during that time. . In the “deposit” transaction model 213 in FIG. 22, the processing time in the Web server 31 is 120 msec, so the difference from the model is 10 msec. At this point, all processing of one “deposit” transaction is completed and output to the output unit 160.

  The DB protocol response message of identification number = 504 shown in the next protocol log 240 is a response message from the DB server 33 to the application server 32. This message means that the DB server 33 process of the “deposit” transaction is completed in 230 msec, as shown in the twentieth state (ST20). In the “deposit” transaction model 213 in FIG. 22, the processing time of the Update Account command in the DB server 33 is 20 msec. Therefore, the difference from the model is 210 msec, and the DB server 33 is greatly increased. And you can see that something is wrong.

  FIG. 34 is a tenth diagram illustrating an example of message analysis. The response of the IIOP protocol with identification number = 202 shown in the next protocol log 241 is a response message from the application server 32 to the Web server 31. As shown in the 21st state (ST21), this message means the end of processing in the application server 32 of the “deposit” transaction. As shown in the response message, the response time from the request to the response is 350 msec. However, when the actual processing time in the application server 32 is considered, the processing time of the two commands in the DB server 33 in the meantime (250 msec = 20 msec + 230 msec) ) Is 100 msec. In the “deposit” transaction model 213 of FIG. 22, the processing time in the application server 32 is 90 msec. Therefore, the difference from the model is 10 msec.

  Note that although the response time at the application server 32 is 350 msec, the actual processing time at the application server 32 is only 100 msec, which is almost the same as the model. It can be seen that the server 32 itself has no performance problem.

  The HTTP protocol response message with identification number = 102 shown in the next protocol log 242 is a response message from the Web server 31 to the client. As shown in the 22nd state (ST22), this message means the end of processing of the “deposit” transaction in the Web server 31. As shown in the response message, the response time from the request to the response is 470 msec. However, when the actual processing time in the Web server 31 is considered, the response time of the application server 32 (350 msec) during that time is 120 msec. . At this point, all processing of the final “deposit” transaction is completed and output to the output unit 160.

  In the “deposit” transaction model 213 in FIG. 22, the processing time in the Web server 31 is 120 msec, which matches the model. Similar to the application server 32, although the response time at the Web server 31 is 470 msec, the actual processing time at the Web server 31 matches the model. You can see that there is no. The analysis results as described above are stored in the analysis result storage unit 114.

Next, processing performed by the output unit 160 will be described in detail.
The output unit 160 outputs the transaction information stored in the analysis result storage unit 114 from the analysis unit 150 to the monitor 11 in various forms. Hereinafter, an output example of transaction information by the output unit 160 will be shown.

  FIG. 35 is a diagram illustrating a display example of the average processing time of the server. As illustrated in FIG. 35, the output unit 160 obtains an average processing time for each server and displays a screen 301 indicating the average processing time on the monitor 11. A line indicating the processing time in the transaction model is displayed on the graph indicating the processing time of each server. In addition, when the difference with the processing time with a model is very large, the output part 160 can also list those processes and can display them on the monitor 11.

  FIG. 36 is a diagram showing a display example of transaction processing time and breakdown. On this screen 302, all transactions for a certain period are totaled and the processing time for each server is displayed.

  FIG. 37 is a diagram illustrating a display example of a processing time histogram. In this screen 303, a transaction processing time and a histogram (occurrence frequency for each processing time) regarding the processing time in each server are displayed.

Further, by displaying various information such as a histogram on the screen at the same time, it is possible to easily analyze the cause of the processing delay.
FIG. 38 is a diagram illustrating a screen example when a plurality of pieces of information are displayed simultaneously. This screen 310 includes a transaction processing time histogram display section 311, a transaction multiplicity display section 312, a transaction time transition display section 313 (a breakdown by the Web server 31, application server 32, and DB server 33) and transaction message information. A sequence display unit 314 is displayed. The output unit 160 displays the display contents of each display target element in cooperation with each other.

  FIG. 39 is a diagram illustrating a state of cooperation between display target elements. As shown in FIG. 39, the histogram display unit 311 displays a bar 311a indicating a threshold for determining processing delay. The bar 311a can be moved left and right in accordance with an operation input from the user. The processing time value at the position where the bar 311a is displayed serves as a threshold value. Transactions that require processing time beyond the threshold are determined as attention processes.

In the example of FIG. 39, a bar 311a is displayed at a position of 300 msec. Therefore, a transaction that requires 300 msec or more is the attention process.
In the multiplicity display unit 312, the processing time zone of the transaction classified as the target process on the histogram display unit 311 is highlighted. In addition, a scroll bar 312 a is provided beside the multiplicity display unit 312. Details of the transaction in the time zone indicated by the scroll bar 312a are displayed on the time transition display unit 313.

  In the time transition display section 313, message passing between protocols is shown in a sequence between servers. A scroll bar 313 a is provided beside the time transition display unit 313. The content of the message in the time period indicated by the scroll bar 313a is displayed on the sequence display unit 314. In the sequence display unit 314, a message related to the attention process is highlighted.

  As described above, if the user selects a transaction that takes a predetermined time or more from the histogram display unit 311, the multiplicity display unit 312 of the transaction, the time transition display unit 313 of the transaction, and the message This can be confirmed on the sequence display unit 314.

  As described above, in the first embodiment, a transaction model is generated, and a message passing along the transaction model is detected from messages transmitted and received via the switch 10. As a result, it is possible to identify a set of messages constituting an arbitrary transaction and analyze the transaction.

  That is, the system analysis apparatus 100 reconfigures communication between applications executed on the server by analyzing the data portion of the TCP packet captured from the network. Then, the system analysis apparatus 100 can select from the reconfigured protocol log a message set in which a call relationship between processes exists reliably, and can extract a transaction that is a series of processes associated with a user request. By tracking the processing of each application from the user request to the response, it becomes possible to quickly grasp performance problems and bottlenecks.

  Moreover, in the first embodiment, transactions are extracted by external observation. Therefore, it is not necessary to add a function to the existing system, and it is not necessary to modify the application in the server.

[Second Embodiment]
In the second embodiment, even if a transaction has a processing time zone that overlaps with other transactions, messages constituting the transaction are extracted and a transaction model can be generated.

  That is, in the first embodiment, a transaction model is acquired by extracting only a part where each process does not overlap with another process (from request to response) (that is, multiplicity is 1). This process is effective, for example, when the operation of the target system is temporarily stopped and can be operated only for model acquisition.

  However, in the case of a system in which the operation cannot be stopped because the service is performed for 24 hours and a plurality of processes are processed in parallel in most cases, it is difficult to apply the first embodiment. Become. Also, if the behavior differs between a low multiplicity of processing and a light load on the system, and a high multiplicity and heavy load, it is not sufficient to generate a transaction model only from multiplicity 1 It is. Therefore, depending on the target system, it is also necessary to generate a transaction model using a portion with a high degree of multiplicity. An example of the operation is shown below.

  The functional blocks of the system analysis apparatus in the second embodiment are the same as those in the first embodiment shown in FIG. Therefore, the processing of the second embodiment will be described using each element shown in FIG. Further, the first embodiment and the second embodiment are different only in the processing of the model generation unit 140, and the processing of other elements is the same. Furthermore, for the sake of simplicity, the second embodiment will be described using an example of a transaction completed between the application server 32 and the DB server 33. That is, the transaction model is generated from the relationship between the IIOP message and the DB message.

  FIG. 40 is a diagram illustrating an example of a message input to the analysis unit. Protocol logs 401 to 420 stored in the protocol log storage unit 112 are input to the model generation unit 140.

The model generation unit 140 analyzes the message indicated in the protocol log according to a predetermined constraint condition.
FIG. 41 is a diagram illustrating processing recognized from a message input to the model generation unit. That is, the model generation unit 140 extracts the start and end of each process from the messages indicated by the protocol logs 401 to 420 in FIG. 40, and arranges the process periods in time series. The result is shown in FIG.

  The process P1 is a process recognized from the IIOP message with the identification number = 1 shown in the protocol logs 401 and 410. The process P2 is a process recognized from the IIOP message with the identification number = 2 shown in the protocol logs 403 and 413. The process P3 is a process recognized from the IIOP message with the identification number = 3 indicated in the protocol logs 407 and 419. The process P4 is a process recognized from the IIOP message with the identification number = 4 indicated by the protocol logs 411 and 420.

  The process P5 is a process recognized from the DB message of identification number = 1 shown in the protocol logs 402 and 405. The process P6 is a process recognized from the DB message with the identification number = 2 shown in the protocol logs 404 and 406. The process P7 is a process recognized from the DB message of identification number = 4 indicated by the protocol logs 409 and 412. The process P8 is a process recognized from the DB message of identification number = 3 indicated by the protocol logs 408 and 414. The process P9 is a process recognized from the DB message of identification number = 5 indicated by the protocol logs 415 and 417. The process P10 is a process recognized from the DB message of identification number = 6 indicated by the protocol logs 416 and 418.

In this example, two types of processing appear in IIOP and two types of processing appear in DB. However, in the following, in order to simplify the description, they are abbreviated as follows.
IIOP Mbalance: Type A
IIOP Mdeposit: Type B
Fetch-> Account by DB: Type a
Update-> Account by DB: Type b
In addition, since the method for obtaining the processing time for each processing type in the model is the same as that in the first embodiment, only the call relationship between the processing types in the model is noted here, and the explanation regarding the processing time is omitted. To do.

The constraint conditions in the second embodiment are as follows.
First restriction: The start time of a process called from a certain process is after the call start process start time, and the end time is before the call end process end time.

Second restriction: IIOP processing is directly called from outside the system (for example, the client 21).
Third restriction: DB processing is always called from IIOP.

  The first constraint requires that if process X calls process Y with basic constraints on call relationships, Y must start after X and end before X. In some cases, an upper limit value or a lower limit value of the difference between the start (end) of X and the start (end) time of Y may be given. In many systems, such a restriction is established, and by using this restriction, the number of call relation candidates can be reduced.

  The second constraint is a general constraint in a hierarchical configuration system, and indicates that a higher-level process (on the user side) calls a lower-level process, but not the other way around. In this case, the IIOP process is called from outside the monitored system, and the DB process is called from there. Other calls, for example, IIOP processing does not call other IIOP processing, and DB processing does not call IIOP processing.

  In addition to this, for example, a certain IIOP process calls a DB process at least once, such as the processing type, the number of calls between the groups and the restrictions on the order, etc. input.

  FIG. 42 is a diagram illustrating a call relationship between processes that satisfy a constraint. When the first to third constraints are used, other processes that can be called from a certain process are limited. That is, it is indicated which DB process can be called from which IIOP process (other calls do not satisfy the constraints).

  For example, the process P5 by DB can be called from the first constraint because the process period includes that of the process P5. In this example, only the process P1 by IIOP can be called. On the other hand, for the caller of process P7, there are three processes P2, P3, and P8 that satisfy the first constraint. Of these, the process P8 is a DB process, and it is understood that the process P7, which is the same DB process, cannot be called from the second constraint and the third constraint. Therefore, there are two candidates for calling the process P8, the process P2 and the process P3.

  Next, the number of calls of other types is calculated for each processing type from these call relationship candidates. Hereinafter, the number of calls from process type i to process type j is described as M (i, j), and M is referred to as a call number matrix.

First, the model generation unit 140 initializes a call count matrix. In the initialization, elements that satisfy the call-related restrictions are set to 1, and other elements are set to 0.
FIG. 43 is a diagram illustrating an example of a call frequency matrix. In this example, because there are four types of processing, the call count matrix has 16 elements, but only calls from IIOP to DB are allowed by the constraint, so 1 is set, and the other 12 are 0. This means that calls that are allowed by constraints are considered to occur with the same frequency (probability) unless there is other information.

  Next, the probability of the call candidate in FIG. 42 is calculated using the call frequency matrix. For example, since the possibility of the caller of process P5 is only process P1, the probability of calling from process P1 to process P5 is 1.

  On the other hand, there are two possibilities for the call to the process P6 (type a): the call from the process P1 (type A) and the call from the process P2 (type B). In such a case, a probability proportional to the value of the number-of-calls matrix element from the process type of the caller (candidate) to the type of the callee (process P6 in this case) is assigned. In this case, the number of times from the type A process to which the process P1 belongs to the type a process to which the process P6 belongs is one (see FIG. 43), and the number of calls from the type B to which the process P2 belongs is also one. Therefore, the probability of each call candidate is ½.

Hereinafter, the model generation unit 140 similarly obtains the probability of each call candidate.
FIG. 44 is a diagram illustrating a result of obtaining the probability of a call candidate. In the number-of-calls matrix shown in FIG. 43, the values of the elements indicating the call relationship that satisfies the constraints are all 1. Therefore, when there are a plurality of call possibilities, the call possibilities are equal (probability is 1/2).

  Next, the model generation unit 140 updates the value of the call count matrix using the above probability. That is, the number of calls from process type X to Y can be calculated as the sum of the probability of call candidates from X to Y divided by the number of occurrences of process type X among the call candidates in FIG.

For example, there are three call candidates from type A to type a: process P1 to process P5, process P1 to process P6, and process P4 to process P10, and the probabilities are 1, 1/2, and 1/2, respectively. . Since this and the processing of type A are two, processing P1 and processing P4, the value of the element M (A, a) of the call count matrix is
(1 + 1/2 + 1/2) / 2 = 1
It becomes. Similarly, the model generation unit 140 calculates other matrix elements.

  FIG. 45 is a diagram showing a call frequency matrix after update. However, since the values of elements that are not allowed to be restricted in the call matrix are always 0, only elements that are allowed by the restriction, that is, elements corresponding to calls from the IIOP processing type to the DB processing type are shown.

  The above-described call candidate probability calculation using the call number matrix and the update of the call number matrix based on the call candidate matrix are repeated until a predetermined termination condition is satisfied. The predetermined end condition is, for example, that the number of updates reaches a preset number. Another end condition is that the change amount of the matrix element before and after the update is equal to or less than a preset upper limit value.

  In the present embodiment, it is assumed that the end condition is two times of update. That is, the model generation unit 140 performs the call count and matrix element calculation again from the state shown in FIG. In the second and subsequent processes, the probability calculation method for each call candidate is the same as the first process. However, the number-of-calls matrix on which the probability calculation is based is the content shown in FIG. 45 and is different from FIG. 43 obtained above, so the calculated probability is also different.

  For example, there are two call candidates for the process P9 (type b): a call from the process P3 (type B) and a process P4 (type A). In the number-of-calls matrix shown in FIG. 45, the number of calls from type B to type b is 3/4, and the number of calls from type A to type b is 1/4. If the probability is assigned in proportion to this, the probability of the call from the process P3 to the process P9 is 3/4, and the probability of the call from the process P4 to the process P9 is 1/4 (the process P9 is the process P3 or the process P9). Note that the sum of the two probabilities is 1 because it is called from either P4).

Hereinafter, the model generation unit 140 similarly obtains the probability of each call candidate.
FIG. 46 is a diagram illustrating a result of obtaining the probability of a call candidate in the second process. In this way, when there is a plurality of call possibilities, the probability is calculated using the predicted value of the number of calls as a weight. Based on the probability of such call candidates, the call frequency matrix is updated.

  FIG. 47 is a diagram illustrating a call frequency matrix after the second update. The calculation method of the number of calls is the same as the first time. Since the number-of-calls matrix has been updated twice, the probability calculation / update process ends and the process proceeds to the next step.

  Next, round the non-integer part of the elements of the call count matrix to an integer by rounding off. In FIG. 47, since the number of calls from type A to type b is 1/8, this is set to 0. Since the number of calls from type B to type b is 7/8, this is set to one. Other than these, the value is an integer and is not changed.

  FIG. 48 is a diagram showing a call frequency matrix finally obtained and a generated transaction model. As shown in FIG. 48, the model generation unit 140 obtains a transaction model representing a call relationship between processing types from an integer number of call times matrix. That is, it can be seen from the call count matrix that IIOP process type A calls DB process type a once, and IIOP type B calls DB process type a and process type b once.

  That is, the call relationship set to 1 in the call frequency matrix is a relationship having a high occurrence probability. Therefore, the model generation unit 140 generates transaction models 431 and 432 recognized from the call relationship in which 1 is set in the call count matrix, and stores the transaction models 431 and 432 in the model storage unit 113.

The above processing procedure is organized as follows.
FIG. 49 is a flowchart illustrating a transaction model generation procedure according to the second embodiment. In the following, the process illustrated in FIG. 49 will be described in order of step number.

[Step S71] The model generation unit 140 extracts a start / end pair of each process from the protocol log.
[Step S72] The model generation unit 140 initializes a call count matrix. At this time, the calling relationship that does not satisfy the constraint is initialized to zero.

[Step S <b> 73] The model generation unit 140 extracts a call relationship between processes that satisfies a constraint as a call relationship candidate.
[Step S74] The model generation unit 140 determines whether an end condition is satisfied. If the end condition is satisfied, the process proceeds to step S77. If the end condition is not satisfied, the process proceeds to step S75.

[Step S75] The model generation unit 140 calculates the occurrence probability of each call relationship candidate so as to be proportional to the value of the call frequency matrix.
[Step S76] The model generation unit 140 averages the probability of each call relationship candidate for each processing type of the caller and callee, and updates the call count matrix. Thereafter, the process proceeds to step S74.

[Step S77] When the termination condition is satisfied, the model generation unit 140 approximates the call count matrix with an integer.
[Step S78] The model generation unit 140 outputs a transaction model in which a non-zero component of the call count matrix is set to the number of calls for each processing type.

  As described above, in the second embodiment, when there are a plurality of processes that can be called with respect to the process to be called, the call probability from each process is uniformly determined, and the process from the call source to the other processes are determined. The call probabilities are integrated for each type of process, and the possibility of a call relationship between processes is calculated. Thereby, a model can be generated even when a plurality of transactions are processed simultaneously. In addition, a model can be generated with a relatively small amount of calculation.

[Third Embodiment]
In the method shown in the second embodiment, the average number of calls between processing types is used. For this reason, for example, it is not possible to distinguish between a situation where a call is made twice with a probability of 1/2 and a situation where a call is made once with a probability of 1, and as a result, a correct transaction model may not be learned. Such a situation can occur, for example, when there are a plurality of call patterns from a certain processing type. In order to solve this, instead of obtaining a relationship between individual processing types as a call relationship candidate, a probability may be obtained for a set of all the processes called by a certain processing type and the order in the set. Hereinafter, a model generation method based on this concept will be described as a third embodiment.

  The functional blocks of the system analyzer in the third embodiment are the same as those in the first embodiment shown in FIG. Therefore, the processing of the third embodiment will be described using each element shown in FIG. Further, the first embodiment and the third embodiment are different only in the processing of the model generation unit 140, and the processing of other elements is the same.

Similarly, it is assumed that the input of the model generation unit 140 is the message string and the constraint in FIG.
First, the model generation unit 140 obtains a call relationship that can be performed between the processes as in the second embodiment. The results are as shown in FIG.

  Next, based on the possible call relationships shown in FIG. 42, a set of processes that each process is calling and a candidate for the order in the set are obtained. For example, a candidate for an ordered set of processes called by the process P1 (hereinafter referred to as a process set candidate) is obtained as follows.

When the call relationship shown in FIG. 42 is analyzed, two processes, process P5 and process P6, may be included in the set U (that is, called from process P1). Among these, the process P5 includes the set U because there is no other caller candidate. On the other hand, since the process P6 may be called from the process P2, both the possibility of being included in the set U and the possibility of not being included are considered. Since the process P5 starts earlier in the process P5 and the process P6, there are the following two candidates for the set U.
U11: {Process P5}
U12: {Process P5, Process P6}
In the description of the sets and processing set candidates, it is assumed that the processing is called from the left in order from the earliest processing. At this stage, since there is no judgment material regarding which of these two candidates is reliable, the reliability is the same, that is, 1/2.

Next, the processing set candidates U11 and U12 are converted into descriptions based on the processing types, and a pattern of processing called from the processing P1, that is, an ordered set candidate of the calling processing types is generated. Since the processing types of the processing P5 and the processing P6 are both a, the processing is as follows.
U11: Pattern {a}
U12: Pattern {a, a}
The latter process set candidate U12 represents the possibility that the process P1 calls the process of the same process type twice consecutively.

  Next, the reliability of the pattern is calculated from the reliability of the processing set that is the basis of the pattern. In this case, since different patterns are generated from the processing set candidate U11 and the processing set candidate U12, the reliability of the processing set candidate U11 and the processing set candidate U12 is used as it is. That is, 1/2.

From the above, the pattern candidates called by the process P1 and their reliability are as follows.
Pattern {a}: reliability 1/2
Pattern {a, a}: reliability 1/2
The second pattern shows a pattern in which the type a process is called twice. For other processes, the model generation unit 140 similarly obtains pattern type candidates and reliability that are called by the processes.

There are two processes P6 and P7 that can be called from the process P2, and both of these may be called from other processes, so the process set candidates called from the process P2 are The following four types. As in the case of the process P1, it is assumed that all these reliability levels are the same, that is, 1/4 at this stage.
U21: {}
U22: {Process P6}
U23: {Process P7}
U24: {Process P6, Process P7}
Since the types of the processes P6 and P7 are a and b, the process type pattern candidates called by the process P2 and their reliability are as follows.
Pattern {}: Reliability 1/4
Pattern {a}: reliability 1/4
Pattern {b}: reliability 1/4
Pattern {a, b}: reliability 1/4
The last pattern represents a pattern in which a and b are called in this order, that is, the process of type a is first called and then the process of b is called. Note that the number of processing types to be called can be used as a pattern without considering the order.

Care must be taken regarding the process P3. The process P3 is always called from the process P8 and the process P3, but the process P7, the process P9, and the process P10 may be called from other processes. Since there are three, the process set candidate that the process P3 is calling is
{Process P8}
{Process P8, Process P7}
{Process P8, Process P9}
{Process P8, Process P10}
{Process P8, Process P7, Process P9}
{Process P8, Process P7, Process P10}
{Process P8, Process P9, Process P10}
{Process P8, Process P7, Process P9, Process P10}
The reliability of each is 1/8. From here, the pattern and its reliability are calculated.

However, since both the process P7 and the process P9 are processes of type b, the same pattern {a, b} is generated from {process P8, process P7} and {process P8, process P9}. Similarly, a pattern {a, b, a} is generated from {Process P8, Process P7, Process P10} and {Process P8, Process P9, Process P10}. In such a case, the reliability of these patterns is calculated by taking the sum of the reliability of the corresponding processing set candidates. Therefore, the result is as follows.
Pattern {a}: reliability 1/8
Pattern {a, b}: reliability 1/4
Pattern {a, a}: reliability 1/8
Pattern {a, b, b}: reliability 1/8
Pattern {a, b, a}: Reliability 1/4
Pattern {a, b, b, a}: reliability 1/8
As for the process P4, the pattern and its reliability are as follows.
Pattern {}: Reliability 1/4
Pattern {b}: reliability 1/4
Pattern {a}: reliability 1/4
Pattern {b, a}: reliability 1/4
Next, by calculating the average of the process type pattern called from each process obtained above and its reliability for each process type of the caller, the pattern to be called and its probability are calculated for each process type. .

  First, since process P1 and process P4 belong to process type A, the average reliability of pattern candidates called from these processes is calculated. For example, since the pattern {a} has a reliability of 1/2 in the process P1 and a reliability of 1/4 in the process P4, the probability that this pattern is called from the process type A is the average, that is, 3/8. On the other hand, the pattern {a, a} has a reliability of 1/2 in the process P1, but does not exist in the pattern candidate in the process P4, that is, the reliability is 0, so the probability is 1/4.

  FIG. 50 is a first diagram showing a calling pattern from processing type A and its probability. As shown in FIG. 50, the probability of the pattern A1 {} is (0 + 1/4) / 2 = 1/8. The probability of the pattern A2 {b} is (0 + 1/4) / 2 = 1/8. The probability of the pattern A3 {a} is (1/2 + 1/4) / 2 = 3/8. The probability of the pattern A4 {a, a} is (1/2 + 0) / 2 = 1/4. The probability of the pattern A5 {b, a} is (0 + 1/4) / 2 = 1/8.

Similarly, taking the average of the processes belonging to process type B, that is, processes P2 and P3, the pattern called from process type B and its probability are calculated as follows.
FIG. 51 is a first diagram showing a calling pattern from processing type B and its probability. As shown in FIG. 51, the probability of the pattern B1 {} is (1/4 + 0) / 2 = 1/8. The probability of the pattern B2 {a} is (1/4 + 1/8) / 2 = 3/16. The probability of the pattern B3 {b} is (1/4 + 0) / 2 = 1/8. The probability of the pattern B4 {a, b} is (1/4 + 1/4) / 2 = 1/4. The probability of the pattern B5 {a, a} is (0 + 1/8) / 2 = 1/16. The probability of the pattern B6 {a, b, b} is (0 + 1/8) / 2 = 1/16. The probability of the pattern B7 {a, b, a} is (0 + 1/4) / 2 = 1/8. The probability of the pattern B8 {a, b, b, a} is (0 + 1/8) / 2 = 1/16.

Next, using the pattern to be called for each process type and its probability, the process set candidate (process set candidate) called from each process and its reliability are recalculated.
First, consider the process P1.
A possible call processing set candidate in process P1 is U11: {process P5}
U12: {Process P5, Process P6}
Is the same. However, the reliability was the same because there was no material for determining which is more likely last time, but this time, the reliability of the calling pattern for each processing type shown in FIGS. 50 and 51 can be used as the determination material. .

  However, the reliability of the processing set candidate U11 and the processing set candidate U12 needs to consider not only the probability of the call pattern from the process P1, but also other processes that affect the call candidate depending on which one is selected. is there.

  The difference between the processing set candidate U11 and the processing set candidate U12 is whether or not the process P6 is called from the process P1. Since the process P6 is called from the process P1 or the process P2, for example, selecting the process set candidate U11 is not simply a selection that the process P6 is not called from the process P1, but the process P6 is changed from the process P2 to the process P6. It is also a choice that it is called. Therefore, when calculating the reliability of the processing set candidate U11, it is necessary to consider how much the selection of the call from the processing P2 is restricted thereby.

  In the case of the processing set candidate U11, the calling pattern from the processing P1 (type A) is A3, and the probability of this pattern is 3/8. On the other hand, in the case of the processing set candidate U12, since the pattern is A4, the probability is 1/4. However, the reliability of the processing set candidate U11 and the processing set candidate U12 does not use these probabilities as they are, but considers how call patterns from other processes are limited thereby.

  That is, for example, when the call from the process P1 is the process set candidate U11, the process P6 is not called from the process P1. Therefore, it is always called from another candidate, that is, the process P2. Therefore, the set of processes called from the process P2 must be {process P6} or {process P6, process P7}.

  Since the types of the processing P6 and the processing P7 are a and b, the processing type pattern is B2 or B4, and the probabilities are 3/16 and 1/4, respectively. Therefore, as for the reliability of the processing set candidate U11, the probability on the processing P2 side can be estimated as the sum of these probabilities, that is, 7/16. Using this, the reliability of the processing set candidate U11 is the product of the probability 3/8 that the processing set candidate U11 is called on the process P1 side and the probability 7/16 resulting from the restriction on the process P2 side, that is, 21/128. .

  On the other hand, in the case of the process set candidate U12, the process P6 is called from the process P1, so the process set candidate to be called on the process P2 side is either {} or {process P7}. Then, it is B1 or B3. Since these probabilities are both 1/8, the reliability of the processing set candidate U12 is 1/4 × (1/8 + 1/8) = 1/16 = 8/128.

Since either one of the processing set candidate U11 or the processing set candidate U12 is correct, normalization is performed so that the sum of the reliability of both becomes 1, and finally the reliability of the processing set candidate U11 and the processing set candidate U12 is determined. U11: {Process P5} reliability 21/29
U12: {Process P5, Process P6} Reliability 8/29
And That is, it is determined that the processing set candidate U11 is more likely.

Next, this is converted into a processing type pattern and its reliability in the same manner as above.
Pattern {a}: reliability 21/29
Pattern {a, a}: reliability 8/29
For process P2, process P3, and process P4, the reliability of possible call processing set candidates is calculated in the same manner as in process P1, and the reliability for each pattern of the call type is calculated therefrom. The results are shown below.

The process P2 is as follows.
Pattern {}: Reliability 4/33
Pattern {a}: reliability 9/33
Pattern {b}: reliability 5/33
Pattern {a, b}: reliability 15/33
The process P3 is as follows.
Pattern {a}: reliability 18/101
Pattern {a, b}: reliability 46/101
Pattern {a, a}: reliability 6/101
Pattern {a, b, b}: reliability 15/101
Pattern {a, b, a}: reliability 11/101
Pattern {a, b, b, a}: reliability 5/101
The process P4 is as follows.
Pattern {}: Reliability 3/28
Pattern {b}: reliability 3/28
Pattern {a}: reliability 15/28
Pattern {b, a}: reliability 7/28
Next, the call pattern for each processing type and its probability are obtained by averaging the call patterns for each processing type from the reliability of the calling pattern for each processing of the calling source as before.

  FIG. 52 is a second diagram showing a calling pattern from processing type A and its probability. As shown in FIG. 52, the probability of the pattern A1: {} is 87/1624 = 0.054. Pattern A2: the probability of {b} is 87/1624 = 0.054. Pattern A3: The probability of {a} is 1023/1624 = 0.630. Pattern A4: The probability of {a, a} is 224/1624 = 0.138. Pattern A5: The probability of {b, a} is 203/1624 = 0.125.

Similarly, taking the average of the processes belonging to process type B, that is, processes P2 and P3, the pattern called from process type B and its probability are calculated as follows.
FIG. 53 is a second diagram showing a calling pattern from processing type B and its probability. As shown in FIG. 53, the probability of the pattern B1: {} is 404/6666 = 0.061. Pattern B2: The probability of {a} is 1503/6666 = 0.225. Pattern B3: The probability of {b} is 505/6666 = 0.076. Pattern B4: The probability of {a, b} is 3033/6666 = 0.455. Pattern B5: The probability of {a, a} is 198/6666 = 0.030. Pattern B6: The probability of {a, b, b} is 495/6666 = 0.074. Pattern B7: The probability of {a, b, a} is 363/6666 = 0.054. Pattern B8: The probability of {a, b, b, a} is 165/6666 = 0.025.

  A set of calling processes for each process and a calculation of the reliability thereof, and a call pattern for each processing type and a calculation of the probability thereof are performed until an appropriate end condition is satisfied. As in the second embodiment, the end condition is determined by the number of repetitions, the upper limit of the amount of change in probability for each pattern, or the like.

  When the termination condition is satisfied in the state shown in FIGS. 52 and 53, the model generation unit 140 generates a model from the calling patterns and the probabilities thereof shown in FIGS. At this time, a model with a small probability is subjected to reliability. Therefore, for each processing type of the caller, a pattern to be adopted as a model is selected using the upper limit of the number of selections and the lower limit of the probability in descending order of probability from the possible patterns.

  For example, if the upper limit of the selection number is 2 and the lower limit of the probability is 0.1, the pattern A3 and the pattern A4 are selected as the model for the call source process type A, and the patterns B4 and B2 are selected as the models for the process type B Is done. The final model is generated by re-normalizing so that the sum of probabilities becomes 1 using only the selected pattern.

  FIG. 54 is a diagram showing a model generation result. For IIOP type A, two transaction models 441 and 442 are generated. The probability of the transaction model 441 is 0.82 (= 0.630 / (0.630 + 0.138)), and the probability of the transaction model 442 is 0.18 (= 0.138 / (0.630 + 0.138). ).

  For IIOP type B, two transaction models 443 and 444 are generated. The probability of the transaction model 443 is 0.80 (= 0.574 / (0.574 + 0.142)), and the probability of the transaction model 444 is 0.20 (= 0.142 / (0.574 + 0.142). ).

The above processing procedure is organized as follows.
FIG. 55 is a flowchart illustrating a transaction model generation procedure according to the third embodiment. In the following, the process illustrated in FIG. 55 will be described in order of step number.

[Step S81] The model generation unit 140 extracts a start and end pair of each process from the protocol log.
[Step S82] The model generation unit 140 extracts a call relationship between processes that satisfies a constraint as a call relationship candidate.

[Step S <b> 83] For each process, the model generation unit 140 generates a set of called processes (call destination process set) from the call relationship candidates that use the process as a caller.
[Step S84] The model generation unit 140 initializes the occurrence probability of the callee process set (allocates the probability evenly for each caller process).

[Step S85] The model generation unit 140 calculates a calling pattern and its probability depending on the processing type from the calling destination processing set and its probability.
[Step S86] The model generation unit 140 determines whether an end condition is satisfied. If the end condition is satisfied, the process proceeds to step S88. If the end condition is not satisfied, the process proceeds to step S87.

  [Step S87] The model generation unit 140 recalculates the occurrence probability of each candidate of the callee processing set from the call pattern and the probability for each processing type. Thereafter, the process proceeds to step S85.

  [Step S88] When the termination condition is satisfied, the model generation unit 140 selects, as a transaction model, a pattern satisfying a predetermined condition (for example, having a higher probability than a predetermined value) among the calling patterns for each processing type. To do.

[Step S89] The model generation unit 140 normalizes the probability of the selected model for each caller type. Thereafter, the process ends.
Thus, in the third embodiment, one or more occurrence patterns indicating combinations of processes that can be called are generated for each process type, and the occurrence probability is calculated for each occurrence pattern. Then, a predetermined number of occurrence patterns having higher occurrence probabilities are selected, and a transaction model is generated based on the selected occurrence pattern. Thereby, even when there are a plurality of possible processing patterns for a processing type of a certain caller, the model can be generated correctly.

In this method, when the multiplicity is high, the amount of processing increases greatly. Therefore, the amount of processing can be reduced by the following method.
In the third embodiment, a transaction model is generated by updating a pattern to be called for each processing type and its probability several times. And the pattern with low possibility is removed from the pattern finally obtained. At this time, when updating the pattern and its probability, it is also possible to remove a pattern that is less likely each time. Since the call pattern once removed does not need to be considered as a possibility during the subsequent model generation process, the time required for model generation can be shortened by removing it early in model generation.

  For example, at the stage where FIGS. 50 and 51 are generated, that is, at the stage where the first possible pattern and its probability are generated, the pattern whose probability is equal to or less than the threshold is deleted. When the threshold is 0.1, the probability of the call pattern from the processing type A shown in FIG. 50 is 1/8 or higher and is not deleted. On the other hand, in the case of the processing type B shown in FIG. 51, the probability of the three patterns of pattern B5, pattern B6, and pattern B8 is 1/16, which is equal to or less than the threshold value, and can be deleted. The erased pattern indicates that the process is not called by these patterns from the actual process.

This means that it is not necessary to consider the erased pattern when determining the probability of a possible pattern again. For example, as described in the above example, the set of processes called from the type B process P3 is {process P8}.
{Process P8, Process P7}
{Process P8, Process P9}
{Process P8, Process P10}
{Process P8, Process P7, Process P9}
{Process P8, Process P7, Process P10}
{Process P8, Process P9, Process P10}
{Process P8, Process P7, Process P9, Process P10}
It is. Since the type of process P8 and process P10 is a and the type of process P7 and process P9 is b, {process P8, process P10} is pattern B5, and {process P8, process P7, process P9} is a pattern. B6, {Process P8, Process P7, Process P9, Process P10} belongs to pattern B8. That is, these calls cannot occur. Therefore, it is not necessary to consider the occurrence of these calls in subsequent processing. By excluding patterns that cannot occur from the determination targets, the subsequent processing amount can be reduced.

[Other application examples]
In each of the above embodiments, the packets constituting the message are collected from the mirror port of the switch 10, but the dump data of the message is recorded in each server 31, 32, 33, and the message observation unit 120 Dump data may be collected from each server 31, 32, 33.

  Also, the transaction model can be updated according to the content analyzed by the analysis unit 150. For example, when the processing time in each server in an arbitrary type of transaction is obtained by the analysis unit 150, the average of the processing time for each type can be obtained and used as the processing time of the corresponding transaction model.

  The above processing functions can be realized by a computer. In that case, a program describing the processing contents of the functions that the system analysis apparatus should have is provided. By executing the program on a computer, the above processing functions are realized on the computer. The program describing the processing contents can be recorded on a computer-readable recording medium. Examples of the computer-readable recording medium include a magnetic recording device, an optical disk, a magneto-optical recording medium, and a semiconductor memory. Examples of the magnetic recording device include a hard disk device (HDD), a flexible disk (FD), and a magnetic tape. Examples of the optical disc include a DVD (Digital Versatile Disc), a DVD-RAM (Random Access Memory), a CD-ROM (Compact Disc Read Only Memory), and a CD-R (Recordable) / RW (ReWritable). Magneto-optical recording media include MO (Magneto-Optical disk).

  When distributing the program, for example, a portable recording medium such as a DVD or a CD-ROM in which the program is recorded is sold. It is also possible to store the program in a storage device of a server computer and transfer the program from the server computer to another computer via a network.

  The computer that executes the program stores, for example, the program recorded on the portable recording medium or the program transferred from the server computer in its own storage device. Then, the computer reads the program from its own storage device and executes processing according to the program. The computer can also read the program directly from the portable recording medium and execute processing according to the program. In addition, each time the program is transferred from the server computer, the computer can sequentially execute processing according to the received program.

(Supplementary note 1) In a system analysis program for analyzing a network operation form in which a plurality of servers are connected by a computer,
In the computer,
Message observing means collects messages passed through the network,
The message analysis unit analyzes the contents of the collected message to determine the processing type requested by the message and whether it is a request message or a response message. The determined information is stored in the protocol log storage unit as a protocol log. Store and
When a model generation instruction is input, the model generation unit causes each process corresponding to the process type to be determined according to the correspondence between the request message and the response message for each process type in the protocol log stored in the protocol log storage unit. And generating a transaction model that satisfies the constraint on the call relationship between processes based on the message set selected according to the selection criteria based on the probability of the call relationship between processes, and storing the generated transaction model in the transaction model storage Stored in the means,
When an analysis instruction is input, the analysis means extracts from the protocol log storage means the protocol log that matches the call relationship indicated by the transaction model stored in the transaction model storage means, and the extracted protocol Analyze the transaction processing state consisting of the messages shown in the log,
A system analysis program characterized by causing processing to be executed.

  (Additional remark 2) The said message observation means collects the said message via the mirror port of the switch provided in the said network, The system analysis program of Additional remark 1 characterized by the above-mentioned.

  (Additional remark 3) The said message observation means collects the said message from the dump data of the message hold | maintained at the said server, The system analysis program of Additional remark 1 characterized by the above-mentioned.

  (Supplementary Note 4) The system analysis program according to Supplementary Note 1, wherein the model generation means defines, as the constraint condition, a condition that a processing time zone of a call source includes a processing time zone of a call destination .

(Supplementary note 5) The system analysis program according to supplementary note 1, wherein the model generation means defines a calling direction between servers as a constraint condition.
(Additional remark 6) The said model production | generation means calculates the time required in the said server of the process corresponding to each protocol based on the time from the request message of each process type in the same transaction to a response message, The said transaction model The system analysis program according to appendix 1, which is set to

  (Additional remark 7) The said model production | generation means determines the processing time zone of each transaction from the request message first called from a client, and the response message corresponding to the said request message, and processing time between other transactions The system analysis program according to claim 1, wherein a non-multiple transaction having no overlapping band is detected, and the transaction model is generated based on the protocol log generated within a processing time zone of the detected non-multiple transaction. .

  (Supplementary Note 8) When there are a plurality of processes that can be called for the process to be called, the model generation means uniformly determines the call probability from each process, and determines the call probability of another process from the call source process. The system analysis program according to appendix 1, wherein the system analysis program is integrated for each type of processing and the possibility of a call relationship between the processing is calculated.

  (Additional remark 9) The said model production | generation means produces | generates one or more generation | occurrence | production patterns which show the combination of the process which can be called for every process classification, calculates the occurrence probability for every said generation pattern, and the said occurrence probability is high-order. The system analysis program according to appendix 1, wherein a predetermined number of generation patterns are selected, and the transaction model is generated based on the selected generation patterns.

(Supplementary Note 10) In a system analysis method for analyzing a network operation mode in which a plurality of servers are connected by a computer,
Message observing means collects messages passed through the network,
The message analysis unit analyzes the contents of the collected message to determine the processing type requested by the message and whether it is a request message or a response message. The determined information is stored in the protocol log storage unit as a protocol log. Store and
When a model generation instruction is input, the model generation unit causes each process corresponding to the process type to be determined according to the correspondence between the request message and the response message for each process type in the protocol log stored in the protocol log storage unit. And generating a transaction model that satisfies the constraint on the call relationship between processes based on the message set selected according to the selection criteria based on the probability of the call relationship between processes, and storing the generated transaction model in the transaction model storage Stored in the means,
When an analysis instruction is input, the analysis means extracts from the protocol log storage means the protocol log that matches the call relationship indicated by the transaction model stored in the transaction model storage means, and the extracted protocol Analyze the transaction processing state consisting of the messages shown in the log,
A system analysis method characterized by the above.

(Supplementary Note 11) In a system analysis apparatus for analyzing an operation mode of a network in which a plurality of servers are connected,
Message observing means for collecting messages passed through the network;
Message analysis means for analyzing the content of the collected message to determine the processing type requested by the message and whether it is a request message or a response message, and storing the determined information in the protocol log storage means as a protocol log When,
When a model generation instruction is input, each process corresponding to the process type is identified by the correspondence between the request message and the response message for each process type in the protocol log stored in the protocol log storage unit, A model for generating a transaction model that satisfies a constraint condition regarding a call relationship between processes based on a message set selected according to a selection criterion based on a probability of a call relationship between them, and storing the generated transaction model in a transaction model storage unit Generating means;
When an analysis instruction is input, the protocol log that matches the call relationship indicated by the transaction model stored in the transaction model storage means is extracted from the protocol log storage means, and is indicated in the extracted protocol log An analysis means for analyzing a processing state of a transaction composed of messages;
A system analysis apparatus comprising:

(Supplementary Note 12) In a computer-readable recording medium in which a system analysis program for analyzing a network operation form to which a plurality of servers are connected is analyzed by a computer,
In the computer,
Message observing means collects messages passed through the network,
The message analysis unit analyzes the contents of the collected message to determine the processing type requested by the message and whether it is a request message or a response message. The determined information is stored in the protocol log storage unit as a protocol log. Store and
When a model generation instruction is input, the model generation unit causes each process corresponding to the process type to be determined according to the correspondence between the request message and the response message for each process type in the protocol log stored in the protocol log storage unit. And generating a transaction model that satisfies the constraint on the call relationship between processes based on the message set selected according to the selection criteria based on the probability of the call relationship between processes, and storing the generated transaction model in the transaction model storage Stored in the means,
When an analysis instruction is input, the analysis means extracts from the protocol log storage means the protocol log that matches the call relationship indicated by the transaction model stored in the transaction model storage means, and the extracted protocol Analyze the transaction processing state consisting of the messages shown in the log,
A computer-readable recording medium having recorded thereon a system analysis program characterized in that processing is executed.

DESCRIPTION OF SYMBOLS 1 System analyzer 1a Message observation means 1b Message analysis means 1c Protocol log storage means 1d Model generation means 1e Transaction model storage means 1f Analysis means 1g Output means 2 Network 3a, 3b, ... Client 4a, 4b, ... Server 5 messages

Claims (8)

An analysis program for analyzing transactions between multiple servers,
On the computer,
A procedure for collecting messages transmitted and received between the plurality of servers;
A model for obtaining a call relationship by referring to information on a message pair of a request message and a response message obtained by analyzing the contents of the collected message, and generating a transaction model that satisfies a constraint condition on the obtained call relationship Generation procedure,
An analysis procedure for analyzing a transaction composed of the message pair indicated in the information that matches the call relationship indicated in the transaction model;
And execute
The plurality of servers are arranged in a hierarchy,
The model generation procedure includes:
Analyzing the contents of the collected message to obtain the information having a plurality of pairs of the time when the message was collected and an identifier indicating a message pair of a request message and a response message,
It is determined from the time whether or not there is a message pair processed by a higher-level server and having another identifier between message pairs processed by a higher-level server,
If it does not exist, the message pair between the message pair is also determined as a message pair related to one transaction and the call relationship is obtained, and the processing time required for processing is obtained from the time of the request message and the time of the response message. A transaction model having the obtained calling relationship and the obtained processing time,
The analysis procedure analyzes a processing time of a transaction composed of a message pair indicated in the information that matches the call relationship indicated in the transaction model.
An analysis program characterized by that .   An analysis program for analyzing transactions between multiple servers,
  On the computer,
  A procedure for collecting messages transmitted and received between the plurality of servers;
  A model for obtaining a call relationship by referring to information on a message pair of a request message and a response message obtained by analyzing the contents of the collected message, and generating a transaction model that satisfies a constraint condition on the obtained call relationship Generation procedure,
  And execute
  The model generation procedure includes:
  Analyzing the content of the collected message, and having a plurality of sets of the collection time of the message, an identifier indicating a message pair of a request message and a response message, and a processing type requested by the message Seeking information,
  Whether or not there is a message pair having another identifier that is a processing type processed by a higher-level server among the processing type message pairs processed by a higher-level server from the above time. Judgment
  If the message pair does not exist, the message pair between the message pair is also determined as a message pair related to one transaction to obtain a calling relationship, and the processing corresponding to the processing type is performed from the time of the request message and the time of the response message. Obtaining a required processing time, and generating a transaction model having the obtained calling relationship and the obtained processing time.
  An analysis program characterized by that. When there are a plurality of processes that can be called with respect to the process that is the call destination, the model generation procedure determines the call probability from each process equally, and determines the call probability of the other process from the call source process for each process type. To calculate the possibility of a call relationship between processes,
  The analysis program according to claim 2. The model generation procedure generates at least one occurrence pattern indicating a combination of processes that can be called for each process type, calculates an occurrence probability for each occurrence pattern, and sets the occurrence pattern having a higher occurrence probability to a predetermined value. Generating the transaction model based on the selected occurrence pattern.
  The analysis program according to claim 2 or 3. A control program for controlling an analyzer that analyzes a transaction executed in a system having a plurality of servers,
  In the analyzer,
  A storage procedure for storing information on a message pair of a request message and a response message in a storage unit based on the content of a message transmitted and received between the plurality of servers.
  A model generation procedure for generating a transaction model having a call relationship determined based on the information;
  An analysis procedure for extracting the information that matches the call relationship indicated by the transaction model from the storage means, and analyzing a transaction including a message pair indicated by the extracted information;
  And execute
  The plurality of servers are arranged in a hierarchy,
  The storing procedure stores, in the storage unit, the information having a plurality of pairs of a time when the message is collected and an identifier indicating a message pair of a request message and a response message based on the content of the message. ,
  The model generation procedure refers to the information to determine whether there is a message pair processed by a higher-level server and having another identifier between message pairs processed by a higher-level server. If it is determined from the time and does not exist, a message pair between the message pairs is also determined as a message pair related to one transaction, and a call relationship is obtained, and processing is performed from the time of the request message and the time of the response message. Generating a transaction model having the call relationship obtained and the obtained processing time;
  The analysis procedure extracts the information that matches the call relationship indicated by the transaction model from the storage means, and analyzes the processing time of a transaction composed of message pairs indicated by the extracted information.
  A control program characterized by that. The storage procedure analyzes the contents of the collected message, and includes the time when the message is collected, an identifier indicating a message pair of a request message and a response message, and a processing type requested by the message. Storing the information having a plurality of sets in the storage means;
  The model generation procedure refers to the information, and has a processing type processed by a higher-level server and another identifier between processing type message pairs processed by a higher-level server. It is determined from the time whether or not a message pair exists. If the message pair does not exist, a message pair between the message pairs is also determined as a message pair related to one transaction to obtain a calling relationship, and the request message Obtaining a processing time required for the processing corresponding to the processing type from the time of the time and the response message, and generating a transaction model having the obtained calling relationship and the obtained processing time.
  The control program according to claim 5. When there are a plurality of processes that can be called with respect to the process that is the call destination, the model generation procedure determines the call probability from each process equally, and determines the call probability of the other process from the call source process for each process type. To calculate the possibility of a call relationship between processes,
  7. The control program according to claim 5 or 6, wherein: The model generation procedure generates at least one occurrence pattern indicating a combination of processes that can be called for each process type, calculates an occurrence probability for each occurrence pattern, and sets the occurrence pattern having a higher occurrence probability to a predetermined value. Generating the transaction model based on the selected occurrence pattern.
  The control program according to claim 5, wherein

Images