WO2014174681A1 - 特定装置、特定方法、および特定プログラム - Google Patents

特定装置、特定方法、および特定プログラム Download PDF

Info

Publication number
WO2014174681A1
WO2014174681A1 PCT/JP2013/062471 JP2013062471W WO2014174681A1 WO 2014174681 A1 WO2014174681 A1 WO 2014174681A1 JP 2013062471 W JP2013062471 W JP 2013062471W WO 2014174681 A1 WO2014174681 A1 WO 2014174681A1
Authority
WO
WIPO (PCT)
Prior art keywords
request
http
type
sql
http request
Prior art date
Application number
PCT/JP2013/062471
Other languages
English (en)
French (fr)
Inventor
峰義 増田
清美 和田
水野　潤
Original Assignee
株式会社日立製作所
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by 株式会社日立製作所 filed Critical 株式会社日立製作所
Priority to PCT/JP2013/062471 priority Critical patent/WO2014174681A1/ja
Priority to JP2015513472A priority patent/JP6031597B2/ja
Priority to US14/427,954 priority patent/US9705772B2/en
Publication of WO2014174681A1 publication Critical patent/WO2014174681A1/ja

Links

Images

Classifications

    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0876—Network utilisation, e.g. volume of load or congestion level
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3409—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment
    • G06F11/3419—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment for performance assessment by assessing time
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/0706—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment
    • G06F11/0709—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation the processing taking place on a specific hardware platform or in a specific software environment in a distributed system consisting of a plurality of standalone computer nodes, e.g. clusters, client-server systems
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/07—Responding to the occurrence of a fault, e.g. fault tolerance
    • G06F11/0703—Error or fault processing not based on redundancy, i.e. by taking additional measures to deal with the error or fault not making use of redundancy in operation, in hardware, or in data representation
    • G06F11/079—Root cause analysis, i.e. error or fault diagnosis
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/30—Monitoring
    • G06F11/34—Recording or statistical evaluation of computer activity, e.g. of down time, of input/output operation ; Recording or statistical evaluation of user activity, e.g. usability assessment
    • G06F11/3452—Performance evaluation by statistical analysis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/01—Protocols
    • H04L67/02—Protocols based on web technology, e.g. hypertext transfer protocol [HTTP]
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L67/00—Network arrangements or protocols for supporting network services or applications
    • H04L67/50—Network services
    • H04L67/60—Scheduling or organising the servicing of application requests, e.g. requests for application data transmissions using the analysis and optimisation of the required network resources
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/81—Threshold
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/835—Timestamp
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F2201/00—Indexing scheme relating to error detection, to error correction, and to monitoring
    • G06F2201/875—Monitoring of systems including the internet
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L41/00—Arrangements for maintenance, administration or management of data switching networks, e.g. of packet switching networks
    • H04L41/06—Management of faults, events, alarms or notifications
    • H04L41/0631—Management of faults, events, alarms or notifications using root cause analysis; using analysis of correlation between notifications, alarms or events based on decision criteria, e.g. hierarchy, tree or time analysis
    • H—ELECTRICITY
    • H04—ELECTRIC COMMUNICATION TECHNIQUE
    • H04L—TRANSMISSION OF DIGITAL INFORMATION, e.g. TELEGRAPHIC COMMUNICATION
    • H04L43/00—Arrangements for monitoring or testing data switching networks
    • H04L43/08—Monitoring or testing based on specific metrics, e.g. QoS, energy consumption or environmental parameters
    • H04L43/0852—Delays

Definitions

  • the present invention relates to a specifying device, a specifying method, and a specifying program for specifying a cause of a performance failure that has occurred in a computer system.
  • Computer system performance management is one of the important roles of the operation department.
  • the operation department (A) detects deterioration in the performance of the service provided by the computer system to the end user, and (B) identifies the cause and deals with it.
  • This technology is a technology for monitoring a processing request from an end user to a computer system and detecting a delay in the processing request.
  • the computer system is a Web system
  • the HTTP request packet sent from the end user to the computer system is monitored, the response time is obtained from the time difference between the processing request packet and the response packet, and the presence or absence of a delay is detected.
  • the work of identifying the cause of the performance failure in (B) is often performed on a database that is particularly susceptible to performance failure.
  • the operation manager monitors the processing request (SQL statement) sent to the database, and identifies the SQL statement that seems to be the cause of the performance failure from the execution time record.
  • HTTP request monitoring in (A) and SQL statement monitoring in (B) are performed individually, so they cannot be associated with each other. For this reason, even if the delay of the HTTP request is detected in (A), the SQL statement causing the delay cannot be efficiently identified.
  • the analysis device of Patent Document 1 calculates the probability that the second group exists between the request and the response in the first group, and based on the calculated probability, the predetermined first A second set corresponding to the set is extracted. That is, the analysis apparatus of Patent Literature 1 extracts a second set corresponding to a predetermined first set based on the probability without using a model in which related information is defined in advance. Therefore, even if the correspondence between the new first group and the second group occurs due to a change in the system specifications, the analysis apparatus of Patent Document 1 has the new first group and the second group. Tie.
  • Patent Document 1 the probability (that is, the correlation) that the HTTP request and the SQL request measured independently are observed in the same period is calculated.
  • the probability that a specific SQL sentence appears during the processing period of a certain HTTP request is high, it is assumed that there is a relationship between the two.
  • the object of the present invention is to reduce the amount of calculation for obtaining the correspondence between a plurality of data observed independently.
  • the identification device, the identification method, and the identification program which are one aspect of the invention disclosed in the present application, are an identification device, an identification method, and an identification program connected to the first device and the second device, A processor for executing, a memory for storing a program to be executed by the processor, and an interface for controlling communication with the first device and controlling communication with the second device,
  • the memory stores a first request set received by the first device and a second request set processed by the second device in response to a request from the first device, the processor , Obtaining from the first request set a request group of the same type that is the same type as the request to be investigated in the first request set, During the processing period from when the request is sent from the first device to the second device and when the response is sent from the second device to the first device, for each request of the quest and the request of the same type A request of another type different from the type of the request to be investigated, which is transmitted from the first device to the second device and a response is transmitted from the second device to the first device, Obtained from
  • the second request processed by the second device during the processing period is acquired from the second request set, and the investigation target request after the deletion and the request
  • a correlation value with the acquired second request is calculated, and a calculation result is output.
  • FIG. 1 is a system configuration diagram of a monitoring system according to Embodiment 1.
  • FIG. It is explanatory drawing which shows the example of a memory content of the HTTP monitoring data table shown in FIG.
  • FIG. It is explanatory drawing which shows the example of a memory content of a SQL monitoring data table.
  • It is a flowchart which shows the example of an operation processing procedure of an HTTP monitoring program.
  • It is explanatory drawing which shows the example of a screen which a SQL sentence specific program displays on a display apparatus.
  • It is a flowchart which shows the example of a process sequence by a SQL sentence specific program.
  • FIG. 9 is a flowchart showing a detailed processing procedure example of the entry deletion processing (step S806) shown in FIG. 8.
  • FIG. FIG. 3 is a system configuration diagram of a monitoring system according to a second embodiment. It is explanatory drawing which shows the example of the memory content of the table utilized with the monitoring system concerning Example 2.
  • FIG. 12 is a flowchart illustrating a detailed processing procedure example of an SQL statement specifying process by an SQL statement specifying program according to Embodiment 2; 13 is a flowchart (first half) showing a detailed processing procedure example of the HTTP-SQL tabulation table update processing (step S1204) shown in FIG.
  • FIG. 13 is a flowchart (second half) illustrating a detailed processing procedure example of the HTTP-SQL tabulation table update processing (step S1204) illustrated in FIG. It is a flowchart which shows the detailed process sequence example of the 1st update process (step S1310) shown in FIG. It is a flowchart which shows the detailed process sequence example of the 2nd update process (step S1404) shown in FIG. 12 is a flowchart illustrating a detailed processing procedure example of a startup process of an SQL statement specifying program 82 by an HTTP monitoring program according to a second embodiment; FIG. 6 is a system configuration diagram of a monitoring system according to a third embodiment. It is explanatory drawing which shows the example of the memory content of the baseline table shown in FIG. It is a flowchart which shows the detailed process sequence example of the monitoring mode change process sequence by a SQL sentence monitoring program.
  • program is used as the subject.
  • the program performs processing determined by being executed by the processor using the memory and the communication port (communication control device)
  • the processor is used as the subject.
  • the explanation may be as follows. Further, the processing disclosed with the program as the subject may be processing performed by a computer such as a management server or an information processing apparatus. Further, part or all of the program may be realized by dedicated hardware.
  • the program distribution server includes a processor and a storage resource, and the storage resource further stores a distribution program and a program to be distributed.
  • the processor executes the distribution program
  • the processor of the program distribution server distributes the distribution target program to other computers.
  • the monitoring computer has an input / output device.
  • input / output devices include a display, a keyboard, and a pointer device, but other devices may be used.
  • a serial interface or an Ethernet interface is used as the input / output device, and a display computer having a display or keyboard or pointer device is connected to the interface, and the display information is transmitted to the display computer.
  • the display computer may perform the display, or the input may be replaced by the input / output device by receiving the input.
  • a set of one or more computers that monitor the computer system to be monitored and display the display information of the present invention may be called a monitoring system.
  • the management computer displays display information
  • the monitoring computer is a management system
  • the combination of the monitoring computer and the display computer is also a monitoring system.
  • a plurality of computers may realize processing equivalent to that of the monitoring computer.
  • the plurality of computers if the display computer performs display, display (Including computers) is the monitoring system.
  • the correspondence between an HTTP (HyperText Transfer Protocol) request, which is an example of the first request, and an SQL (Structured Query Language) statement, which is an example of the second request, is accurately obtained with a smaller calculation amount.
  • the cause candidate SQL sentence is efficiently identified from the delayed HTTP request as a starting point.
  • the conventional method described in the background art section obtains the correlation between the HTTP request and the SQL sentence in a brute force manner, whereas the present embodiment calculates by limiting to a certain period. Significantly reduce the amount.
  • FIG. 1 is an explanatory diagram showing a specific example of a cause candidate for a performance failure in the embodiment of the present invention.
  • the vertical line at the left end is the time axis and indicates the passage of time from top to bottom.
  • the left column is an HTTP request measured during a certain period
  • the middle column is an SQL statement measured between the left column and the synchronization
  • the right column correlates each period in the left column and the middle column. Indicates whether or not to use for calculation.
  • the box “# 1” in the left column indicates “a certain period”.
  • four periods, that is, # 1, # 2, # 3, and # 4 are illustrated, and the notation explanation taking the period # 1 as an example is the other periods # 2, # 3, and # 4. 4 is also common.
  • the box in the left column # 1 indicates that two HTTP requests, that is, HTTP requests of the types H1 and H2, are processed in parallel with the period # 1.
  • H1 and H2 are codes that simply represent information that can identify the type of HTTP request, such as the type of HTTP request, that is, URL (Uniform Resource Locator) and similar identification information.
  • the HTTP request H1 with a dark hatch in FIG. 1 indicates a delay (performance failure).
  • an HTTP request (in this case, H1) for which a delay occurs and the cause of the performance failure is specified is referred to as a target HTTP request, and other HTTP requests (in this case, H2, H3,...) Are referred to as disturbance HTTP requests.
  • the middle column also indicates that two SQL statements, that is, SQL statements of the types S1 and S2, were processed in parallel during the period # 1, as in the above-described HTTP monitoring data.
  • S1 is an SQL statement processed by DBMS (DataBase Management System) during the processing of the HTTP request H1.
  • DBMS DataBase Management System
  • FIG. 1 shows a small number of cases for both HTTP requests and SQL statements, but there may actually be several tens to several hundreds per second.
  • the relevance of both is estimated based on the temporal correlation between the HTTP request and the SQL sentence.
  • the period used for the correlation calculation is limited by the following method to reduce the amount of calculation.
  • Method 1 Select a period with few disturbance HTTP requests.
  • the specific device selects a period in which there are few disturbance HTTP requests processed simultaneously with the target HTTP request, and performs correlation calculation. For example, if only the target HTTP request is being processed, there is a high probability that the SQL sentence measured during the synchronization is related to the target HTTP request. Conversely, in a period in which there are many disturbance HTTP requests, there are often many SQL statements measured during the same period. In the correlation calculation in the period, the probability that the relationship between the target HTTP request and the SQL sentence is correctly obtained is low.
  • Period # 2 shows a case where there are many disturbance HTTP requests.
  • the target HTTP request H1 three disturbance HTTP requests H3, H4, and H5 are processed.
  • the SQL statement (S1) related to the target HTTP request and the other SQL statements (S3, S4, S5) are processed.
  • the following shows the probability that the correlation between the HTTP request and the SQL sentence for period # 2 is correct.
  • the probability that the correlation of H1 ⁇ S1 is correct is 1/16
  • the probability that the correlation of H1 ⁇ S3 is correct is 1/16
  • the probability that the correct correlation H1 ⁇ S1 is obtained is 1/4, and a value larger than that in the period # 2 can be obtained. It can also be seen that the amount of calculation is less than that of period # 2.
  • this calculation method also reinforces incorrect correlation. For example, in the example of period # 1, the probability 1/4 of the incorrect correlation H1 ⁇ S2 is reflected in the calculation result. If the period # 3 in which the same HTTP requests H1 and H2 as the period # 1 are measured is used for the correlation calculation, the incorrect correlation of H1 ⁇ S2 is further strengthened. To avoid this, the following method is added.
  • the period used for correlation calculation is as follows.
  • the x mark at the left end indicates a period not used for correlation calculation.
  • Period # 1 (H1, H2) ⁇ Period # 2: (H1, H3, H4, H5) ⁇ Period # 3: (H1, H2) Period # 4: (H1, H6)
  • period # 2 is excluded by method 1 because there are many disturbance HTTP requests.
  • period # 3 is excluded by the method 2 because the disturbance HTTP request is the same as the period # 1. Therefore, the method of the present embodiment selects a period so that the number of HTTP requests other than the target HTTP request H1 is small and the types of disturbance HTTP requests are not uniform. As a result, the correlation between the HTTP request H1 and the SQL statement correlated with the HTTP request H1 can be easily and efficiently expressed.
  • FIG. 2 is a system configuration diagram of the monitoring system according to the first embodiment.
  • the network system 1 includes a monitoring computer 10 and a computer system 95 that is a monitoring target thereof.
  • Each component (described later) of the monitoring computer 10 and the computer system 95 is connected by a LAN (Local Area Network) 90, for example.
  • LAN Local Area Network
  • the monitoring computer 10 includes a processor 11, a memory 12, a display I / F 14, and a network (NW) I / F 16.
  • the processor 11 executes the HTTP monitoring program 80, the SQL statement monitoring program 81, and the SQL statement specifying program 82 stored in the memory 12. Further, the memory 12 stores an HTTP monitoring data table 20, an SQL monitoring data table 30, and a monitoring setting table 40 that are read and written by each program.
  • the display I / F 14 is connected to the display device 15. A screen for each program to perform input / output with the operation manager is displayed on the display device 15 via the display I / F.
  • the NWI / F 16 is connected to the LAN 90. Each program communicates with the components of the computer system 95 via the NWI / F 16.
  • the computer system 95 includes a switch 92, a Web / AP server 93, and a database (DB) server 94.
  • the switch 92, the Web / AP server 93, and the DB server 94 are connected to the LAN 90 and communicate with each other.
  • the Web / AP server 93 is either a Web server or an application server, or a server having both functions.
  • the terminal 91 transmits an HTTP request to the computer system 95 using a browser.
  • the HTTP request passes through the switch 92 and is processed in the order of the Web / AP server 93 and the DB server 94.
  • the processed result is returned to the browser used by the terminal 91 through the switch 92 again.
  • the HTTP monitoring program 80 captures a packet passing through the switch 92 and measures the response time of the HTTP request (details will be described later). The measurement result is stored in the HTTP monitoring data table 20.
  • the SQL statement monitoring program 81 periodically monitors the performance of the SQL statement executed by the DB server 94 at a certain monitoring interval.
  • the monitoring result is stored in the SQL monitoring data table 30.
  • the SQL statement specifying program 82 interacts with the operation manager and supports the narrowing down of the SQL statement that causes the delayed HTTP request.
  • FIG. 3 is an explanatory diagram showing an example of stored contents of the HTTP monitoring data table 20 shown in FIG.
  • the HTTP monitoring data table 20 is a table that records information related to HTTP requests measured by the HTTP monitoring program 80.
  • Each entry 28 (28a to 28l,...) Of the HTTP monitoring data table 20 includes the following information 21 to 27 measured by the HTTP monitoring program 80.
  • the HTTP request identifier 21 is a unique identifier assigned to each HTTP request.
  • the processing host-specific HTTP request execution count 22 is a value obtained by counting the number of HTTP requests executed simultaneously during the HTTP request processing for each processing host 23.
  • the processing host 23 is host information of the Web / AP server 93 to which the HTTP request is transmitted.
  • the HTTP request type identifier 24 is a unique identifier of the type of the HTTP request.
  • the HTTP request type identifier 24 may be a URI (Uniform Resource Identifier) of the HTTP request, a part of the URI, or a hash value generated based on the URI. In FIG. 3, for the sake of simplicity, notations such as H1 and H2 are used.
  • the start time 25 is the time when the processing of the HTTP request is started in the computer system 95. For example, it is the time when the HTTP monitoring program 80 captures the HTTP request.
  • the end time 26 is the time when the HTTP request has been processed by the computer system 95. For example, it is the time when the HTTP monitoring program 80 captures the response message in which the HTTP request is processed by the computer system 95.
  • the threshold excess 27 is a flag indicating whether or not the response time of the HTTP request obtained by subtracting the start time 25 from the end time 26 exceeds a predetermined threshold.
  • Y is recorded when the number is exceeded
  • N is recorded when the number is not exceeded.
  • the threshold value may be a static constant threshold value, or may be a dynamic threshold value based on baseline monitoring described later in a third embodiment described later.
  • FIG. 4 is an explanatory diagram showing an example of the stored contents of the SQL monitoring data table 30.
  • the SQL monitoring data table 30 is a table that records information about the SQL sentence measured by the monitoring computer 10. Each entry 39 (39a to 39l,%) Of the SQL monitoring data table 30 includes information 31 to 38 relating to individual SQL statements requested to be executed from the Web / AP server 93 to the DB server 94, measured by the monitoring computer 10. .
  • the SQL identifier 31 is a unique identifier representing the type of the SQL.
  • the SQL identifier 31 may be an SQL statement that is actually requested to be executed, a part of the SQL statement, or a hash value generated based on the SQL statement.
  • the start time 31 is the time when the SQL processing is started.
  • the end time 33 is the time when the SQL processing is ended.
  • the request source host 34 is host information of the Web / AP server 93 that has requested execution of the SQL statement.
  • the transaction ID 35 is an identifier of a transaction given by the DB server 94 to which the SQL statement belongs (more specifically, a DBMS operating on the DB server 94).
  • the same transaction ID 35 is assigned to the SQL statements belonging to the same transaction. Since the transaction ID 35 is not assigned to all SQL statements, the transaction ID 35 may be blank.
  • the processor time 36, the I / O waiting time 37, and the lock waiting time 38 are breakdown times of the processing time of the SQL statement. Depending on the DBMS, the time information may not be measured. In addition to these times, time information indicating a breakdown of the processing time of the SQL sentence may be stored in the SQL monitoring data table 30.
  • FIG. 5 is an explanatory diagram showing an example of the stored contents of the monitoring setting table 40.
  • the monitoring setting table 40 is a table for recording monitoring setting information for each computer system 95.
  • the HTTP monitoring program 80 and the SQL statement monitoring program 81 monitor the computer system 95 according to the monitoring setting information from the monitoring setting table 40.
  • One monitoring setting information is recorded in each entry of the monitoring setting table 40.
  • the system 41 is information indicating the computer system 95 to which the monitoring setting information recorded in the entry is applied.
  • the monitoring setting information is applied to “System A”.
  • the monitoring target 42 is a monitoring target of the monitoring setting information (HTTP request or DBMS, or although not shown, the processor usage rate of the server). In the case of “System A”, the HTTP request and the DBMS are monitored.
  • monitoring property 43 is information indicating the property name and its value of the monitoring setting information.
  • the monitoring properties include a monitoring interval and a monitoring target.
  • FIG. 5 it is specified that all HTTP requests of the system A are monitored in real time, and that SQL statements requested to be executed by the DBMS are monitored at intervals of 1 second.
  • FIG. 6 is a flowchart showing an example of an operation processing procedure of the HTTP monitoring program 80.
  • the HTTP monitoring program 80 measures the response time of the HTTP request processed by the computer system 95 and stores the result in the HTTP monitoring data table 20.
  • the HTTP monitoring program 80 captures an HTTP request packet transmitted from the terminal 91 to the Web / AP server 93 (step S601).
  • the HTTP request transmitted from the terminal 91 is sent to the Web / AP server 93 by the switch 92.
  • the switch 92 duplicates the packet and sends it to the mirror port.
  • the HTTP monitoring program 80 captures the copied packet from the NWI / F 16. In this case, the HTTP monitoring program 80 records the captured HTTP request in the memory 12 in order to calculate a response time and the like together with a response message to the HTTP request.
  • the HTTP monitoring program 80 captures a response message packet returned by the computer system 95 in response to the HTTP request requested by the terminal 91 (step S602).
  • the HTTP request requested by the terminal 91 is processed by the Web / AP server 93 and the DB server 94, and a response message is generated.
  • the response message is transmitted from the Web / AP server 93 to the terminal 91.
  • the response message also passes through the switch 92.
  • the HTTP monitoring program 80 captures a response message packet, as in step S601.
  • the HTTP monitoring program 80 calculates the response time of the HTTP request (step S603).
  • the HTTP monitoring program 80 calculates the difference between the measurement times of the HTTP request packet temporarily recorded in step S601 and the response message acquired in step S602 as the response time of the HTTP request.
  • the HTTP monitoring program 80 calculates the number of HTTP requests that have been processed in parallel at that time, that is, the number of HTTP requests simultaneously executed by each processing host (step S604).
  • the HTTP monitoring program 80 groups the HTTP requests recorded in the temporary storage area in step S601 for each transmission destination host acquired from the header of the HTTP request, and calculates the number as the HTTP request simultaneous execution number for each processing host. .
  • Another method may be used to calculate the HTTP request concurrent execution count.
  • the HTTP monitoring program 80 obtains the maximum number of HTTP requests recorded in the temporary storage area for a certain period (for example, 1 second) as the number of HTTP request simultaneous executions, and this number is calculated for all the requests processed during this period. It is good also as the HTTP request simultaneous execution number of an HTTP request.
  • the HTTP monitoring program 80 adds a new entry to the HTTP monitoring data table 20 and records the HTTP request data (step S605).
  • the HTTP monitoring program 80 generates a unique identifier in the HTTP monitoring data table 20 when a new entry is created, and records it as the HTTP request identifier 21. Further, the HTTP monitoring program 80 stores the value calculated in step S604 in the HTTP request simultaneous execution count 22 for each processing host.
  • the HTTP monitoring program 80 acquires the transmission destination host and URL from the header of the HTTP request saved in the temporary storage area in step S601, and records them as the processing host 23 and the HTTP request type identifier 24, respectively.
  • the HTTP request type identifier 24 may be a URL as it is, or another identifier generated based on the URL.
  • the HTTP monitoring program 80 records the time when the HTTP request is captured in step S601 as the start time 25, and the time when the response message is captured in step S602 as the end time 26. If a threshold value is provided for the response time, the HTTP monitoring program 80 sets the threshold value excess 27 to “+” if the response time obtained in step S3 exceeds the threshold value. If “Y” is not exceeded, “N” is recorded.
  • the SQL statement monitoring program 81 requests acquisition of monitoring data from the DB server 94 at a certain monitoring interval.
  • the SQL statement monitoring program 81 reads the entry 44 c of the monitoring setting table 40. Therefore, the monitoring interval is stored in the monitoring setting table 40 shown in FIG.
  • the DB server 94 for which the monitoring data is requested returns information related to the SQL statement operating at the time of the request to the SQL statement monitoring program 81.
  • the SQL statement monitoring program 81 stores the acquired information in the SQL monitoring data table 30.
  • FIG. 7 is an explanatory diagram showing an example of a screen displayed on the display device 15 by the SQL sentence specifying program 82.
  • the operation manager operates this screen and designates a delayed HTTP request for which the cause SQL statement is desired to be specified.
  • the SQL statement specifying program 82 specifies a cause SQL statement cause of the designated delayed HTTP request and displays the result on the screen.
  • the screen example in Fig. 7 consists of two upper and lower panes.
  • the upper pane displays a delayed HTTP request list 100.
  • the SQL statement specifying program 82 refers to the HTTP monitoring data table, obtains an entry whose threshold value excess 27 is “Y”, and stores each entry in the entry 101 (101a to 101c) of the delayed HTTP request list 100 on the screen. indicate.
  • the operation manager determines an entry for which the cause SQL statement is to be specified from the displayed entry 101 and checks the check box 102. In the screen example of FIG. 7, the entry 101a is checked.
  • the SQL statement specifying program 82 receives a delayed HTTP request (hereinafter simply referred to as “investigation target”) checked by the operation manager, and narrows down the cause SQL statement to a small number of candidates.
  • This narrowing-down process corresponds to the flowchart of FIG.
  • the lower pane of the screen displays the cause SQL list 103 narrowed down by the SQL statement specifying program 82.
  • a cause SQL entry 104 is displayed in each line of the cause SQL list 103.
  • Each cause SQL entry 104 includes a rating 105 indicating the likelihood that the SQL statement is the cause.
  • the operation manager recognizes the cause SQL sentence causing the delay with reference to the rating 105.
  • FIG. 8 is a flowchart showing an example of a processing procedure performed by the SQL sentence specifying program 82.
  • the SQL statement specifying program 82 waits for the operation manager to specify an HTTP request on the screen (step S801: No).
  • the SQL statement specifying program 82 acquires information on the specified investigation target (step S802). ).
  • the type of the survey target is “H1”.
  • the SQL statement specifying program 82 checks whether or not there is a strong correlation between the delay to be investigated and the HTTP request simultaneous execution count for each processing host (step S802).
  • the presence or absence of strong correlation may use a general correlation calculation method.
  • the SQL statement specifying program 82 calculates a correlation coefficient between the period length of a period in which an HTTP request of the same type as that of the investigation target has been processed in the past and the number of simultaneous execution of HTTP requests for each processing host during the same period.
  • the period length of the period in which an HTTP request of the same type as the survey target has been processed in the past is a time obtained by subtracting the start time from the end time for the HTTP request of the same type as the survey target.
  • the SQL statement specifying program 82 may be a method of determining that there is a strong correlation when the calculated correlation coefficient exceeds a threshold value.
  • step S803 determines whether or not there is a strong correlation.
  • step S803: Yes the process proceeds to step S804, and when there is no strong correlation (step S803: No), the process proceeds to step S803. This is because the application of Method 1 is excluded when the effect of “Method 1: Select a period with few disturbance HTTP requests” is low.
  • Step S803 and S804 are optional, and the SQL statement specifying program 82 need not necessarily be executed.
  • step S803 If there is a strong correlation (step S803: Yes), the SQL statement specifying program 82 is an HTTP request of the same type as the investigation target (in this example, the HTTP request type identifier 24 is “H1”), and a threshold value. Obtained from the HTTP request monitoring data table 20 in which the excess 27 is “Y” (step S804). After step S804, the process proceeds to step S807.
  • step S803 when there is no strong correlation (step S803: No), the SQL statement specifying program 82 refers to the HTTP monitoring data table 20, and the HTTP request of the same type as the investigation target (in this example, the HTTP request type identifier 24 is “ H1 ") entries (hereinafter referred to as" same type HTTP requests ”) are acquired in ascending order of the number of simultaneous executions of HTTP requests 22 by processing host (step S805).
  • the SQL statement specifying program 82 acquires the entries 28a, 28c, 28e, 28i, and 28k whose HTTP request type identifier is “H1”.
  • the entries to be acquired include, for example, the entries up to the top X in order of decreasing HTTP request simultaneous execution number 22 for each processing host, and entries whose value of HTTP request simultaneous execution number 22 for each processing host is a predetermined number or less.
  • step S806 the SQL statement specifying program 82 executes entry deletion processing.
  • the combination of disturbance HTTP requests is the same from the set of HTTP requests of the same type acquired in step S805 in accordance with the above-described method 2: “Make disturbance HTTP request types irregular”. This is a process of deleting an entry.
  • the SQL statement specifying program 82 processes an HTTP request (disturbance HTTP request) entry that has been processed in the same period as the HTTP request of the same type acquired in step S805 and has the same processing host 23 as HTTP. Obtained from the monitoring data table 20. As a result, a “set” of the HTTP request of the same type as the investigation target and the acquired disturbance HTTP request is formed.
  • the entry 28a of the same type HTTP request acquired in step S805 is taken as an example. Assuming that the processing period of the entry 28a (4: 00: 00.000 to 4: 00: 00.000) is the period # 1, the HTTP request entry 28b processed in the period # 1 is acquired as a disturbance HTTP request. .
  • the HTTP request type identifier of the entry 28b is “H2”.
  • period # 1 a set of (H1, H2) is formed.
  • a set of (H1, H3, H4, H5) is formed, and if entry 28i is taken as an example, period # 3 (1 (Hour 0 minute 0 second .000 to 1 hour 0 minute 5 second .000), a set of (H1, H2) is formed.
  • a set of (H1, H6) is formed in the period # 4 (0 hour 0 minute 0 second .000 to 0 hour 0 minute 5 second .000).
  • the SQL statement specifying program 82 compares the types of disturbance HTTP requests of each set, and specifies a set having the same combination of disturbance HTTP requests. Then, when there are a plurality of the same pairs, the SQL statement specifying program 82 leaves only one and deletes the other pairs. For example, since the set of period # 1 (H1, H2) matches the set of period # 3 (H1, H2), the SQL statement specifying program 82, for example, sets the set of period # 3 (H1, H2). delete.
  • the same determination of the combination of disturbance HTTP request types may be complete match or partial match. For example, if half of the disturbance HTTP requests are duplicated, it may be determined that they are the same. For example, when a set (H1, H2, H3) exists in a certain period, it partially matches the set (H1, H2) of period # 1. In this case, in the group (H1, H2, H3), H2 which is half of the disturbance requests H2 and H3 overlaps, so the SQL statement specifying program 82 deletes the group (H1, H2, H3).
  • the SQL statement specifying program 82 acquires a paired SQL entry from the SQL monitoring data table 30 for each HTTP request remaining after the entry deletion process (step S806) (step S807). That is, the SQL statement specifying program 82 is processed in the same period as the entry of the HTTP request remaining after the entry deletion process (step S806), and the HTTP request processing host 23 makes a request for the SQL monitoring data table 30. The same SQL entry 39 as that of the original host 34 is acquired.
  • step S804 is executed, the SQL statement specifying program 82 acquires a paired SQL entry from the SQL monitoring data table 30 for each HTTP request acquired in step S804 (step S804). S807).
  • the SQL statement specifying program 82 filters the SQL entry obtained in step S807 using the transaction ID 35 of the SQL monitoring data table 30 (step S808). That is, the SQL statement specifying program 82 obtains the transaction ID 35 of each SQL entry acquired in step S807, and checks whether another entry having the same transaction ID exists in the SQL monitoring data table 30. If such an entry exists, it means that the transaction having the transaction ID 35 has been processed before the processing of the same type HTTP request is started. Therefore, the SQL entry 39 having the same transaction ID 35 may be excluded. Note that step S808 is optional and not an essential step.
  • the SQL statement specifying program 82 deletes the SQL statement whose processing time is less than the predetermined time and removes it from the correlation calculation target after step S810 (step S809).
  • the SQL statement specifying program 82 may exclude the SQL entry 39 whose processing time is less than a certain time, or exclude the SQL entry less than the monitoring interval for monitoring the SQL statement with reference to the monitoring setting table 40. Also good.
  • SQL entries other than the SQL entry 39 processed in synchronization with the investigation target designated by the operation manager in step S802 may be excluded.
  • the SQL statement specifying program 82 calculates a correlation value between the HTTP request and the SQL statement (step S810).
  • the co-correlation probability between the HTTP request and the SQL sentence is calculated as in the correlation probability calculation method shown in FIG.
  • the calculation procedure follows a general correlation probability calculation method.
  • the SQL statement specifying program 82 displays the SQL statement having a large correlation value between the HTTP request and the SQL statement in the cause SQL list 103 of FIG. 7 as a delay cause candidate.
  • a high rating 105 is assigned to the SQL sentence having a large correlation value as an index for helping the operation manager understand. Any method may be used for calculating the rating 105. For example, a method may be used in which correlation values having a value range from 0 to 1 are divided into 0.2 values, and five levels of ratings are assigned in order from the smallest value.
  • the operation manager can immediately recognize that the SQL sentence given the high rating 105 is highly likely to cause the HTTP request delay. Thereby, the operation manager can efficiently narrow down the cause SQL sentence candidates of the delayed HTTP request.
  • FIG. 9 is a flowchart showing a detailed processing procedure example of the entry deletion processing (step S806) shown in FIG.
  • the SQL statement specifying program 82 determines whether or not there is an unselected entry among the entry group obtained in step S805 (step S901). If there is an unselected entry (step S901: Yes), the SQL statement specifying program 82 selects one unselected entry (step S902). Then, the SQL statement specifying program 82 acquires a disturbance HTTP request entry processed within the processing period of the selected entry (step S903), and generates a pair such as (H1, H2) described above (step S904). ). Then, the process returns to step S901.
  • step S901 determines whether there is an unselected pair among the pairs generated in step S904 (step S905). . When there is an unselected pair (step S905: Yes), the SQL statement specifying program 82 selects a pair with the smallest number of disturbance HTTP requests (step S906).
  • step S907 determines whether there is a set that matches the selected set. If there is a set (step S907: Yes), the matched set is deleted (step S908). The process returns to step S904. When there is no matching pair (step S907: No), the process returns to step S905. In step S905, when there is no unselected pair (step S905: No), the SQL statement specifying program 82 ends the entry deletion process (step S806), and proceeds to step S807.
  • the number of HTTP requests used for identifying the cause of the failure can be suppressed by selecting a period with a small number of disturbance HTTP requests. Thereby, the amount of calculation can be reduced.
  • the types of disturbance HTTP requests uneven, the number of HTTP requests used for identifying the cause of the failure can be suppressed. Thereby, the amount of calculation can be reduced.
  • the types of disturbance HTTP requests uneven it is possible to suppress the strengthening of incorrect correlation and to improve the narrowing accuracy of SQL sentences that are candidates for the cause of HTTP requests that show a delay in processing performance. .
  • Example 2 Example 2 Next, Example 2 will be described.
  • the SQL statement specifying program 82 executes the SQL statement specifying process after receiving the SQL statement specifying request from the operation manager. That is, the SQL sentence specifying process is performed on demand.
  • the SQL statement specifying program 82 executes the SQL statement specifying process in the background in advance.
  • the SQL statement specifying program 82 is started periodically.
  • the SQL statement specifying program 82 executes an SQL statement specifying process for an HTTP request added after the previous activation (hereinafter, “added HTTP request”).
  • the SQL statement specifying program 82 processes only the difference from the previous time.
  • the operation manager requests the SQL sentence specifying process
  • the SQL sentence that is a cause candidate can be immediately output.
  • the same configurations and the same processes as those of the first embodiment are denoted by the same reference numerals, and the description thereof is omitted.
  • FIG. 10 is a system configuration diagram of the network system 1 according to the second embodiment. The difference from the first embodiment is that the calculated HTTP combination table 50 and the HTTP-SQL tabulation table 60 are added to the memory 12, and the contents of the operation flow of the SQL statement specifying program 82.
  • the SQL statement specifying program 82 calculates the correlation between the HTTP request and the SQL statement, and updates the HTTP-SQL tabulation table 60. At this time, the SQL statement specifying program 82 records in the calculated HTTP combination table 50 the combinations of disturbance HTTP requests that have been processed in parallel during the period used for the correlation calculation. The SQL statement specifying program 82 refers to the record of the calculated HTTP combination table 50 before performing the correlation calculation, and deletes the same combination of disturbance HTTP requests by the technique 2.
  • FIG. 11 is an explanatory diagram of an example of stored contents of a table used in the network system 1 according to the second embodiment.
  • 11A shows an example of the stored contents of the calculated HTTP combination table 50.
  • the calculated HTTP combination table 50 records the disturbance HTTP request identifier, its type, and the number of HTTP request simultaneous executions for each HTTP request type identifier 51 to be investigated. For example, it is assumed that the HTTP request type for which the correspondence relationship with the SQL statement is to be obtained is “H1” and one HTTP request “H1” is measured in the state where there is no entry in the calculated HTTP combination table 50.
  • an entry 55a is created in the calculated HTTP combination table 50. That is, the HTTP request type identifier 51 indicating the type of the HTTP request whose correspondence is to be obtained is “H1”, the HTTP request simultaneous execution number 53 for each processing host is “1”, that is, the HTTP request processed during the synchronization, Since there is no disturbance HTTP request, “(null)” is recorded as the disturbance HTTP request type.
  • the HTTP request identifier 52 is a unique identifier of the HTTP request “H1”, and is the same data as the HTTP request identifier 21 of the HTTP monitoring data table 20.
  • the type of the HTTP request (request identifier is “100”) whose correspondence with the SQL statement is to be obtained is “H1”, and there is one HTTP request having the type “H2” in synchronization with “H1”.
  • an entry 55b is created in the calculated HTTP combination table 50. That is, an entry is created in which the HTTP request type identifier 51 is “H1”, the HTTP request identifier 52 is “100”, the HTTP request simultaneous execution number 53 for each processing host is “2”, and the disturbance HTTP request type 54 is “H2”.
  • FIG. 11B shows an example of stored contents of the HTTP-SQL tabulation table 60.
  • the HTTP-SQL tabulation table 60 stores, for each HTTP request type identifier 61, the number of appearances 63 of the SQL statement type (SQL identifier 62) measured during the HTTP request processing period. For example, if an SQL statement with an SQL identifier “S1” is measured 30 times during the processing period of an HTTP request with an HTTP request type identifier “H1”, an entry 64a is created in the HTTP-SQL tabulation table 60. Is done. Similarly, when “S2” is measured 3 times and “S3” is measured 6 times, entries 64b and 64c are created in the HTTP-SQL tabulation table 60, respectively.
  • FIG. 12 is a flowchart of a detailed processing procedure example of the SQL statement specifying process by the SQL statement specifying program 82 according to the second embodiment.
  • the SQL statement specifying program 82 is periodically started.
  • the SQL statement specifying program 82 refers to the HTTP monitoring data table to determine whether or not there is an unselected additional HTTP request (step S1201). ).
  • step S1201 When there is an unselected additional HTTP request (step S1201: Yes), the SQL statement specifying program 82 selects one unselected additional HTTP request (step S1202), and the entry of the selected additional HTTP request is HTTP monitored. Obtained from the data table (step S1203). For example, when the HTTP request type identifier 24 of the selected addition HTTP request is “H1”, the SQL statement specifying program 82 selects the HTTP request whose HTTP request type identifier 24 is “H1” in the HTTP monitoring data table, and The entries 55a, 55b, 55c, 55d, 55e,... Of the selected HTTP request are acquired.
  • the HTTP-SQL tabulation table update process (step S1204) is a process for executing the process according to the above-described technique 1 and technique 2 in the background for the selected addition HTTP request, and details will be described later with reference to FIG. After the HTTP-SQL tabulation table update process (step S1204), the process returns to step S1201.
  • step S1201 No
  • the SQL statement specifying program 82 ends the process.
  • the SQL statement specifying process can be executed in the background for each additional HTTP request.
  • FIG. 13 is a flowchart (first half) showing a detailed processing procedure example of the HTTP-SQL tabulation table update process (step S1204) shown in FIG.
  • the SQL statement specifying program 82 counts the number of entries (the number of entries) having the same type as the selected and added HTTP request and the HTTP request type identifier 51 from the calculated HTTP combination table 50 (step S1301). .
  • the SQL statement specifying program 82 includes entries 55a, 55b in which the HTTP request type identifier 51 is “H1” in the calculated HTTP combination table 5050.
  • the number of entries is the number of HTTP requests simultaneously executed for each processing host of the selective addition HTTP request.
  • the SQL statement specifying program 82 determines whether or not the HTTP host simultaneous execution count for each processing host, which is the counted number of entries, is equal to or greater than a threshold value. If it is equal to or greater than the threshold value (step S1302: Yes), the SQL statement specifying program 82 executes steps S1303 to S1308. If it is less than the threshold value (step S1302: No), the process proceeds to step S1309.
  • Steps S1301 and S1302 are processes for determining whether sufficient data has already been recorded for calculating the relationship of the selective addition HTTP request. If there is a threshold value or more (step S1302: Yes), a process for determining whether or not the selected addition HTTP request obtained this time is more useful than the existing HTTP request is executed (steps S1303 to S1308). Steps S1301 and S1302 are optional and may be omitted.
  • the SQL statement specifying program 82 refers to the already-calculated HTTP combination table 50, acquires the HTTP request simultaneous execution number 53 for each processing host for each HTTP request of the same type as the selected addition HTTP request, From this, the maximum execution number M is specified (step S1304).
  • step S1305 if the HTTP request simultaneous execution number N per host for the processing of the selection addition HTTP request is equal to or less than the maximum execution number M (step S1305: No), the HTTP-SQL tabulation table update process for the selection addition HTTP request (step S1204). And the process returns to step S1201 of FIG. In other words, cases where the number of HTTP requests simultaneously executed by the processing host is equal to or less than the past are excluded. As a result, an unselected additional HTTP request is selected, and an HTTP-SQL tabulation table update process (step S1204) is executed.
  • step S1306 the SQL statement specifying program 82 acquires from the HTTP monitoring data table 20 the disturbance HTTP request that has been executed in parallel with the selected addition HTTP request (step S1306). Specifically, for example, the SQL statement specifying program 82 reads the HTTP request entry (disturbance) from the HTTP monitoring data table 20 during the processing period of the selective addition HTTP request (the period from the start time 25 to the end time 26). HTTP request).
  • the SQL statement specifying program 82 reads the HTTP request entry (disturbance) from the HTTP monitoring data table 20 during the processing period of the selective addition HTTP request (the period from the start time 25 to the end time 26). HTTP request).
  • the processing period is the start time: 2: 00: 0. 000 to end time: 2: 00: 5.
  • the period is up to 000.
  • the SQL statement specifying program 82 acquires the disturbance HTTP requests H3 to H5 that are the entries 28f, 28g, and 28h having the same processing period as the processing period of the entry 28e.
  • the processing period of the disturbance HTTP request includes the processing period of the selective addition HTTP request. It may also be included.
  • the SQL statement specifying program 82 acquires the disturbance HTTP request of the selected addition HTTP request from the calculated HTTP combination table 50 (step S1307). For example, when the HTTP request type identifier 24 of the selected addition HTTP request is “H1”, the SQL statement specifying program 82 specifies the entries 55 a to 55 e of the same type “H1” from the calculated HTTP combination table 50. Then, the SQL statement specifying program 82 acquires H2, H3, H4, H5, H6, and H7 recorded in the disturbance HTTP request type 54 of the entries 55a to 55e.
  • the SQL statement specifying program 82 follows whether or not the disturbance HTTP request acquired in step S1306 and the disturbance HTTP request acquired in step S1307 overlap according to “Method 2: Make the types of disturbance HTTP requests uneven”. Is determined (step S1307). Specifically, the SQL statement specifying program 82 determines whether or not the HTTP request type identifier 24 of the disturbance HTTP request overlaps with the disturbance HTTP request type 54.
  • the disturbance HTTP request acquired in step S1306 is H3 to H5
  • the disturbance HTTP request acquired in step S1307 is H2 to H7. Therefore, the disturbance HTTP requests H3 to H5 are duplicated. Note that the overlap in step S1307 may be complete match or partial match. For example, if half of the disturbance HTTP requests match, it may be determined that there is duplication.
  • step S1308 If they overlap (step S1308: Yes), the HTTP-SQL tabulation table update process (step S1204) for the selected addition HTTP request is terminated, and the process returns to step S1201 in FIG. As a result, an unselected additional HTTP request is selected, and an HTTP-SQL tabulation table update process (step S1204) is executed.
  • step S1305 when there is no duplication (step S1305: No), the process proceeds to step S1309. Thereby, the selection addition HTTP request can be evaluated with respect to the newly added disturbance HTTP request which is not duplicated.
  • the SQL statement specifying program 82 adds an entry of the HTTP request to the calculated HTTP combination table 50 (step S1309). Specifically, for example, when Step S1308: No is executed, the SQL statement specifying program 82 adds entries of the selection addition HTTP request and the disturbance HTTP request acquired in Step S1306. As a result, a new disturbance HTTP request is registered in the calculated HTTP combination table 50.
  • step S1302 No, the SQL statement specifying program 82 adds an entry of the selection addition HTTP request.
  • the disturbance HTTP request type 54 of the entry is (null).
  • the SQL sentence specifying program 82 executes the first update process (step S1309).
  • the SQL statement specifying program 82 executes an update for adding an entry to the HTTP-SQL tabulation table 60.
  • the SQL statement specifying program 82 has, for the HTTP-SQL tabulation table 60, an entry having a selection addition HTTP request, an SQL statement processed during the processing period, and the number of appearances of the SQL statement. Add a new. If the SQL statement specifying program 82 has been added, the number of appearances is updated. Details of the first update process (step S1310) will be described later with reference to FIG. After the first update process (step S1310), the process proceeds to step S1401 in FIG.
  • FIG. 14 is a flowchart (second half) showing a detailed processing procedure example of the HTTP-SQL tabulation table update process (step S1204) shown in FIG.
  • the SQL statement specifying program 82 is again the same as the selected addition HTTP request from the calculated HTTP combination table 50, similarly to step S1301 of FIG.
  • the number of HTTP requests simultaneously executed by processing host which is the number of entries of the type, is counted (step S1401). Since an entry is added in step S1309, the latest HTTP request simultaneous execution count for each processing host is obtained as compared with step S1301.
  • step S1402 determines whether or not the HTTP request simultaneous execution count for each processing host, which is the counted number of entries, is equal to or greater than a threshold value (step S1402).
  • This threshold value is the same threshold value as in step S1302.
  • the process of step S1402 is a process of determining whether or not a sufficient number of entries (the number of HTTP requests for each processing host simultaneously executed) has been obtained by adding an entry to the calculated HTTP combination table 50 in step S1309. is there.
  • the SQL statement specifying program 82 executes steps S1403 and S1404. Delete the extra entry.
  • step S1402 determines whether it is less than the threshold value (step S1402: No). If it is less than the threshold value (step S1402: No), the HTTP-SQL tabulation table update process (step S1204) for the selected addition HTTP request is terminated, and the process returns to step S1201 in FIG. As a result, an unselected additional HTTP request is selected, and an HTTP-SQL tabulation table update process (step S1204) is executed.
  • step S1403 the SQL statement specifying program 82 deletes the entry corresponding to the deletion condition from the calculated HTTP combination table 50 in accordance with “Method 1: Select a period with few disturbance HTTP requests” (step S1403). For example, if the selected addition HTTP request is the entry 28e in FIG. 3, the HTTP request type identifier 24 is “H1”, and therefore, the HTTP request entry whose HTTP type identifier 51 is “H1” in the calculated HTTP combination table 50. Of 55a to 55e, the entry corresponding to the deletion condition is deleted.
  • the deletion condition is, for example, that the HTTP request simultaneous execution number 53 for each processing host is equal to or greater than a threshold value.
  • a threshold value As a result, the number of HTTP requests used can be suppressed, and the calculation load can be reduced.
  • deletion condition may be that the processing period is equal to or less than the threshold value, not the old entry as described above. This is because if the processing time is long, there is a high possibility of obtaining relationships with more SQL statements.
  • step S1404 the SQL statement specifying program 82 executes the second update process.
  • step S1404 the SQL statement specifying program 82 executes an update that deletes the addition by the entry deleted in step S1403 from the HTTP-SQL tabulation table 60. Details of the second update process (step S1404) will be described later with reference to FIG.
  • step S1404 After the second update process (step S1404), the HTTP-SQL tabulation table update process (step S1204) for the selective addition HTTP request is terminated, and the process returns to step S1201 in FIG. As a result, an unselected additional HTTP request is selected, and an HTTP-SQL tabulation table update process (step S1204) is executed.
  • FIG. 15 is a flowchart showing a detailed processing procedure example of the first update processing (step S1310) shown in FIG.
  • the SQL statement specifying program 82 acquires, from the SQL monitoring data table, the entry of the SQL statement that was being executed during the processing period of the selective addition HTTP request (step S1501).
  • the selected addition HTTP request is the entry 28e in FIG. 3, the SQL executed during the processing period of the entry 28e (2: 0: 0.000 to 2: 0: 5.000)
  • the sentence entries 39e to 39h are acquired from the SQL monitoring data table 30.
  • the processing period of the SQL statement is included in the processing period of the selective addition HTTP request, when the part overlaps, or the processing period of the SQL sentence includes the processing period of the selective addition HTTP request May also be included.
  • the SQL statement specifying program 82 determines whether or not there is a SQL identifier 31 of an unselected entry in the entry group acquired in step S1501 (step S1502). When there is an SQL identifier 31 of an unselected entry (step S1502: Yes), the SQL statement specifying program 82 selects an SQL identifier 31 of an unselected entry (step S1503).
  • the SQL statement specifying program 82 calculates the number of entries having the selected SQL identifier 31 by counting the entry group acquired in step S1501 for each SQL identifier (hereinafter, selected SQL identifier) 31 of the selected entry ( Step S1504).
  • the number of entries calculated in step S1504 is referred to as “SQL appearance number”.
  • the SQL statement specifying program 82 from the HTTP-SQL tabulation table 60, the HTTP request type identifier 61 is the HTTP request type identifier of the selected additional HTTP request, and the SQL identifier 62 is the selected SQL identifier 31.
  • a matching entry is specified (step S1505).
  • the SQL statement specifying program 82 specifies the entry 64a from the HTTP-SQL tabulation table 60. If there is no entry that matches the selected SQL identifier 31, the SQL statement specifying program 82 newly creates an entry in the HTTP-SQL tabulation table 60.
  • step S1502 when there is no entry of an unselected SQL sentence (step S1502: No), the SQL sentence specifying program 82 ends the first update process (step S1310), and proceeds to step S1401 in FIG. As a result, the number of appearances of the SQL sentence processed within the processing period of the selective addition HTTP request (the number of SQL appearances) is sequentially updated.
  • FIG. 16 is a flowchart showing a detailed processing procedure example of the second update processing (step S1404) shown in FIG.
  • the second update process (step S1404) is a process for deleting from the HTTP-SQL tabulation table 60 the amount added by the entry deleted in step S140.
  • the first update process (step S1310) adds the SQL statement appearance count to the HTTP-SQL tabulation table 60
  • the second update process (step S1404) is a process of subtracting conversely. Therefore, steps S1601 to S1605 are the same as steps S1501 to S1505 in FIG.
  • step S1606 the SQL statement specifying program 82 subtracts the SQL statement appearance count calculated in step S1604 from the entry appearance count 63 specified in step S1605 and saves it (step S1606). Then, the process returns to step S1602. If there is no unselected entry in step S1602 (step S1602: No), the SQL statement specifying program 82 ends the second update process (step S1404) and returns to step S1201 in FIG. As a result, an unselected additional HTTP request is selected, and an HTTP-SQL tabulation table update process (step S1204) is executed.
  • step S1308 for each additional HTTP request, by making the types of disturbance HTTP requests uneven in the background, the enhancement of incorrect correlation is suppressed, and the HTTP request that shows a delay in processing performance Therefore, it is possible to improve the accuracy of narrowing down the SQL sentence that is the cause of the problem.
  • the latest state can be confirmed at that time by reading the HTTP-SQL tabulation table of FIG. 11 and displaying it on the screen.
  • Method 1 Select a period with few disturbance HTTP requests” is applied in step S1403 of FIG. 14. However, even if Method 1 is applied before the SQL statement specifying program 82 is started. Good.
  • the period during which the HTTP monitoring program 80 can easily identify the correspondence between the HTTP request and the SQL statement that is, the period during which the HTTP request processing host-specific execution number of the HTTP request described in the method 1 is equal to or less than a predetermined number.
  • the SQL statement specifying program 82 is activated.
  • FIG. 17 is a flowchart of an example of a detailed processing procedure for starting the SQL statement specifying program 82 by the HTTP monitoring program 80 according to the second embodiment.
  • the HTTP monitoring program 80 determines whether there is an unselected additional HTTP request (step S1701).
  • Step S1701 is determined, for example, in a cycle shorter than the startup cycle of the above-described SQL statement specifying program.
  • step S1701 When there is an unselected additional HTTP request (step S1701: Yes), the HTTP monitoring program 80 selects one unselected additional HTTP request from the HTTP monitoring data table (step S1702). Next, the HTTP monitoring program 80 acquires the HTTP request simultaneous execution count for each processing host of the selection addition HTTP request from the HTTP monitoring data table (step S1703). Then, the HTTP monitoring program 80 determines whether or not the HTTP request simultaneous execution count for each processing host acquired in step S1703 is equal to or less than a threshold value (step S1704).
  • Step S1705 If it is equal to or less than the threshold (step S1705: Yes), Method 1: Select a period with few disturbance HTTP requests.
  • the HTTP monitoring program 80 starts the SQL statement specifying program 82 (step S1705). In this case, Steps S1203 and 1204 in FIG. 12 are executed for the selective addition HTTP request in Step S1702.
  • step S1705 when the HTTP request simultaneous execution count for each processing host acquired in step S1703 is not less than or equal to the threshold value (step S1705: No), the process returns to step S1701. If there is no unselected HTTP request (step S1701: No), the startup process of the SQL statement specifying program 82 is terminated.
  • the HTTP request indicating a delay in the processing performance of the SQL statement specifying program 82. This makes it possible to improve the efficiency of narrowing down the SQL sentence that is the cause of the problem.
  • the SQL statement specifying program 82 is activated when the HTTP request simultaneous execution count for each processing host is equal to or less than the threshold value, the SQL statement specifying program 82 is executed only when necessary as compared with the case where it is periodically activated. Can be activated. Therefore, unauthorized SQL specifying processing can be reduced, and the calculation load of the monitoring computer can be reduced.
  • Example 3 Next, Example 3 will be described.
  • the period in which the relationship between the HTTP request and the SQL sentence is easily obtained is selected from the given monitoring data.
  • monitoring data that easily obtains the relationship is generated.
  • the SQL statement monitoring program 81 in the first and second embodiments can measure only a part of the SQL statement to the DB server 94. This is because if the SQL statement monitoring program 81 measures all SQL statements, the load on the DB server 94 due to the measurement cannot be ignored. For this reason, the SQL statement monitoring program 81 of the first and second embodiments measures the DB server 94 at a constant monitoring interval so as not to apply an excessive load to the DB server 94 by measurement. Since the processing time is limited to the SQL statement being processed at the time of measurement, the load applied to the DB server 94 is small, but the measured SQL statement is limited to a part.
  • the SQL statement monitoring program 81 dynamically changes the method of monitoring the DB server 94. As described above, the correspondence between the HTTP request and the SQL statement is likely to appear during a period when the number of HTTP requests is small.
  • the SQL statement monitoring program 81 according to the first embodiment switches between all SQL statement measurement and partial SQL statement measurement according to the number of HTTP requests.
  • FIG. 18 is a system configuration diagram of the network system 1 according to the third embodiment.
  • FIG. 18 shows a system configuration in which a baseline table 70 is added to the system configurations of the first and second embodiments.
  • FIG. 19 is an explanatory diagram showing an example of the contents stored in the baseline table 70 shown in FIG.
  • the baseline table 70 is a table for recording “normal behavior (baseline)” of the computer system 95 calculated from the records of the HTTP monitoring data table 20.
  • the baseline table 70 information indicating the type of the computer system 95 is recorded in the system 71.
  • the HTTP request count baseline 72 a baseline of the number of HTTP requests normally processed by the computer system 95 is recorded.
  • a general method may be used for creating the baseline.
  • the monitoring computer performs statistical processing on the record of the number of past HTTP requests recorded in the HTTP monitoring data table 20, and calculates and records the average number of HTTP requests by time (and its standard deviation).
  • FIG. 20 is a flowchart showing a detailed processing procedure example of the monitoring mode change processing procedure by the SQL statement monitoring program 81.
  • the SQL statement monitoring program 81 periodically changes the measurement mode according to this flowchart.
  • the SQL statement monitoring program 81 acquires the HTTP request count baseline 72 of the computer system 95 to be monitored from the baseline table 70 (step S2001).
  • the SQL statement monitoring program 81 identifies the number of HTTP requests at the current time for the HTTP request number baseline 72 acquired in step S2001, and compares the number of HTTP requests with a threshold value (step S2002). When it is less than the threshold (step S2002: Yes), the SQL statement monitoring program 81 changes the measurement mode of the SQL statement monitoring program 81 to the all SQL measurement mode (step S2003), and ends the processing.
  • the all SQL sentence measurement mode is a mode in which all SQL sentences are measured by the SQL sentence monitoring program 81. For example, in the case of a packet capture method, all captured packets are measured.
  • step S2002 determines whether it is equal to or greater than the threshold value in step S2002 (step S2002: Yes).
  • the regular measurement mode is a mode in which the SQL sentence monitoring program 81 measures the SQL sentence at predetermined time intervals such as one second intervals. Thereby, the SQL sentence to measure can be thinned out compared with all the SQL sentence measurement modes. Therefore, the SQL statement monitoring process can be executed according to the calculation load.
  • the SQL statement monitoring program 81 changes the measurement mode based on the past history (baseline). Normally, the entire SQL statement measurement mode in which a slight load on the DB server 94 is allowed is executed during a period when the number of HTTP requests is small, and the regular measurement mode where the load on the DB server 94 is low during other periods. Executed. As a result, a large number of SQL statements can be obtained in a period in which the number of HTTP requests in which the correspondence between HTTP requests and SQL statements can be easily obtained is small, and the efficiency of obtaining the correspondence can be improved.
  • step S2003 the cycle may be shorter than the measurement cycle of the regular measurement mode in step S2004.
  • step S2002 the number of HTTP requests is compared with a threshold value.
  • a plurality of threshold values may be prepared, and the measurement cycle of the measurement mode may be changed stepwise according to the threshold value.
  • the combination of the HTTP request and the SQL statement has been described.
  • the combination is not limited thereto.
  • an email may be applied instead of an HTTP request.
  • the present invention can be applied to the case where the data flow is observed by two different independent methods.
  • the configuration of the computer system 95 to be monitored is not limited to the configurations of FIG. 2, FIG. 10, and FIG.
  • the monitoring computer 10 receives the first request set received by the first device and the second request processed by the second device according to the request from the first device. And a request group of the same type that is the same type as the request to be investigated in the first request set is obtained from the first request set, and the request to be investigated and the same request set are obtained. For each request in the type request group, the first request is sent during the processing period from when the first device transmits the response to the second device until the response is transmitted from the second device to the first device. A request of another type different from the type of the request to be investigated is transmitted from the device to the second device and a response is transmitted from the second device to the first device.
  • the monitoring computer 10 receives the first request set received by the first device and the second device processed by the second device according to the request from the first device. 2, and a request group of the same type that is the same type as the request for investigation in the first request set is acquired from the first request set, and the request for investigation and the request set For each request of the same type request group, the first request is transmitted during the processing period from when the first device transmits the response to the second device until the response is transmitted from the second device to the first device.
  • a request of another type that is different from the type of the request to be investigated, which is transmitted from one device to the second device and a response is transmitted from the second device to the first device.
  • a list of requests from the first request set, and the number of requests of the other types acquired from the survey target request and the same type of request group is a predetermined number or more, or in a predetermined order in ascending order.
  • the following requests are deleted, and the second request processed by the second device during the processing period is changed to the second request set for each request of the investigation target request and the request of the same type after the deletion.
  • the correlation value with the acquired second request is calculated for each request of the investigation target request and the request of the same type after the deletion, and the calculation result is output.
  • the monitoring computer 10 receives the first request set received by the first device and the second device processed by the second device according to the request from the first device.
  • the first request to be added is selected, and the selected first addition request is transmitted from the first device to the second device and then from the second device to the first request.
  • the first addition in which a response is transmitted from the first device to the second device and a response is transmitted from the second device to the first device during a processing period until a response is transmitted to the device.
  • a request of another type different from the type of the target request is acquired from each of the first request set and the correspondence information, and the request of the other type acquired from the first request set and the request It is determined whether or not the other type of request acquired from the correspondence information overlaps. If there is no overlap, the correspondence information is acquired from the first addition target request and the first request set.
  • the second type of request added and the second addition target request processed by the second device during the processing period of the first addition target request and the second request The number of occurrences of the addition target request is identified from the second request set, and based on the number of occurrences of the first addition target request, the second addition target request, and the second addition target request, The count information is updated.
  • the monitoring computer 10 is processed by the second device according to the first request set received by the first device and the request from the first device.
  • the first device transmits a response from the first device to the second device and a response is transmitted from the second device to the first device during a processing period until a response is transmitted to the first device.
  • a request of another type different from the type of the additional target request is acquired from the first request set, and the correspondence information is specified from the first additional target request and the first request set.
  • the second type of request and the number of occurrences of the second addition target request which are processed by the second device during the processing period of the first addition target request, Are determined from the second set of requests, and based on the first addition target request, the second addition target request, and the number of occurrences of the second addition target request, Counting information is updated, and for the first addition target request added to the correspondence information, the number of requests of other types different from the type of the first addition target request is counted from the correspondence information. If the result is equal to or greater than a predetermined number, the first addition target request added to the correspondence information and the other type of request specified from the first request set are deleted from the correspondence information, and the count The count information is updated by subtracting the number of appearances from the information.

Landscapes

  • Engineering & Computer Science (AREA)
  • Theoretical Computer Science (AREA)
  • General Engineering & Computer Science (AREA)
  • Physics & Mathematics (AREA)
  • Quality & Reliability (AREA)
  • General Physics & Mathematics (AREA)
  • Computer Hardware Design (AREA)
  • Computer Networks & Wireless Communication (AREA)
  • Signal Processing (AREA)
  • Health & Medical Sciences (AREA)
  • Biomedical Technology (AREA)
  • Life Sciences & Earth Sciences (AREA)
  • Bioinformatics & Cheminformatics (AREA)
  • Bioinformatics & Computational Biology (AREA)
  • Evolutionary Biology (AREA)
  • Probability & Statistics with Applications (AREA)
  • Environmental & Geological Engineering (AREA)
  • Debugging And Monitoring (AREA)

Abstract

　独立して観測される複数のデータの対応関係を求める計算量の削減を図る。 特定装置は、調査対象リクエストおよび同種別リクエスト群の各リクエストについての処理期間中に第１の装置から前記第２の装置に送信され第２の装置から第１の装置にレスポンスが送信された調査対象リクエストの種別とは異なる他の種別のリクエストを取得し、取得された前記他の種別のリクエストとの組み合わせを生成し、ある組み合わせ内の前記異なる種別のリクエストと一致する他の組み合わせを削除し、削除後において、処理期間中に第２の装置で処理された第２のリクエストを第２のリクエスト集合から取得し、削除後において、取得した第２のリクエストとの相関値を算出し、算出結果を出力する。

Description

特定装置、特定方法、および特定プログラム
　本発明は、計算機システムで起きた性能障害の原因候補を特定する特定装置、特定方法、および特定プログラムに関する。
　計算機システムの性能管理は、運用部門の重要な役割の一つである。運用部門は、（Ａ）計算機システムがエンドユーザへ提供するサービスの性能劣化を検知し、（Ｂ）その原因を特定し、対処する。
（Ａ）を実現する技術にエンドユーザモニタリング技術がある。この技術は、エンドユーザから計算機システムへの処理要求を監視し、処理要求の遅延を検知する技術である。計算機システムがＷｅｂシステムの場合、エンドユーザから計算機システムへ送られたＨＴＴＰリクエストのパケットを監視し、処理要求パケットとその応答パケットの時間差から応答時間を求め、遅延の有無を検出する。
（Ｂ）の性能障害の原因を特定する作業は、特に性能障害が起きやすいデータベースに対して行われることが多い。運用管理者は、データベースに送られた処理要求（ＳＱＬ文）を監視し、その実行時間の記録から、性能障害の原因と思われるＳＱＬ文を特定する。
　（Ａ）のＨＴＴＰリクエスト監視と、（Ｂ）のＳＱＬ文監視がそれぞれ個別に行われるため、両者を関連づけられない。このため、（Ａ）でＨＴＴＰリクエストの遅延を検知しても、遅延を発生させたＳＱＬ文を効率的に特定できない。
　これに対し、特許文献１の分析装置は、第一の組におけるリクエストとレスポンスとの間に、第二の組が存在する確率を算出し、算出された確率に基づいて、所定の第一の組に対応する第二の組を抽出する。すなわち、特許文献１の分析装置は、事前に関連のある情報同士を定義したモデルを用いることなく、確率に基づいて、所定の第一の組に対応する第二の組を抽出する。そのため、特許文献１の分析装置は、システムの仕様変更などにより、新たな第一の組と第二の組との対応が発生しても、この新たな第一の組と第二の組とを紐付ける。
　このように、特許文献１には、それぞれ独立に計測したＨＴＴＰリクエストとＳＱＬリクエストとが同じ期間に観測される確率（すなわち相関性）を計算する。あるＨＴＴＰリクエストの処理期間中に、特定のＳＱＬ文が現れる確率が高い場合、両者の間に関連性があるとする。
特開２０１２－１９８８１８号公報
　ＨＴＴＰリクエストおよびＳＱＬ文は、１秒間に数十～数百個処理されることがあるため、その記録量が膨大になる。そのため、ＨＴＴＰリクエストとＳＱＬ文との確率を総当り的に計算すると、大量のデータ読み込みと膨大な計算が必要になる。このような計算を現実的な時間で実行する場合、計算負荷が増大するという問題がある。このような問題は、ＨＴＴＰリクエストとＳＱＬ文との関係に限らず、独立して観測される複数のデータ間で生じる。
　本発明は、独立して観測される複数のデータの対応関係を求める計算量を削減することを目的とする。
　本願において開示される発明の一側面となる特定装置、特定方法、および特定プログラムは、第１の装置および第２の装置に接続される特定装置、特定方法、および特定プログラムであって、プログラムを実行するプロセッサと、前記プロセッサが実行するプログラムを格納するメモリと、前記第１の装置との間の通信を制御し、前記第２の装置との間の通信を制御するインターフェースとを備え、前記メモリは、前記第１の装置が受信した第１のリクエスト集合と、前記第１の装置からの要求により前記第２の装置で処理された第２のリクエスト集合と、を記憶し、前記プロセッサは、前記第１のリクエスト集合の中の調査対象リクエストと同一種別である同種別リクエスト群を前記第１のリクエスト集合の中から取得し、前記調査対象リクエストおよび前記同種別リクエスト群の各リクエストについて、前記第１の装置から前記第２の装置に送信されてから前記第２の装置から前記第１の装置にレスポンスが送信されるまでの処理期間中に前記第１の装置から前記第２の装置に送信され前記第２の装置から前記第１の装置にレスポンスが送信された、前記調査対象リクエストの種別とは異なる他の種別のリクエストを、前記第１のリクエスト集合の中から取得し、前記調査対象リクエストおよび前記同種別リクエスト群の各リクエストについて、取得された前記他の種別のリクエストとの組み合わせを生成し、生成された組み合わせの集合の中から、ある組み合わせ内の前記異なる種別のリクエストと一致する他の組み合わせを削除し、削除後における前記調査対象リクエストおよび前記同種別リクエスト群の各リクエストについて、前記処理期間中に前記第２の装置で処理された第２のリクエストを前記第２のリクエスト集合から取得し、前記削除後における前記調査対象リクエストおよび前記同種別リクエスト群の各リクエストについて、取得した前記第２のリクエストとの相関値を算出し、算出結果を出力する、ことを特徴とする。
　本発明の代表的な実施の形態によれば、独立して観測される複数のデータの対応関係を求める計算量を削減することができる。前述した以外の課題、構成及び効果は、以下の実施例の説明により明らかにされる。
本発明の実施の形態における性能障害の原因候補の特定例を示す説明図である。 実施例１にかかる監視システムのシステム構成図である。 図１に示したＨＴＴＰ監視データテーブルの記憶内容例を示す説明図である。 ＳＱＬ監視データテーブルの記憶内容例を示す説明図である。 監視設定テーブルの記憶内容例を示す説明図である。 ＨＴＴＰ監視プログラムの動作処理手順例を示すフローチャートである。 ＳＱＬ文特定プログラムが表示装置に表示する画面例を示す説明図である。 ＳＱＬ文特定プログラムによる処理手順例を示すフローチャートである。 図８に示したエントリ削除処理（ステップＳ８０６）の詳細な処理手順例を示すフローチャートである。 実施例２にかかる監視システムのシステム構成図である。 実施例２にかかる監視システムで利用するテーブルの記憶内容例を示す説明図である。 実施例２にかかるＳＱＬ文特定プログラムによるＳＱＬ文特定処理の詳細な処理手順例を示すフローチャートである。 図１２に示したＨＴＴＰ－ＳＱＬ集計テーブル更新処理（ステップＳ１２０４）の詳細な処理手順例を示すフローチャート（前半）である。 図１２に示したＨＴＴＰ－ＳＱＬ集計テーブル更新処理（ステップＳ１２０４）の詳細な処理手順例を示すフローチャート（後半）である。 図１３に示した第１の更新処理（ステップＳ１３１０）の詳細な処理手順例を示すフローチャートである。 図１４に示した第２の更新処理（ステップＳ１４０４）の詳細な処理手順例を示すフローチャートである。 実施例２にかかるＨＴＴＰ監視プログラムによるＳＱＬ文特定プログラム８２の起動処理の詳細な処理手順例を示すフローチャートである。 実施例３にかかる監視システムのシステム構成図である。 図１８に示したベースラインテーブルの記憶内容例を示す説明図である。 ＳＱＬ文監視プログラムによる監視モード変更処理手順の詳細な処理手順例を示すフローチャートである。
　以後の説明では「ａａａテーブル」、「ａａａリスト」、「ａａａＤＢ」、「ａａａキュー」等の表現にて本発明の情報を説明するが、これら情報は必ずしもテーブル、リスト、ＤＢ、キュー、等のデータ構造以外で表現されていてもよい。そのため、データ構造に依存しないことを示すために「ａａａテーブル」、「ａａａリスト」、「ａａａＤＢ」、「ａａａキュー」等について「ａａａ情報」と呼ぶことがある。
　さらに、各情報の内容を説明する際に、「識別情報」、「識別子」、「名」、「名前」、「ＩＤ」という表現を用いるが、これらについてはお互いに置換が可能である。
　以後の説明では「プログラム」を主語として説明を行う場合があるが、プログラムはプロセッサによって実行されることで定められた処理をメモリ及び通信ポート（通信制御デバイス）を用いながら行うため、プロセッサを主語とした説明としてもよい。また、プログラムを主語として開示された処理は管理サーバ等の計算機、情報処理装置が行う処理としてもよい。また、プログラムの一部または全ては専用ハードウェアによって実現されてもよい。
　また、各種プログラムはプログラム配布サーバや、計算機が読み取り可能な記憶メディアによって各計算機にインストールされてもよい。この場合、プログラム配布サーバはプロセッサと記憶資源を含み、記憶資源はさらに配布プログラムと配布対象であるプログラムを記憶している。そして、配布プログラムをプロセッサが実行することで、プログラム配布サーバのプロセッサは配布対象のプログラムを他の計算機に配布する。
　なお、本実施の形態にかかる監視計算機は入出力デバイスを有する。入出力デバイスの例としてはディスプレイとキーボードとポインタデバイスが考えられるが、これ以外のデバイスであってもよい。また、入出力デバイスの代替としてシリアルインターフェースやイーサーネットインターフェースを入出力デバイスとし、当該インターフェースにディスプレイ又はキーボード又はポインタデバイスを有する表示用計算機を接続し、表示用情報を表示用計算機に送信したり、入力用情報を表示用計算機から受信することで、表示用計算機で表示を行ったり、入力を受け付けることで入出力デバイスでの入力及び表示を代替してもよい。
　以後、監視対象である計算機システムを監視し、本願発明の表示用情報を表示する一つ以上の計算機の集合を監視システムと呼ぶことがある。管理計算機が表示用情報を表示する場合は監視計算機が管理システムである、また、監視計算機と表示用計算機の組み合わせも監視システムである。また、監視処理の高速化や高信頼化のために複数の計算機で監視計算機と同等の処理を実現してもよく、この場合は当該複数の計算機（表示を表示用計算機が行う場合は表示用計算機も含め）が監視システムである。
　本発明の実施の形態にかかる性能障害の原因候補を特定する特定装置、特定方法、および特定プログラムについて説明する。
　本実施の形態は、第１のリクエストの一例であるＨＴＴＰ（ＨｙｐｅｒＴｅｘｔ　Ｔｒａｎｓｆｅｒ　Ｐｒｏｔｏｃｏｌ）リクエストと第２のリクエストの一例であるＳＱＬ（Ｓｔｒｕｃｔｕｒｅｄ　Ｑｕｅｒｙ　Ｌａｎｇｕａｇｅ）文との対応を、より少ない計算量で精度良く求め、遅延したＨＴＴＰリクエストを起点として効率的に原因候補のＳＱＬ文を特定する。具体的には、背景技術の項で説明した従来方式は、総当り的にＨＴＴＰリクエストとＳＱＬ文の相関関係を求めるのに対し、本実施の形態は、一部の期間に限定することで計算量を大幅に削減する。
　＜性能障害の原因候補の特定例＞
　図１は、本発明の実施の形態における性能障害の原因候補の特定例を示す説明図である。図１において、左端の縦線は時間軸であり、上から下に向かって時間経過を示す。また、左列は、ある期間に計測されたＨＴＴＰリクエストであり、中列は、左列と同期間に計測されたＳＱＬ文であり、右列は、左列および中列における各期間を相関関係の計算に使用するか否かを示す。
　左列の「＃１」の囲みは、「ある期間」を示す。図１では、４つの期間、すなわち＃１、＃２、＃３、および＃４を図示しており、期間＃１を例にとった表記説明は、他の期間＃２、＃３、および＃４にも共通である。
　左列＃１の囲みは、２つのＨＴＴＰリクエスト、すなわち、Ｈ１とＨ２という種類のＨＴＴＰリクエストが、期間＃１に平行して処理されたことを示している。ここで、Ｈ１およびＨ２は、ＨＴＴＰリクエストの種別、つまり、ＵＲＬ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｌｏｃａｔｏｒ）やそれに類する識別情報など、ＨＴＴＰリクエストの種別を識別可能な情報を簡略的に表現した符号である。なお、この例では、図１中濃いハッチがかかったＨＴＴＰリクエストＨ１が遅延（性能障害）を示す。
　以下、遅延が発生して性能障害の原因を特定したいＨＴＴＰリクエスト（ここではＨ１）をターゲットＨＴＴＰリクエスト、それ以外のＨＴＴＰリクエスト（ここではＨ２、Ｈ３、…）を外乱ＨＴＴＰリクエストと表記する。
　中列も前述のＨＴＴＰ監視データと同様に、期間＃１中に、二つのＳＱＬ文、すなわち、Ｓ１およびＳ２という種別のＳＱＬ文が、平行して処理されたことを示している。ここで、Ｓ１は、ＨＴＴＰリクエストＨ１の処理中にＤＢＭＳ（ＤａｔａＢａｓｅ　Ｍａｎａｇｅｍｅｎｔ　Ｓｙｓｔｅｍ）で処理されたＳＱＬ文とする。またＨ２、Ｓ２の関係も同様とする。
　このように、ＨＴＴＰリクエストとＳＱＬ文の間には、処理上の対応関係が存在するが、ＨＴＴＰリクエストとＳＱＬ文をそれぞれ個別に計測した場合、一般的に、両者を結びつける情報を得ることはできない。そのため、時間的な相関性によって両者を結びつける技術の必要性が生じる。すなわち、ＨＴＴＰリクエストＨ１の処理中に、ＤＢＭＳでＳ１というＳＱＬ文が処理されていることが統計的に多い場合、Ｈ１とＳ１に処理上の関係性があるものと推測できる。
　しかしながら、統計的な手法でＨＴＴＰリクエストとＳＱＬ文との間の相関性計算には、膨大な計算量を要する。図１には、簡単のため、ＨＴＴＰリクエストおよびＳＱＬ文ともに少数のケースを図示しているが、実際にはそれぞれ秒間数十個～数百個の場合がありうる。本実施の形態も、ＨＴＴＰリクエストとＳＱＬ文との間の時間的な相関性で両者の関連性を推測するが、次の手法によって相関計算に用いる期間を限定し、計算量を削減する。
手法１：外乱ＨＴＴＰリクエストが少ない期間を選択する。
　特定装置は、ターゲットＨＴＴＰリクエストと同時に処理されていた外乱ＨＴＴＰリクエストが少ない期間を選択して相関計算を行う。たとえば、ターゲットＨＴＴＰリクエストのみが処理されていた期間であれば、同期間に計測されたＳＱＬ文はターゲットＨＴＴＰリクエストと関連がある確率は高い。逆に、外乱ＨＴＴＰリクエストが多数ある期間の場合、同期間に計測されるＳＱＬ文も多数あることが多い。当該期間での相関計算は、正しくターゲットＨＴＴＰリクエストとＳＱＬ文との関係が得られる確率は低くなる。
　期間＃２は、外乱ＨＴＴＰリクエストが多数あるケースを示している。このケースでは、ターゲットＨＴＴＰリクエストＨ１の他、３個の外乱ＨＴＴＰリクエストＨ３、Ｈ４、Ｈ５処理される。ＳＱＬ文も同様に、ターゲットＨＴＴＰリクエストと関連のあるＳＱＬ文（Ｓ１）と、それ以外のＳＱＬ文（Ｓ３、Ｓ４、Ｓ５）が処理される。期間＃２について機械的に相関性を計算すると、次のようになる。
　下記は、期間＃２についてのＨＴＴＰリクエストとＳＱＬ文との相関性が正しい確率を示す。たとえば、以下に示すように、Ｈ１→Ｓ１の相関性が正しい確率が１/１６、Ｈ１→Ｓ３の相関性が正しい確率が１/１６、Ｈ１→Ｓ４、Ｈ１→Ｓ５も同様である。
ＨＴＴＰリクエスト→ＳＱＬ文：左の組み合わせの相関性が正しい確率
　Ｈ１　　　　　　→Ｓ１　　：１/１６
　Ｈ１　　　　　　→Ｓ３　　：１/１６
　Ｈ１　　　　　　→Ｓ４　　：１/１６
　Ｈ１　　　　　　→Ｓ５　　：１/１６
　Ｈ３　　　　　　→Ｓ１　　：１/１６
　Ｈ３　　　　　　→Ｓ３　　：１/１６
　Ｈ３　　　　　　→Ｓ４　　：１/１６
　Ｈ３　　　　　　→Ｓ５　　：１/１６
　Ｈ４　　　　　　→Ｓ１　　：１/１６
　Ｈ４　　　　　　→Ｓ３　　：１/１６
　Ｈ４　　　　　　→Ｓ４　　：１/１６
　Ｈ４　　　　　　→Ｓ５　　：１/１６
　Ｈ５　　　　　　→Ｓ１　　：１/１６
　Ｈ５　　　　　　→Ｓ３　　：１/１６
　Ｈ５　　　　　　→Ｓ４　　：１/１６
　Ｈ５　　　　　　→Ｓ５　　：１/１６
　上記から、正しい相関性Ｈ１→Ｓ１が得られている確率は１／１６となる。一方、同じ計算を期間＃１で行った場合は、下記のようになる。
ＨＴＴＰリクエスト→ＳＱＬ文：左の組み合わせの相関性が正しい確率
　Ｈ１　　　　　　→Ｓ１　　：１/４
　Ｈ１　　　　　　→Ｓ２　　：１/４
　Ｈ２　　　　　　→Ｓ１　　：１/４
　Ｈ２　　　　　　→Ｓ２　　：１/４
　期間＃１での計算では、正しい相関性Ｈ１→Ｓ１が得られる確率は１／４となり、期間＃２よりも大きな値を得られることが分かる。また、計算量も期間＃２より少ないことが分かる。しかしながら、この計算方法は、正しくない相関性も強化してしまう。たとえば、期間＃１の例では、正しくない相関性Ｈ１→Ｓ２の確率１／４を計算結果に反映してしまう。もし、期間＃１と同じＨＴＴＰリクエストＨ１、Ｈ２が計測された期間＃３を相関計算に用いた場合、Ｈ１→Ｓ２という正しくない相関性が更に強化されてしまう。これを避けるために、次の手法が追加される。
手法２：　外乱ＨＴＴＰリクエストの種別を不揃いにする。
　すなわち、期間＃１（Ｈ１、Ｈ２）を相関計算に用いた場合、同じＨＴＴＰリクエストが計測された期間＃３（Ｈ１、Ｈ２）を相関計算に用いない。これにより、正しくない相関性が強化されることを回避する。以上の手法を整理すると、相関計算に用いる期間は次のようになる。ここで、左端の×印は、相関計算に用いない期間であることを示している。
　期間＃１：　　（Ｈ１、Ｈ２）
×期間＃２：　　（Ｈ１、Ｈ３、Ｈ４、Ｈ５）
×期間＃３：　　（Ｈ１、Ｈ２）
　期間＃４：　　（Ｈ１、Ｈ６）
　すなわち、期間＃２は、外乱ＨＴＴＰリクエストが多いため手法１により除外される。また、期間＃３は、期間＃１と外乱ＨＴＴＰリクエストが同じであるため手法２により除外される。したがって、本実施の形態の手法は、ターゲットＨＴＴＰリクエストＨ１以外のＨＴＴＰリクエストの数が少なく、また、外乱ＨＴＴＰリクエストの種別が揃わないように期間を選択する。これにより、効率的かつ精度良く、ＨＴＴＰリクエストＨ１とＨＴＴＰリクエストＨ１に相関のあるＳＱＬ文との相関性が表れやすくする。
　したがって、処理性能に遅延を示したＨＴＴＰリクエストの原因候補となるＳＱＬ文の特定に必要な計算量を削減することができる。また、計算に必要なデータ読み込み量も同時に削減することができる。また、計算量を削減することで、計算機１台で多数の計算機システムを監視することができる。また、処理性能に遅延を示したＨＴＴＰリクエストの原因となるＳＱＬ文を特定しやすい期間を、意図的に現出することができる。以下、本実施の形態の実施例について説明する。なお、以下に示す各実施例では、手法１および手法２を適用した例について説明するが、手法１および手法２のうち手法１のみ、または手法２のみを適用することとしてもよい。
　（実施例１）
　＜監視システム＞
　図２は、実施例１にかかる監視システムのシステム構成図である。ネットワークシステム１は、監視計算機１０とその監視対象である計算機システム９５とを含む。監視計算機１０と計算機システム９５の各構成要素（後述）は、たとえば、ＬＡＮ（Ｌｏｃａｌ　Ａｒｅａ　Ｎｅｔｗｏｒｋ）９０で接続される。
　監視計算機１０は、プロセッサ１１、メモリ１２、表示Ｉ／Ｆ１４、およびネットワーク（ＮＷ）Ｉ／Ｆ１６から構成される。プロセッサ１１は、メモリ１２に格納されたＨＴＴＰ監視プログラム８０、ＳＱＬ文監視プログラム８１、およびＳＱＬ文特定プログラム８２を実行する。また、メモリ１２には、各プログラムが読み書きするＨＴＴＰ監視データテーブル２０、ＳＱＬ監視データテーブル３０、および監視設定テーブル４０が格納される。
　表示Ｉ／Ｆ１４は、表示装置１５と接続される。各プログラムが運用管理者と入出力を行うための画面は、表示Ｉ／Ｆを介して表示装置１５に表示される。ＮＷＩ／Ｆ１６は、ＬＡＮ９０に接続される。各プログラムは、ＮＷＩ／Ｆ１６を介して、計算機システム９５の構成要素と通信する。
　計算機システム９５は、スイッチ９２、Ｗｅｂ／ＡＰサーバ９３、データベース（ＤＢ）サーバ９４を含む。スイッチ９２、Ｗｅｂ／ＡＰサーバ９３、ＤＢサーバ９４は、ＬＡＮ９０に接続され、相互に通信する。Ｗｅｂ／ＡＰサーバ９３は、Ｗｅｂサーバまたはアプリケーションサーバのいずれか、または両機能を有するサーバである。Ｗｅｂ／ＡＰサーバ９３は複数台あってもよい。端末９１は、ブラウザを用いて、計算機システム９５へＨＴＴＰリクエストを送信する。ＨＴＴＰリクエストはスイッチ９２を通り、Ｗｅｂ／ＡＰサーバ９３、ＤＢサーバ９４の順に処理される。処理された結果は、再度スイッチ９２を通り、端末９１が使用するブラウザへ返される。
　ＨＴＴＰ監視プログラム８０は、スイッチ９２を通過するパケットをキャプチャし、ＨＴＴＰリクエストの応答時間を計測する（詳細は後述）。計測結果は、ＨＴＴＰ監視データテーブル２０に格納される。
　ＳＱＬ文監視プログラム８１は、ある監視間隔で、定期的にＤＢサーバ９４で実行されたＳＱＬ文の性能を監視する。その監視結果はＳＱＬ監視データテーブル３０に格納される。ＳＱＬ文特定プログラム８２は、運用管理者とインタラクションし、遅延したＨＴＴＰリクエストの原因となるＳＱＬ文の絞込み作業を支援する。
　＜各テーブルの記憶内容例＞
　図３は、図１に示したＨＴＴＰ監視データテーブル２０の記憶内容例を示す説明図である。ＨＴＴＰ監視データテーブル２０は、ＨＴＴＰ監視プログラム８０が計測したＨＴＴＰリクエストに関する情報を記録するテーブルである。ＨＴＴＰ監視データテーブル２０の各エントリ２８（２８ａ～２８ｌ、…）は、ＨＴＴＰ監視プログラム８０が計測した以下の情報２１～２７を含む。
　ＨＴＴＰリクエスト識別子２１とは、各ＨＴＴＰリクエストに付与された一意識別子である。処理ホスト別ＨＴＴＰリクエスト同実行数２２とは、当該ＨＴＴＰリクエスト処理中に同時実行されていたＨＴＴＰリクエストの数を処理ホスト２３別に集計した値である。処理ホスト２３とは、当該ＨＴＴＰリクエストが送信されたＷｅｂ／ＡＰサーバ９３のホスト情報である。ＨＴＴＰリクエスト種別識別子２４とは、当該ＨＴＴＰリクエストの種類の一意識別子である。ＨＴＴＰリクエスト種別識別子２４は、ＨＴＴＰリクエストのＵＲＩ（Ｕｎｉｆｏｒｍ　Ｒｅｓｏｕｒｃｅ　Ｉｄｅｎｔｉｆｉｅｒ）でもよいし、ＵＲＩの一部、または、ＵＲＩを基に生成したハッシュ値などでもよい。図３では、簡単のため、Ｈ１やＨ２といった表記が用いられる。
　開始時刻２５とは、当該ＨＴＴＰリクエストが計算機システム９５で処理が開始された時刻である。たとえば、当該ＨＴＴＰリクエストを、ＨＴＴＰ監視プログラム８０がキャプチャした時刻である。終了時刻２６とは、当該ＨＴＴＰリクエストが計算機システム９５で処理が終了した時刻である。たとえば、当該ＨＴＴＰリクエストが計算機システム９５で処理された応答メッセージをＨＴＴＰ監視プログラム８０がキャプチャした時刻である。
　しきい値超過２７とは、終了時刻２６から開始時刻２５を減算して得られた当該ＨＴＴＰリクエストの応答時間が、所定のしきい値を超過したか否かを示すフラグである。図３では、超過した場合に「Ｙ」、超過していなければ「Ｎ」が記録される。しきい値は静的な一定のしきい値でもよいし、後述する実施例３で後述するベースライン監視による動的なしきい値でもよい。
　図４は、ＳＱＬ監視データテーブル３０の記憶内容例を示す説明図である。ＳＱＬ監視データテーブル３０は、監視計算機１０が計測したＳＱＬ文に関する情報を記録するテーブルである。ＳＱＬ監視データテーブル３０の各エントリ３９（３９ａ～３９ｌ、…）は、監視計算機１０が計測した、Ｗｅｂ／ＡＰサーバ９３からＤＢサーバ９４へ実行要求された個々のＳＱＬ文に関する情報３１～３８を含む。
　ＳＱＬ識別子３１とは、当該ＳＱＬの種別を表す一意識別子である。ＳＱＬ識別子３１は、実際に実行要求されたＳＱＬ文でもよいし、ＳＱＬ文の一部でもよいし、または、ＳＱＬ文を基に生成されたハッシュ値でもよい。開始時刻３１とは、当該ＳＱＬの処理が開始された時刻である。終了時刻３３とは、当該ＳＱＬの処理が終了した時刻である。
　要求元ホスト３４とは、当該ＳＱＬ文の実行を要求したＷｅｂ／ＡＰサーバ９３のホスト情報である。トランザクションＩＤ３５とは、当該ＳＱＬ文が属するＤＢサーバ９４（より具体的にはＤＢサーバ９４上で動作するＤＢＭＳ）によって付与されたトランザクションの識別子である。同一トランザクションに属するＳＱＬ文には、同じトランザクションＩＤ３５が付与される。すべてのＳＱＬ文にトランザクションＩＤ３５が付与されるわけではないため、トランザクションＩＤ３５は空欄の場合がある。
　プロセッサ時間３６、Ｉ／Ｏ待ち時間３７、ロック待ち時間３８は、当該ＳＱＬ文の処理時間の内訳の時間である。ＤＢＭＳによっては、これらの時間情報を計測できない場合がある。また、これらの時間以外に、ＳＱＬ文の処理時間の内訳を示す時間情報をＳＱＬ監視データテーブル３０に格納してもよい。
　図５は、監視設定テーブル４０の記憶内容例を示す説明図である。監視設定テーブル４０は、計算機システム９５別の監視設定情報を記録するテーブルである。ＨＴＴＰ監視プログラム８０およびＳＱＬ文監視プログラム８１は、監視設定テーブル４０から監視設定情報にしたがい、計算機システム９５を監視する。監視設定テーブル４０の各エントリには、それぞれ一つの監視設定情報が記録される。
　システム４１とは、当該エントリに記録された監視設定情報が適用される計算機システム９５を示す情報である。図５では、「システムＡ」に監視設定情報が適用される。監視対象４２とは、監視設定情報の監視対象（ＨＴＴＰリクエストやＤＢＭＳ、あるいは図示しないが、サーバのプロセッサ使用率など）である。「システムＡ」の場合、ＨＴＴＰリクエストおよびＤＢＭＳが監視対象となる。
　監視プロパティ：値４３とは、監視設定情報のプロパティ名とその値とを示す情報である。監視プロパティには、監視間隔と監視対象がある。図５では、例として、システムＡの全ＨＴＴＰリクエストをリアルタイムに監視すること、ＤＢＭＳへ実行要求されたＳＱＬ文を１秒間隔で監視することが規定される。
　＜ＨＴＴＰ監視プログラム８０の動作処理手順＞
　図６は、ＨＴＴＰ監視プログラム８０の動作処理手順例を示すフローチャートである。ＨＴＴＰ監視プログラム８０は、計算機システム９５が処理するＨＴＴＰリクエストの応答時間を計測し、その結果をＨＴＴＰ監視データテーブル２０へ格納する。
　ＨＴＴＰ監視プログラム８０は、端末９１からＷｅｂ／ＡＰサーバ９３へ送信されたＨＴＴＰリクエストのパケットをキャプチャする（ステップＳ６０１）。端末９１から送信されたＨＴＴＰリクエストは、スイッチ９２によってＷｅｂ／ＡＰサーバ９３へ送られる。このとき、スイッチ９２は、パケットを複製してミラーポートへ送る。ＨＴＴＰ監視プログラム８０は、ＮＷＩ／Ｆ１６から、その複製されたパケットをキャプチャする。この場合、ＨＴＴＰ監視プログラム８０は、ＨＴＴＰリクエストへの応答メッセージとつき合わせて応答時間等を算出するために、キャプチャしたＨＴＴＰリクエストをメモリ１２に記録する。
　ＨＴＴＰ監視プログラム８０は、端末９１が処理要求したＨＴＴＰリクエストに対して、計算機システム９５が返却する応答メッセージのパケットをキャプチャする（ステップＳ６０２）。端末９１が処理要求したＨＴＴＰリクエストは、Ｗｅｂ／ＡＰサーバ９３およびＤＢサーバ９４で処理され、応答メッセージが生成される。応答メッセージは、Ｗｅｂ／ＡＰサーバから９３から端末９１へ送信される。このとき、ＨＴＴＰリクエストと同様に、応答メッセージもスイッチ９２を通過する。ＨＴＴＰ監視プログラム８０は、ステップＳ６０１と同様に、応答メッセージのパケットをキャプチャする。
　ＨＴＴＰ監視プログラム８０は、ＨＴＴＰリクエストの応答時間を算出する（ステップＳ６０３）。ＨＴＴＰ監視プログラム８０は、ステップＳ６０１で一時的に記録したＨＴＴＰリクエストのパケットと、ステップＳ６０２で取得した、それに対する応答メッセージとの計測時刻の差分を、ＨＴＴＰリクエストの応答時間として算出する。
　ＨＴＴＰ監視プログラム８０は、その時点で平行に処理されていたＨＴＴＰリクエストの数、すなわち、処理ホスト別ＨＴＴＰリクエスト同時実行数を計算する（ステップＳ６０４）。ＨＴＴＰ監視プログラム８０は、ステップＳ６０１において一時記憶域に記録されたＨＴＴＰリクエストを、同ＨＴＴＰリクエストのヘッダから取得した送信先ホストごとにグルーピングし、その個数を処理ホスト別ＨＴＴＰリクエスト同時実行数として算出する。
　ＨＴＴＰリクエスト同時実行数の算出は、別の方法でもよい。たとえば、ＨＴＴＰ監視プログラム８０が、一定期間（たとえば１秒）に一時記憶域に記録されたＨＴＴＰリクエスト数の最大値をＨＴＴＰリクエスト同時実行数として求め、この数を、この期間中に処理された全ＨＴＴＰリクエストのＨＴＴＰリクエスト同時実行数としてもよい。
　ＨＴＴＰ監視プログラム８０は、ＨＴＴＰ監視データテーブル２０に新規のエントリを追加し、ＨＴＴＰリクエストのデータを記録する（ステップＳ６０５）。ＨＴＴＰ監視プログラム８０は、新規エントリ作成時に、ＨＴＴＰ監視データテーブル２０内で一意な識別子を生成し、ＨＴＴＰリクエスト識別子２１として記録する。また、ＨＴＴＰ監視プログラム８０は、ステップＳ６０４で算出した値を、処理ホスト別ＨＴＴＰリクエスト同時実行数２２に格納する。
　また、ＨＴＴＰ監視プログラム８０は、ステップＳ６０１で一時記憶域に保存したＨＴＴＰリクエストのヘッダから送信先ホストおよびＵＲＬを取得し、それぞれ処理ホスト２３、ＨＴＴＰリクエスト種別識別子２４として記録する。前述の通り、ＨＴＴＰリクエスト種別識別子２４は、ＵＲＬそのままでもよいし、ＵＲＬを元に生成した別の識別子でもよい。
　また、ＨＴＴＰ監視プログラム８０は、ステップＳ６０１でＨＴＴＰリクエストをキャプチャした時刻を開始時刻２５とし、また、ステップＳ６０２で応答メッセージをキャプチャした時刻を終了時刻２６として記録する。また、応答時間に対してしきい値が設けられている場合、ＨＴＴＰ監視プログラム８０は、ステップＳ３で求めた応答時間が、そのしきい値を超過している場合、しきい値超過２７に「Ｙ」を、超過してなければ「Ｎ」を記録する。
　次に、ＳＱＬ文監視プログラム８１の動作を説明する。ＳＱＬ文監視プログラム８１は、ある監視間隔でＤＢサーバ９４から監視データの取得を要求する。ＳＱＬ文監視プログラム８１は、監視設定テーブル４０のエントリ４４ｃを読み込む。したがって、監視間隔は、図５に示す監視設定テーブル４０に格納される。監視データを要求されたＤＢサーバ９４は、要求時点で動作していたＳＱＬ文に関する情報をＳＱＬ文監視プログラム８１へ返却する。ＳＱＬ文監視プログラム８１は、ＳＱＬ監視データテーブル３０に取得した情報を格納する。フローチャートの説明に先立ち、想定する運用管理者の操作例について説明する。
　図７は、ＳＱＬ文特定プログラム８２が表示装置１５に表示する画面例を示す説明図である。運用管理者は、この画面を操作し、原因ＳＱＬ文を特定したい遅延ＨＴＴＰリクエストを指定する。ＳＱＬ文特定プログラム８２は、指定された遅延ＨＴＴＰリクエストの原因ＳＱＬ文の候補を特定し、その結果を画面に表示する。
　図７の画面例は、上下２つのペインで構成される。上部ペインは、遅延ＨＴＴＰリクエスト一覧１００を表示する。ＳＱＬ文特定プログラム８２は、ＨＴＴＰ監視データテーブルを参照し、しきい値超過２７が「Ｙ」であるエントリを取得し、それぞれを画面上の遅延ＨＴＴＰリクエスト一覧１００のエントリ１０１（１０１ａ～１０１ｃ）に表示する。運用管理者は、表示されたエントリ１０１から原因ＳＱＬ文を特定したいエントリを決め、チェックボックス１０２をチェックする。図７の画面例では、エントリ１０１ａについてチェックされている。
　ＳＱＬ文特定プログラム８２は、運用管理者がチェックした遅延ＨＴＴＰリクエスト（以下、単に「調査対象」と称す）を受領し、その原因ＳＱＬ文を少数の候補に絞り込む。この絞り込み処理が、後述する図８のフローチャートに相当する。画面の下部ペインは、ＳＱＬ文特定プログラム８２が絞り込んだ、原因ＳＱＬリスト１０３を表示する。原因ＳＱＬリスト１０３の各行には、原因ＳＱＬエントリ１０４が表示される。各原因ＳＱＬエントリ１０４には、そのＳＱＬ文が原因であることの確からしさを示すレーティング１０５が含まれる。運用管理者は、レーティング１０５を参考に、遅延を引き起こした原因ＳＱＬ文を認識する。次に、ＳＱＬ文特定プログラム８２の動作を図８のフローチャートで説明する。
　図８は、ＳＱＬ文特定プログラム８２による処理手順例を示すフローチャートである。ＳＱＬ文特定プログラム８２は、運用管理者が画面上でＨＴＴＰリクエストが指定されるのを待ち受ける（ステップＳ８０１：Ｎｏ）。図７に示したようにチェックボックスにチェックを入力することによりＨＴＴＰリクエストが指定された場合（ステップＳ８０１：Ｙｅｓ）、ＳＱＬ文特定プログラム８２は、指定された調査対象の情報を取得する（ステップＳ８０２）。以下では、調査対象の種別が「Ｈ１」であるものとする。
　つぎに、ＳＱＬ文特定プログラム８２は、調査対象の遅延と処理ホスト別ＨＴＴＰリクエスト同時実行数との強い相関性の有無を調べる（ステップＳ８０２）。強い相関性の有無は、一般的な相関度計算の手法を用いてよい。たとえば、ＳＱＬ文特定プログラム８２は、調査対象と同種別のＨＴＴＰリクエストが過去に処理された期間の期間長と、同期間の処理ホスト別ＨＴＴＰリクエスト同時実行数と、の相関係数を計算する。調査対象と同種別のＨＴＴＰリクエストが過去に処理された期間の期間長とは、調査対象と同種別のＨＴＴＰリクエストについて終了時刻から開始時刻を減算した時間である。そして、ＳＱＬ文特定プログラム８２は、計算した相関係数がしきい値を超過する場合、強い相関性があると判定する手法でもよい。
　このあと、ＳＱＬ文特定プログラム８２は、強い相関性があるか否かを判断する（ステップＳ８０３）。強い相関性がある場合（ステップＳ８０３：Ｙｅｓ）、ステップＳ８０４へ進み、強い相関性がない場合（ステップＳ８０３：Ｎｏ）、ステップＳ８０３へ進む。上述した「手法１：外乱ＨＴＴＰリクエストが少ない期間を選択する。」の効果が低い場合には、手法１の適用を除外するためである。
　調査対象の遅延が、計算機システム９５のＨＴＴＰリクエスト数が多い場合（換言すれば、処理ホスト別ＨＴＴＰリクエスト同時実行数が多い場合）にのみ起きるのであれば、処理ホスト別ＨＴＴＰリクエスト同時実行数が少ない期間を選択する手法１の効果は小さいことになる。ステップＳ８０３およびステップＳ８０４はオプショナルであり、ＳＱＬ文特定プログラム８２は、必ずしも実行する必要はない。
　強い相関性がある場合（ステップＳ８０３：Ｙｅｓ）、ＳＱＬ文特定プログラム８２は、調査対象と同種別のＨＴＴＰリクエスト（本例ではＨＴＴＰリクエスト種別識別子２４が「Ｈ１」）であり、かつ、しきい値超過２７が「Ｙ」であるＨＴＴＰリクエスト監視データテーブル２０から取得する（ステップＳ８０４）。ステップＳ８０４のあとは、ステップＳ８０７に移行する。
　一方、強い相関性がない場合（ステップＳ８０３：Ｎｏ）、ＳＱＬ文特定プログラム８２は、ＨＴＴＰ監視データテーブル２０を参照し、調査対象と同種別のＨＴＴＰリクエスト（本例ではＨＴＴＰリクエスト種別識別子２４が「Ｈ１」）のエントリ（以下、「同種別ＨＴＴＰリクエスト」と記す）を、処理ホスト別ＨＴＴＰリクエスト同時実行数２２が少ない順に取得する（ステップＳ８０５）。
　たとえば、調査対象が「Ｈ１」である場合、ＳＱＬ文特定プログラム８２は、ＨＴＴＰリクエスト種別識別子が「Ｈ１」であるエントリ２８ａ、２８ｃ、２８ｅ、２８ｉ、２８ｋを取得する。取得するエントリは、たとえば、処理ホスト別ＨＴＴＰリクエスト同時実行数２２が少ない順に上位Ｘ番目までのエントリや、処理ホスト別ＨＴＴＰリクエスト同時実行数２２の値が所定数以下のエントリなどが挙げられる。
つぎに、ＳＱＬ文特定プログラム８２は、エントリ削除処理を実行する（ステップＳ８０６）。エントリ削除処理（ステップＳ８０６）は、上述した手法２：「外乱ＨＴＴＰリクエストの種別を不揃いにする。」にしたがい、ステップＳ８０５で取得した同種別ＨＴＴＰリクエストの集合から、外乱ＨＴＴＰリクエストの組み合わせが同一であるエントリを削除する処理である。
　具体的には、ＳＱＬ文特定プログラム８２は、ステップＳ８０５で取得した同種別ＨＴＴＰリクエストと同一期間に処理されており、かつ、処理ホスト２３が同一であるＨＴＴＰリクエスト（外乱ＨＴＴＰリクエスト）のエントリをＨＴＴＰ監視データテーブル２０から取得する。これにより、調査対象と同種別ＨＴＴＰリクエストと、取得した外乱ＨＴＴＰリクエストとの「組」が形成される。
　たとえば、ステップＳ８０５で取得された同種別ＨＴＴＰリクエストのエントリ２８ａを例に挙げる。エントリ２８ａの処理期間（４時０分０秒．０００～４時０分１０秒．０００）を期間＃１とすると、期間＃１で処理されたＨＴＴＰリクエストのエントリ２８ｂを外乱ＨＴＴＰリクエストとして取得する。エントリ２８ｂのＨＴＴＰリクエスト種別識別子は「Ｈ２」である。
　これにより、期間＃１において、（Ｈ１、Ｈ２）の組が形成される。同様に、ステップＳ８０５で取得された同種別ＨＴＴＰリクエストのエントリ２８ｅを例に挙げると、（Ｈ１、Ｈ３、Ｈ４、Ｈ５）の組が形成され、エントリ２８ｉを例に挙げると、期間＃３（１時０分０秒．０００～１時０分５秒．０００）において（Ｈ１、Ｈ２）の組が形成される。また、エントリ２８ｋを例に挙げると、期間＃４（０時０分０秒．０００～０時０分５秒．０００）において（Ｈ１、Ｈ６）の組が形成される。
　ＳＱＬ文特定プログラム８２は、各組の外乱ＨＴＴＰリクエストの種別を比較し、外乱ＨＴＴＰリクエストの組み合わせが同じ組を特定する。そして、ＳＱＬ文特定プログラム８２は、同じ組が複数ある場合、１つだけ残し、それ以外の組を削除する。たとえば、上述した期間＃１の組（Ｈ１、Ｈ２）と期間＃３の組（Ｈ１、Ｈ２）は一致するため、ＳＱＬ文特定プログラム８２は、たとえば、期間＃３の組（Ｈ１、Ｈ２）を削除する。
　なお、外乱ＨＴＴＰリクエストの種別の組み合わせの同一判定は、完全一致でもいいし、部分一致でもいい。たとえば、外乱ＨＴＴＰリクエストのうち半数が重複していれば同一と判定してもよい。たとえば、ある期間において組（Ｈ１、Ｈ２、Ｈ３）が存在する場合、期間＃１の組（Ｈ１、Ｈ２）と部分一致する。この場合、組（Ｈ１、Ｈ２、Ｈ３）は、外乱リクエストＨ２、Ｈ３のうち半数であるＨ２が重複するため、ＳＱＬ文特定プログラム８２は、組（Ｈ１、Ｈ２、Ｈ３）を削除する。
　つぎに、ＳＱＬ文特定プログラム８２は、エントリ削除処理（ステップＳ８０６）後に残ったＨＴＴＰリクエストの各々に対して、ＳＱＬ監視データテーブル３０から対となるＳＱＬエントリを取得する（ステップＳ８０７）。すなわち、ＳＱＬ文特定プログラム８２は、エントリ削除処理（ステップＳ８０６）後に残ったＨＴＴＰリクエストのエントリと同じ期間に処理されており、かつ、同ＨＴＴＰリクエストの処理ホスト２３が、ＳＱＬ監視データテーブル３０の要求元ホスト３４と同一なＳＱＬエントリ３９を取得する。なお、ステップＳ８０４が実行された場合は、ＳＱＬ文特定プログラム８２は、ステップＳ８０４で取得したＨＴＴＰリクエストの各々に対して、ＳＱＬ監視データテーブル３０から対となるＳＱＬエントリを取得することになる（ステップＳ８０７）。
　そして、ＳＱＬ文特定プログラム８２は、ＳＱＬ監視データテーブル３０のトランザクションＩＤ３５を用いて、ステップＳ８０７で求めたＳＱＬエントリをフィルタリングする（ステップＳ８０８）。すなわち、ＳＱＬ文特定プログラム８２は、ステップＳ８０７で取得した各ＳＱＬエントリのトランザクションＩＤ３５を求め、同トランザクションＩＤを持つ他のエントリがＳＱＬ監視データテーブル３０に存在するか調べる。もし、そのようなエントリが存在する場合、そのトランザクションＩＤ３５を持つトランザクションは、同種別ＨＴＴＰリクエストの処理開始前から処理されていたこととなる。したがって、同トランザクションＩＤ３５を持つＳＱＬエントリ３９は除外してよい。なお、本ステップＳ８０８はオプショナルであり、必須のステップではない。
　このあと、ＳＱＬ文特定プログラム８２は、処理時間が一定時間未満のＳＱＬ文を削除し、ステップＳ８１０以降の相関性計算の対象から外す（ステップＳ８０９）。たとえば、ＳＱＬ文特定プログラム８２は、処理時間が一定時間未満のＳＱＬエントリ３９を除外してもよいし、監視設定テーブル４０を参照してＳＱＬ文を監視する監視間隔未満のＳＱＬエントリを除外してもよい。また、ステップＳ８０２で運用管理者から指定された調査対象と同期間に処理されていたＳＱＬエントリ３９以外のＳＱＬエントリを除外してもよい。
　ＳＱＬ文特定プログラム８２は、ＨＴＴＰリクエストとＳＱＬ文との相関値を計算する（ステップＳ８１０）。たとえば、図１に示した相関性の確率の計算方法のように、ＨＴＴＰリクエストとＳＱＬ文との共相関確率を計算する。計算手順は、一般的な相関確率計算の手法にしたがう。
　そして、ＳＱＬ文特定プログラム８２は、ＨＴＴＰリクエストとＳＱＬ文との相関値の大きいＳＱＬ文を遅延原因候補として、図７の原因ＳＱＬリスト１０３に表示する。このとき、運用管理者の理解を助ける指標として、相関値の大きなＳＱＬ文に高いレーティング１０５を付与する。レーティング１０５の計算方法はどのような方法でもよい。たとえば、０から１までの値域を持つ相関値を０．２ずつに区分けし、値が小さい方から順に５段階のレーティングをつける方法でもよい。運用管理者は、高いレーティング１０５を付与されたＳＱＬ文が、ＨＴＴＰリクエスト遅延の原因可能性が高いことを即座に認識することができる。これにより、運用管理者は、遅延したＨＴＴＰリクエストの原因ＳＱＬ文の候補を効率的に絞り込むことができる。
　図９は、図８に示したエントリ削除処理（ステップＳ８０６）の詳細な処理手順例を示すフローチャートである。ＳＱＬ文特定プログラム８２は、ステップＳ８０５で得られたエントリ群のうち、未選択のエントリがあるか否かを判断する（ステップＳ９０１）。未選択のエントリがある場合（ステップＳ９０１：Ｙｅｓ）、ＳＱＬ文特定プログラム８２は、未選択のエントリを１つ選択する（ステップＳ９０２）。そして、ＳＱＬ文特定プログラム８２は、選択エントリの処理期間内に処理された外乱ＨＴＴＰリクエストのエントリを取得して（ステップＳ９０３）、上述した（Ｈ１、Ｈ２）のような組を生成する（ステップＳ９０４）。そして、ステップＳ９０１に戻る。
　ステップＳ９０１において、未選択のエントリがない場合（ステップＳ９０１：Ｎｏ）、ＳＱＬ文特定プログラム８２は、ステップＳ９０４で生成された組のうち未選択の組があるか否かを判断する（ステップＳ９０５）。未選択の組がある場合（ステップＳ９０５：Ｙｅｓ）、ＳＱＬ文特定プログラム８２は、外乱ＨＴＴＰリクエストの数が最小の組を選択する（ステップＳ９０６）。
　そして、ＳＱＬ文特定プログラム８２は、選択した組に一致する組があるか否かを判断し（ステップＳ９０７）、ある場合（ステップＳ９０７：Ｙｅｓ）、一致する組を削除して（ステップＳ９０８）、ステップＳ９０４に戻る。一致する組がない場合（ステップＳ９０７：Ｎｏ）、ステップＳ９０５に戻る。ステップＳ９０５において、未選択の組がない場合（ステップＳ９０５：Ｎｏ）、ＳＱＬ文特定プログラム８２は、エントリ削除処理（ステップＳ８０６）を終了して、ステップＳ８０７に移行する。
　このように、実施例１によれば、外乱ＨＴＴＰリクエストが少ない期間を選択することにより、障害原因の特定に用いられるＨＴＴＰリクエストの数を抑制することができる。これにより、計算量の削減を図ることができる。
　また、外乱ＨＴＴＰリクエストの種別を不揃いにすることにより、障害原因の特定に用いられるＨＴＴＰリクエストの数を抑制することができる。これにより、計算量の削減を図ることができる。また、外乱ＨＴＴＰリクエストの種別を不揃いにすることにより、正しくない相関性の強化が抑制され、処理性能に遅延を示したＨＴＴＰリクエストの原因候補となるＳＱＬ文の絞り込み精度の向上を図ることができる。
　（実施例２）
　つぎに、実施例２について説明する。実施例１では、運用管理者からのＳＱＬ文特定の要求を受けてからＳＱＬ文特定プログラム８２がＳＱＬ文の特定処理を実行した。つまり、オンデマンドでＳＱＬ文特定処理を行った。一方、実施例２では、ＳＱＬ文特定プログラム８２が、ＳＱＬ文特定処理をバックグラウンドで予め実行する。ＳＱＬ文特定プログラム８２は、定期的に起動される。ＳＱＬ文特定プログラム８２は、前回起動時以降に追加されたＨＴＴＰリクエスト（以下、「追加ＨＴＴＰリクエスト」）を対象にＳＱＬ文特定処理を実行する。
　すなわち、ＳＱＬ文特定プログラム８２は、前回との差分のみ処理する。これにより、運用管理者がＳＱＬ文特定処理を要求することにより、即座に原因候補となるＳＱＬ文を出力することができる。なお、実施例２の説明において、実施例１と同一構成、同一処理については同一符号を付し、その説明を省略する。
　＜ネットワークシステム１のシステム構成＞
　図１０は、実施例２にかかるネットワークシステム１のシステム構成図である。実施例１との差分は、メモリ１２に、計算済みＨＴＴＰ組み合わせテーブル５０とＨＴＴＰ－ＳＱＬ集計テーブル６０が追加されている点と、ＳＱＬ文特定プログラム８２の動作フローの内容である。
　そして、ＳＱＬ文特定プログラム８２は、ＨＴＴＰリクエストとＳＱＬ文との相関性を計算して、ＨＴＴＰ－ＳＱＬ集計テーブル６０を更新する。このとき、ＳＱＬ文特定プログラム８２は、相関計算に用いた期間に平行処理されていた外乱ＨＴＴＰリクエストの組み合わせを計算済みＨＴＴＰ組み合わせテーブル５０に記録する。ＳＱＬ文特定プログラム８２は、相関計算を行う前に計算済みＨＴＴＰ組み合わせテーブル５０の記録を参照して、手法２により、外乱ＨＴＴＰリクエストの同一組み合わせを削除する。
　＜各テーブルの記憶内容例＞
　図１１は、実施例２にかかるネットワークシステム１で利用するテーブルの記憶内容例を示す説明図である。図１１において、（Ａ）は、計算済みＨＴＴＰ組み合わせテーブル５０の記憶内容例を示す。計算済みＨＴＴＰ組み合わせテーブル５０は、調査対象であるＨＴＴＰリクエスト種別識別子５１ごとに、外乱ＨＴＴＰリクエストの識別子とその種別、および、ＨＴＴＰリクエスト同時実行数を記録する。たとえば、計算済みＨＴＴＰ組み合わせテーブル５０にエントリがない状態で、ＳＱＬ文との対応関係を求めたいＨＴＴＰリクエストの種別が「Ｈ１」であり、「Ｈ１」のＨＴＴＰリクエストが一つ計測されたとする。
　このとき、計算済みＨＴＴＰ組み合わせテーブル５０には、５５ａのエントリが作成される。すなわち、対応関係を求めたいＨＴＴＰリクエストの種別を示すＨＴＴＰリクエスト種別識別子５１が「Ｈ１」であり、処理ホスト別ＨＴＴＰリクエスト同時実行数５３が「１」、同期間に処理されていたＨＴＴＰリクエスト、すなわち、外乱ＨＴＴＰリクエストがないため、外乱ＨＴＴＰリクエスト種別には「（ｎｕｌｌ）」が記録される。なお、ＨＴＴＰリクエスト識別子５２は、「Ｈ１」のＨＴＴＰリクエストの一意識別子であり、ＨＴＴＰ監視データテーブル２０のＨＴＴＰリクエスト識別子２１と同じデータである。
　次に、ＳＱＬ文との対応関係を求めたいＨＴＴＰリクエスト（リクエストの識別子は「１００」）の種別が「Ｈ１」で、「Ｈ１」と同期間に「Ｈ２」の種別を持つＨＴＴＰリクエストが一つ計測されたとする。このとき、計算済みＨＴＴＰ組み合わせテーブル５０には、５５ｂのエントリが作成される。すなわち、ＨＴＴＰリクエスト種別識別子５１が「Ｈ１」、ＨＴＴＰリクエスト識別子５２が「１００」、処理ホスト別ＨＴＴＰリクエスト同時実行数５３が「２」、外乱ＨＴＴＰリクエスト種別５４が「Ｈ２」であるエントリが作成される。
　図１１において、（Ｂ）は、ＨＴＴＰ－ＳＱＬ集計テーブル６０の記憶内容例を示す。ＨＴＴＰ－ＳＱＬ集計テーブル６０は、ＨＴＴＰリクエスト種別識別子６１ごとに、ＨＴＴＰリクエスト処理期間内に計測されたＳＱＬ文の種類（ＳＱＬ識別子６２）の出現回数６３を格納する。たとえば、ＨＴＴＰリクエスト種別識別子が「Ｈ１」であるＨＴＴＰリクエストの処理期間中に、ＳＱＬ識別子が「Ｓ１」であるＳＱＬ文が３０回計測された場合、ＨＴＴＰ－ＳＱＬ集計テーブル６０に６４ａのエントリが作成される。同様に、「Ｓ２」が３回、「Ｓ３」が６回計測された場合、それぞれ６４ｂ、６４ｃのエントリがＨＴＴＰ－ＳＱＬ集計テーブル６０に作成される。
　＜ＳＱＬ文特定処理＞
　図１２は、実施例２にかかるＳＱＬ文特定プログラム８２によるＳＱＬ文特定処理の詳細な処理手順例を示すフローチャートである。ＳＱＬ文特定プログラム８２は定期的に起動され、起動されると、ＳＱＬ文特定プログラム８２は、ＨＴＴＰ監視データテーブルを参照して、未選択の追加ＨＴＴＰリクエストがあるか否かを判断する（ステップＳ１２０１）。
　未選択の追加ＨＴＴＰリクエストがある場合（ステップＳ１２０１：Ｙｅｓ）、ＳＱＬ文特定プログラム８２は、未選択の追加ＨＴＴＰリクエストを１つ選択し（ステップＳ１２０２）、選択した追加ＨＴＴＰリクエストのエントリを、ＨＴＴＰ監視データテーブルから取得する（ステップＳ１２０３）。たとえば、選択追加ＨＴＴＰリクエストのＨＴＴＰリクエスト種別識別子２４が「Ｈ１」である場合、ＳＱＬ文特定プログラム８２は、ＨＴＴＰ監視データテーブルにおいてＨＴＴＰリクエスト種別識別子２４が「Ｈ１」であるＨＴＴＰリクエストを選択し、当該選択したＨＴＴＰリクエストのエントリ５５ａ、５５ｂ、５５ｃ、５５ｄ、５５ｅ，…を取得する。
そして、ＳＱＬ文特定プログラム８２は、ＨＴＴＰ－ＳＱＬ集計テーブル更新処理を実行する（ステップＳ１２０４）。ＨＴＴＰ－ＳＱＬ集計テーブル更新処理（ステップＳ１２０４）は、選択追加ＨＴＴＰリクエストについて、上述した手法１および手法２に応じた処理をバックグラウンドで実行する処理であり、図１３において詳細を後述する。ＨＴＴＰ－ＳＱＬ集計テーブル更新処理（ステップＳ１２０４）のあと、ステップＳ１２０１に戻る。
　そして、未選択の追加ＨＴＴＰリクエストがない場合（ステップＳ１２０１：Ｎｏ）、ＳＱＬ文特定プログラム８２は、処理を終了する。これにより、追加ＨＴＴＰリクエストごとに、バックグラウンドでＳＱＬ文特定処理を実行することができる。
　図１３は、図１２に示したＨＴＴＰ－ＳＱＬ集計テーブル更新処理（ステップＳ１２０４）の詳細な処理手順例を示すフローチャート（前半）である。図１３において、まず、ＳＱＬ文特定プログラム８２は、計算済みＨＴＴＰ組み合わせテーブル５０から、選択追加ＨＴＴＰリクエストとＨＴＴＰリクエスト種別識別子５１が同種別であるエントリの数（エントリ数）を計数する（ステップＳ１３０１）。
　たとえば、選択追加ＨＴＴＰリクエストのＨＴＴＰリクエスト種別識別子５１が「Ｈ１」である場合、ＳＱＬ文特定プログラム８２は、計算済みＨＴＴＰ組み合わせテーブル５０５０においてＨＴＴＰリクエスト種別識別子５１が「Ｈ１」であるエントリ５５ａ、５５ｂ、５５ｃ、５５ｄ、５５ｅ，…のエントリ数を計数する。このエントリ数が、選択追加ＨＴＴＰリクエストの処理ホスト別ＨＴＴＰリクエスト同時実行数となる。
　つぎに、ＳＱＬ文特定プログラム８２は、計数したエントリ数である処理ホスト別ＨＴＴＰリクエスト同時実行数がしきい値以上であるか否かを判断する。しきい値以上である場合（ステップＳ１３０２：Ｙｅｓ）、ＳＱＬ文特定プログラム８２は、ステップＳ１３０３～Ｓ１３０８を実行し、しきい値未満の場合（ステップＳ１３０２：Ｎｏ）、ステップＳ１３０９に移行する。
　ステップＳ１３０１およびＳ１３０２は、選択追加ＨＴＴＰリクエストの関係性計算に十分なデータが既に記録されているか判定する処理である。しきい値以上ある場合（ステップＳ１３０２：Ｙｅｓ）、今回得られた選択追加ＨＴＴＰリクエストが、既存のＨＴＴＰリクエストより有用か否かを判定する処理を実行することになる（ステップＳ１３０３～Ｓ１３０８）。ステップＳ１３０１およびＳ１３０２は、オプションであり、省略してもよい。
　ステップＳ１３０３～Ｓ１３０８について説明する。しきい値以上ある場合（ステップＳ１３０２：Ｙｅｓ）、ＳＱＬ文特定プログラム８２は、選択追加ＨＴＴＰリクエストの処理ホスト別ＨＴＴＰリクエスト同時実行数２２を、ＨＴＴＰ監視データテーブル２０から取得する（ステップＳ１３０３）。取得した選択追加ＨＴＴＰリクエストの処理ホスト別ＨＴＴＰリクエスト同時実行数２２を「Ｎ」とする。たとえば、選択追加ＨＴＴＰリクエストが図３のエントリ２８ｅの場合、Ｎ＝４である。
　つぎに、ＳＱＬ文特定プログラム８２は、計算済みＨＴＴＰ組み合わせテーブル５０を参照して、選択追加ＨＴＴＰリクエストと同種別のＨＴＴＰリクエストの各々について、処理ホスト別ＨＴＴＰリクエスト同時実行数５３を取得し、その中から最大実行数Ｍを特定する（ステップＳ１３０４）。
　たとえば、選択追加ＨＴＴＰリクエストが図３のエントリ２８ｅの場合、ＨＴＴＰリクエスト種別識別子２４は「Ｈ１」である。したがって、ＳＱＬ文特定プログラム８２は、ＨＴＴＰリクエスト種別識別子５１が「Ｈ１」であるエントリ５５ａ、５５ｂ、５５ｃ、５５ｄ、５５ｅ，…の処理ホスト別ＨＴＴＰリクエスト同時実行数５３を計算済みＨＴＴＰ組み合わせテーブル５０から取得する。そして、ＳＱＬ文特定プログラム８２は、その中で最大実行数Ｍを特定する。図１１の計算済みＨＴＴＰ組み合わせテーブル５０の場合、Ｍ＝３となる。
　このあと、ＳＱＬ文特定プログラム８２は、選択追加ＨＴＴＰリクエストの処理ホスト別ＨＴＴＰリクエスト同時実行数Ｎが、最大実行数Ｍより大きいか否かを判断する（ステップＳ１３０５）。大きい場合（ステップＳ１３０５：Ｙｅｓ）、ステップＳ１３０６に移行する。上記の例では、Ｎ＝４、Ｍ＝３であるため、ステップＳ１３０６に移行する。
　一方、選択追加ＨＴＴＰリクエストの処理ホスト別ＨＴＴＰリクエスト同時実行数Ｎが、最大実行数Ｍ以下である場合（ステップＳ１３０５：Ｎｏ）、選択追加ＨＴＴＰリクエストについてのＨＴＴＰ－ＳＱＬ集計テーブル更新処理（ステップＳ１２０４）を終了して、図１２のステップＳ１２０１に戻る。すなわち、過去の処理ホスト別ＨＴＴＰリクエスト同時実行数以下の場合が除外される。これにより、未選択の追加ＨＴＴＰリクエストが選択され、ＨＴＴＰ－ＳＱＬ集計テーブル更新処理（ステップＳ１２０４）が実行される。
　ステップＳ１３０６では、ＳＱＬ文特定プログラム８２は、選択追加ＨＴＴＰリクエストと並列実行されていた外乱ＨＴＴＰリクエストを、ＨＴＴＰ監視データテーブル２０から取得する（ステップＳ１３０６）。具体的には、たとえば、ＳＱＬ文特定プログラム８２は、ＨＴＴＰ監視データテーブル２０から、選択追加ＨＴＴＰリクエストの処理期間（開始時刻２５から終了時刻２６までの期間）に処理されたＨＴＴＰリクエストのエントリ（外乱ＨＴＴＰリクエスト）を取得する。
　図３のエントリ２８ｅの場合、処理期間は開始時刻：２時０分０秒．０００から終了時刻：２時０分５秒．０００までの間の期間となる。この場合、ＳＱＬ文特定プログラム８２は、エントリ２８ｅの処理期間と同一処理期間であるエントリ２８ｆ、２８ｇ、２８ｈである外乱ＨＴＴＰリクエストＨ３～Ｈ５を取得する。なお、外乱ＨＴＴＰリクエストの処理期間は、選択追加ＨＴＴＰリクエストの処理期間に包含される場合のほか、一部が重複する場合や、外乱ＨＴＴＰリクエストの処理期間が、選択追加ＨＴＴＰリクエストの処理期間を包含する場合も含んでもよい。
　つぎに、ＳＱＬ文特定プログラム８２は、選択追加ＨＴＴＰリクエストの外乱ＨＴＴＰリクエストを、計算済みＨＴＴＰ組み合わせテーブル５０から取得する（ステップＳ１３０７）。たとえば、選択追加ＨＴＴＰリクエストのＨＴＴＰリクエスト種別識別子２４が「Ｈ１」である場合、ＳＱＬ文特定プログラム８２は、計算済みＨＴＴＰ組み合わせテーブル５０から同一種別「Ｈ１」のエントリ５５ａ～５５ｅを特定する。そして、ＳＱＬ文特定プログラム８２は、エントリ５５ａ～５５ｅの外乱ＨＴＴＰリクエスト種別５４に記録されているＨ２、Ｈ３、Ｈ４、Ｈ５、Ｈ６、Ｈ７を取得する。
　そして、ＳＱＬ文特定プログラム８２は、「手法２：外乱ＨＴＴＰリクエストの種別を不揃いにする。」に従い、ステップＳ１３０６で取得した外乱ＨＴＴＰリクエストとステップＳ１３０７で取得した外乱ＨＴＴＰリクエストとが重複するか否かを判断する（ステップＳ１３０７）。具体的には、ＳＱＬ文特定プログラム８２は、外乱ＨＴＴＰリクエストのＨＴＴＰリクエスト種別識別子２４と、外乱ＨＴＴＰリクエスト種別５４の重複有無を判断する。
　選択追加ＨＴＴＰリクエストが図３のエントリ２８ｅの場合、ステップＳ１３０６で取得した外乱ＨＴＴＰリクエストはＨ３～Ｈ５であり、ステップＳ１３０７で取得した外乱ＨＴＴＰリクエストはＨ２～Ｈ７である。したがって、外乱ＨＴＴＰリクエストＨ３～Ｈ５が重複することになる。なお、ステップＳ１３０７の重複は、完全一致でもいいし、部分一致でもいい。たとえば、外乱ＨＴＴＰリクエストのうち半数が一致していれば重複と判定してもよい。
　重複する場合（ステップＳ１３０８：Ｙｅｓ）、選択追加ＨＴＴＰリクエストについてのＨＴＴＰ－ＳＱＬ集計テーブル更新処理（ステップＳ１２０４）を終了して、図１２のステップＳ１２０１に戻る。これにより、未選択の追加ＨＴＴＰリクエストが選択され、ＨＴＴＰ－ＳＱＬ集計テーブル更新処理（ステップＳ１２０４）が実行される。
　一方、重複しない場合（ステップＳ１３０５：Ｎｏ）、ステップＳ１３０９に移行する。これにより、重複していない新規追加の外乱ＨＴＴＰリクエストに対して選択追加ＨＴＴＰリクエストを評価することができる。
　このあと、ＳＱＬ文特定プログラム８２は、計算済みＨＴＴＰ組み合わせテーブル５０に、ＨＴＴＰリクエストのエントリを追加する（ステップＳ１３０９）。具体的には、たとえば、ステップＳ１３０８：Ｎｏが実行された場合、ＳＱＬ文特定プログラム８２は、選択追加ＨＴＴＰリクエストと、ステップＳ１３０６で取得された外乱ＨＴＴＰリクエストと、のエントリを追加する。これにより、新規な外乱ＨＴＴＰリクエストが計算済みＨＴＴＰ組み合わせテーブル５０に登録される。
　また、ステップＳ１３０２：Ｎｏの場合には、ＳＱＬ文特定プログラム８２は、選択追加ＨＴＴＰリクエストのエントリを追加する。この場合、当該エントリの外乱ＨＴＴＰリクエスト種別５４は（ｎｕｌｌ）となる。
　そして、ＳＱＬ文特定プログラム８２は、第１の更新処理を実行する（ステップＳ１３０９）。第１の更新処理（ステップＳ１３１０）では、ＳＱＬ文特定プログラム８２は、ＨＴＴＰ－ＳＱＬ集計テーブル６０に対しエントリを追加する更新を実行する。具体的には、ＳＱＬ文特定プログラム８２は、ＨＴＴＰ－ＳＱＬ集計テーブル６０に対し、選択追加ＨＴＴＰリクエストと、その処理期間内に処理されたＳＱＬ文と、当該ＳＱＬ文の出現回数と、を有するエントリを新規追加する。追加済みの場合、ＳＱＬ文特定プログラム８２は、出現回数を更新する。第１の更新処理（ステップＳ１３１０）の詳細については、図１５で後述する。第１の更新処理（ステップＳ１３１０）のあと、図１４のステップＳ１４０１に移行する。
　図１４は、図１２に示したＨＴＴＰ－ＳＱＬ集計テーブル更新処理（ステップＳ１２０４）の詳細な処理手順例を示すフローチャート（後半）である。図１３の第１の更新処理（ステップＳ１３０９）のあと、図１４において、ＳＱＬ文特定プログラム８２は、図１３のステップＳ１３０１と同様、再度、計算済みＨＴＴＰ組み合わせテーブル５０から、選択追加ＨＴＴＰリクエストと同種別のエントリ数である処理ホスト別ＨＴＴＰリクエスト同時実行数を計数する（ステップＳ１４０１）。ステップＳ１３０９によりエントリが追加されているため、ステップＳ１３０１よりも最新の処理ホスト別ＨＴＴＰリクエスト同時実行数が得られる。
　そして、ＳＱＬ文特定プログラム８２は、計数したエントリ数である処理ホスト別ＨＴＴＰリクエスト同時実行数がしきい値以上であるか否かを判断する（ステップＳ１４０２）。このしきい値は、ステップＳ１３０２と同一しきい値である。ステップＳ１４０２の処理は、ステップＳ１３０９で、計算済みＨＴＴＰ組み合わせテーブル５０にエントリが追加されたことで、十分なエントリ数（処理ホスト別ＨＴＴＰリクエスト同時実行数）が得られたか否かを判定する処理である。十分なエントリ数が得られた場合、すなわち、処理ホスト別ＨＴＴＰリクエスト同時実行数がしきい値以上である場合（ステップＳ１４０２：Ｙｅｓ）、ＳＱＬ文特定プログラム８２は、ステップＳ１４０３およびＳ１４０４を実行することにより、余分なエントリを削除する。
　一方、しきい値未満である場合（ステップＳ１４０２：Ｎｏ）、選択追加ＨＴＴＰリクエストについてのＨＴＴＰ－ＳＱＬ集計テーブル更新処理（ステップＳ１２０４）を終了して、図１２のステップＳ１２０１に戻る。これにより、未選択の追加ＨＴＴＰリクエストが選択され、ＨＴＴＰ－ＳＱＬ集計テーブル更新処理（ステップＳ１２０４）が実行される。
　ステップＳ１４０３において、ＳＱＬ文特定プログラム８２は、「手法１：外乱ＨＴＴＰリクエストが少ない期間を選択する。」に従い、計算済みＨＴＴＰ組み合わせテーブル５０から削除条件に該当するエントリを削除する（ステップＳ１４０３）。たとえば、選択追加ＨＴＴＰリクエストが図３のエントリ２８ｅの場合、ＨＴＴＰリクエスト種別識別子２４が「Ｈ１」であるため、計算済みＨＴＴＰ組み合わせテーブル５０において、ＨＴＴＰ種別識別子５１が「Ｈ１」であるＨＴＴＰリクエストのエントリ５５ａ～５５ｅのうち、削除条件に該当するエントリを削除する。
　ここで、削除条件とは、たとえば、処理ホスト別ＨＴＴＰリクエスト同時実行数５３がしきい値以上である。これにより、ＨＴＴＰリクエストを使用する数を抑制することができ、計算負荷の低減を図ることができる。また、当該しきい値以上であり、かつ、処理の開始時刻（終了時刻でもよい）が現在時刻から所定時間前の時点以前の時刻としてもよい。これにより、より古いＨＴＴＰリクエストを対象外とすることができ、障害原因の特定精度の向上を図ることができる。
なお、削除条件としては上述したような古いエントリではなく、処理期間がしきい値以下であることを削除条件にしてもよい。処理時間が長ければ、より多くのＳＱＬ文との関係性を得られる可能性が高いからである。
　このあと、ＳＱＬ文特定プログラム８２は、第２の更新処理を実行する（ステップＳ１４０４）。第２の更新処理（ステップＳ１４０４）では、ＳＱＬ文特定プログラム８２は、ステップＳ１４０３で削除したエントリによる加算分をＨＴＴＰ－ＳＱＬ集計テーブル６０から削除する更新を実行する。第２の更新処理（ステップＳ１４０４）の詳細については、図１６で後述する。
　第２の更新処理（ステップＳ１４０４）のあと、選択追加ＨＴＴＰリクエストについてのＨＴＴＰ－ＳＱＬ集計テーブル更新処理（ステップＳ１２０４）を終了して、図１２のステップＳ１２０１に戻る。これにより、未選択の追加ＨＴＴＰリクエストが選択され、ＨＴＴＰ－ＳＱＬ集計テーブル更新処理（ステップＳ１２０４）が実行される。
　図１５は、図１３に示した第１の更新処理（ステップＳ１３１０）の詳細な処理手順例を示すフローチャートである。まず、ＳＱＬ文特定プログラム８２は、選択追加ＨＴＴＰリクエストの処理期間中に実行されていたＳＱＬ文のエントリを、ＳＱＬ監視データテーブルから取得する（ステップＳ１５０１）。
　具体的には、たとえば、選択追加ＨＴＴＰリクエストが図３のエントリ２８ｅの場合、エントリ２８ｅの処理期間（２時０分０秒．０００～２時０分５秒．０００）に実行されていたＳＱＬ文エントリ３９ｅ～３９ｈをＳＱＬ監視データテーブル３０から取得する。なお、ＳＱＬ文の処理期間は、選択追加ＨＴＴＰリクエストの処理期間に包含される場合のほか、一部が重複する場合や、ＳＱＬ文の処理期間が、選択追加ＨＴＴＰリクエストの処理期間を包含する場合も含んでもよい。
　つぎに、ＳＱＬ文特定プログラム８２は、ステップＳ１５０１で取得したエントリ群のうち未選択エントリのＳＱＬ識別子３１があるか否かを判断する（ステップＳ１５０２）。未選択エントリのＳＱＬ識別子３１がある場合（ステップＳ１５０２：Ｙｅｓ）、ＳＱＬ文特定プログラム８２は、未選択エントリのＳＱＬ識別子３１を選択する（ステップＳ１５０３）。
　そして、ＳＱＬ文特定プログラム８２は、ステップＳ１５０１で取得したエントリ群を選択エントリのＳＱＬ識別子（以下、選択ＳＱＬ識別子）３１ごとに計数することにより、選択ＳＱＬ識別子３１を有するエントリの数を算出する（ステップＳ１５０４）。ステップＳ１５０４で算出したエントリの数を「ＳＱＬ出現数」と称す。
　そして、ＳＱＬ文特定プログラム８２は、選択ＳＱＬ識別子３１について、ＨＴＴＰ－ＳＱＬ集計テーブル６０から、ＨＴＴＰリクエスト種別識別子６１が選択追加ＨＴＴＰリクエストのＨＴＴＰリクエスト種別識別子であり、ＳＱＬ識別子６２が選択ＳＱＬ識別子３１と一致するエントリを特定する（ステップＳ１５０５）。
　たとえば、選択追加ＨＴＴＰリクエストのＨＴＴＰリクエスト種別識別子が「Ｈ１」であり、選択ＳＱＬ識別子が「Ｓ１」である場合、ＳＱＬ文特定プログラム８２は、ＨＴＴＰ－ＳＱＬ集計テーブル６０から、エントリ６４ａを特定する。なお、選択ＳＱＬ識別子３１と一致するエントリがない場合には、ＳＱＬ文特定プログラム８２は、ＨＴＴＰ－ＳＱＬ集計テーブル６０に新たにエントリを作成する。
　このあと、ＳＱＬ文特定プログラム８２は、ステップＳ１５０５で特定したエントリの出現回数６３に、ステップＳ１５０４で算出したＳＱＬ文出現数を加算して保存する（ステップＳ１５０６）。そして、ステップＳ１５０２に戻る。ステップＳ１５０２において、未選択のＳＱＬ文のエントリがない場合（ステップＳ１５０２：Ｎｏ）ＳＱＬ文特定プログラム８２は、第１の更新処理（ステップＳ１３１０）を終了し、図１４のステップＳ１４０１に移行する。これにより、選択追加ＨＴＴＰリクエストの処理期間内に処理されたＳＱＬ文の出現回数（ＳＱＬ出現数）が逐次更新されることになる。
　図１６は、図１４に示した第２の更新処理（ステップＳ１４０４）の詳細な処理手順例を示すフローチャートである。第２の更新処理（ステップＳ１４０４）は、ステップＳ１４０で削除したエントリによる加算分をＨＴＴＰ－ＳＱＬ集計テーブル６０から削除する処理である。第１の更新処理（ステップＳ１３１０）がＨＴＴＰ－ＳＱＬ集計テーブル６０に対しＳＱＬ文出現回数を加算したのに対し、第２の更新処理（ステップＳ１４０４）は、逆に減算する処理である。したがって、ステップＳ１６０１～Ｓ１６０５は、図１５のステップＳ１５０１～Ｓ１５０５と同一処理であるため、説明を省略する。
　ステップＳ１６０６において、ＳＱＬ文特定プログラム８２は、ステップＳ１６０５で特定したエントリの出現回数６３から、ステップＳ１６０４で算出したＳＱＬ文出現数を減算して保存する（ステップＳ１６０６）。そして、ステップＳ１６０２に戻る。ステップＳ１６０２において、未選択エントリがない場合（ステップＳ１６０２：Ｎｏ）ＳＱＬ文特定プログラム８２は、第２の更新処理（ステップＳ１４０４）を終了し、図１２のステップＳ１２０１に戻る。これにより、未選択の追加ＨＴＴＰリクエストが選択され、ＨＴＴＰ－ＳＱＬ集計テーブル更新処理（ステップＳ１２０４）が実行される。
　このように、実施例２によれば、ＨＴＴＰリクエストとＳＱＬ文との対応関係を予め求めておくことで、遅延ＨＴＴＰリクエスト発生時に短時間で原因ＳＱＬ文の候補を特定することができる。したがって、バックグラウンドで外乱ＨＴＴＰリクエストが少ない期間を選択することができ、計算量の削減を図ることができる。また、ステップＳ１３０８に示したように、追加ＨＴＴＰリクエストごとに、バックグラウンドで外乱ＨＴＴＰリクエストの種別を不揃いにすることにより、正しくない相関性の強化が抑制され、処理性能に遅延を示したＨＴＴＰリクエストの原因候補となるＳＱＬ文の絞り込み精度の向上を図ることができる。
　なお、運用管理者が原因ＳＱＬ文の候補を確認したい場合は、図１１のＨＴＴＰ－ＳＱＬ集計テーブルを読み出して画面に表示することにより、その時点で最新の状態を確認することができる。
　また、実施例２では、図１４のステップＳ１４０３において、「手法１：外乱ＨＴＴＰリクエストが少ない期間を選択する。」を適用したが、ＳＱＬ文特定プログラム８２の起動前に手法１を適用してもよい。
　たとえば、ＨＴＴＰ監視プログラム８０が、ＨＴＴＰリクエストとＳＱＬ文との対応関係を特定しやすい期間、すなわち上述した手法１で述べたＨＴＴＰリクエストの処理ホスト別ＨＴＴＰリクエスト同時実行数が所定数以下である期間を検知するごとに、ＳＱＬ文特定プログラム８２を起動する。
　図１７は、実施例２にかかるＨＴＴＰ監視プログラム８０によるＳＱＬ文特定プログラム８２の起動処理の詳細な処理手順例を示すフローチャートである。まず、ＨＴＴＰ監視プログラム８０は、未選択の追加ＨＴＴＰリクエストがあるか否かを判断する（ステップＳ１７０１）。ステップＳ１７０１は、たとえば、上述したＳＱＬ文特定プログラムの起動周期よりも短い周期で判断される。
　未選択の追加ＨＴＴＰリクエストがある場合（ステップＳ１７０１：Ｙｅｓ）、ＨＴＴＰ監視プログラム８０は、ＨＴＴＰ監視データテーブルから未選択の追加ＨＴＴＰリクエストを１つ選択する（ステップＳ１７０２）。つぎに、ＨＴＴＰ監視プログラム８０は、選択追加ＨＴＴＰリクエストの処理ホスト別ＨＴＴＰリクエスト同時実行数をＨＴＴＰ監視データテーブルから取得する（ステップＳ１７０３）。そして、ＨＴＴＰ監視プログラム８０は、ステップＳ１７０３で取得した処理ホスト別ＨＴＴＰリクエスト同時実行数がしきい値以下であるか否かを判断する（ステップＳ１７０４）。
　しきい値以下である場合（ステップＳ１７０５：Ｙｅｓ）、手法１：外乱ＨＴＴＰリクエストが少ない期間を選択する。」を遵守するため、ＨＴＴＰ監視プログラム８０は、ＳＱＬ文特定プログラム８２を起動する（ステップＳ１７０５）。この場合、ステップＳ１７０２の選択追加ＨＴＴＰリクエストについて、図１２のステップＳ１２０３、１２０４が実行される。
　一方、ステップＳ１７０５において、ステップＳ１７０３で取得した処理ホスト別ＨＴＴＰリクエスト同時実行数がしきい値以下でない場合（ステップＳ１７０５：Ｎｏ）、ステップＳ１７０１に戻る。そして、未選択のＨＴＴＰリクエストがない場合（ステップＳ１７０１：Ｎｏ）、ＳＱＬ文特定プログラム８２の起動処理を終了する。
　このように、ＳＱＬ文特定プログラム８２の起動処理によれば、ＳＱＬ文特定プログラム８２の起動前に手法１を適用することができるため、ＳＱＬ文特定プログラム８２における処理性能に遅延を示したＨＴＴＰリクエストの原因候補となるＳＱＬ文の絞り込み処理の効率化を図ることができる。
　また、処理ホスト別ＨＴＴＰリクエスト同時実行数がしきい値以下の場合にＳＱＬ文特定プログラム８２が起動するため、定期的に起動する場合と比較して、必要な場合にのみＳＱＬ文特定プログラム８２を起動することができる。したがって、無断なＳＱＬ特定処理を低減することができ、監視計算機の計算負荷の低減を図ることができる。
　（実施例３）
　つぎに、実施例３について説明する。実施例１および実施例２では、所与の監視データから、ＨＴＴＰリクエストとＳＱＬ文との関係性を求めやすい期間を選択した。実施例３では、逆に、その関係性を求めやすい監視データを作り出す例である。
　実施例１および実施例２におけるＳＱＬ文監視プログラム８１は、ＤＢサーバ９４へのＳＱＬ文の一部しか計測できない。ＳＱＬ文監視プログラム８１が、全ＳＱＬ文を計測すると、計測によるＤＢサーバ９４への負荷が無視できないためである。このため、実施例１および２のＳＱＬ文監視プログラム８１は、計測によるＤＢサーバ９４へ過大な負荷を与えないように、一定の監視間隔でＤＢサーバ９４を計測する。計測時点で処理中のＳＱＬ文に限定して処理時間を計測するため、ＤＢサーバ９４へ与える負荷は小さいが、計測されるＳＱＬ文が一部に限定される。
　一方、実施例３では、ＳＱＬ文監視プログラム８１がＤＢサーバ９４を監視する方法を動的に変更する。上述したように、ＨＴＴＰリクエストとＳＱＬ文との対応関係は、ＨＴＴＰリクエストの数が少ない期間に現れやすい。実施例１におけるＳＱＬ文監視プログラム８１は、全ＳＱＬ文計測と部分ＳＱＬ文計測とをＨＴＴＰリクエスト数に応じて切り替える。
　すなわち、ＨＴＴＰリクエスト数が少ないと推測される期間では全ＳＱＬ文を計測し、それ以外の期間では、実施例１および２と同様に、一部のＳＱＬ文を計測する。なお、実施例３の説明において、実施例１および実施例２と同一構成、同一処理については同一符号を付し、その説明を省略する。
　＜ネットワークシステム１のシステム構成＞
　図１８は、実施例３にかかるネットワークシステム１のシステム構成図である。図１８は、実施例１及び実施例２のシステム構成に、ベースラインテーブル７０を追加したシステム構成である。
　＜ベースラインテーブル７０の記憶内容例＞
　図１９は、図１８に示したベースラインテーブル７０の記憶内容例を示す説明図である。ベースラインテーブル７０は、ＨＴＴＰ監視データテーブル２０の記録から計算した、計算機システム９５の「通常のふるまい（ベースライン）」を記録するテーブルである。ベースラインテーブル７０において、システム７１には、計算機システム９５の種別を示す情報が記録される。ＨＴＴＰリクエスト数ベースライン７２には、計算機システム９５が通常処理するＨＴＴＰリクエスト数のベースラインが記録される。ベースラインの作成方法は一般的な方法でよい。すなわち、監視計算機は、ＨＴＴＰ監視データテーブル２０に記録された過去のＨＴＴＰリクエスト数の記録を統計処理して、時間別のＨＴＴＰリクエスト数平均値（およびその標準偏差）を算出し記録する。
　図２０は、ＳＱＬ文監視プログラム８１による監視モード変更処理手順の詳細な処理手順例を示すフローチャートである。ＳＱＬ文監視プログラム８１は、このフローチャートにしたがって、定期的に計測モードを変更する。まず、ＳＱＬ文監視プログラム８１は、ベースラインテーブル７０から、監視対象の計算機システム９５のＨＴＴＰリクエスト数ベースライン７２を取得する（ステップＳ２００１）。
　つぎに、ＳＱＬ文監視プログラム８１は、ステップＳ２００１で取得したＨＴＴＰリクエスト数ベースライン７２について現在時刻におけるＨＴＴＰリクエスト数を特定し、当該ＨＴＴＰリクエスト数としきい値とを比較する（ステップＳ２００２）。しきい値未満である場合（ステップＳ２００２：Ｙｅｓ）、ＳＱＬ文監視プログラム８１は、ＳＱＬ文監視プログラム８１の計測モードを、全ＳＱＬ計測モードへ変更し（ステップＳ２００３）、処理を終了する。全ＳＱＬ文計測モードとは、ＳＱＬ文監視プログラム８１によりすべてのＳＱＬ文を計測するモードであり、たとえば、パケットキャプチャ方式の場合、キャプチャしたパケットをすべて計測する。
　一方、ステップＳ２００２において、しきい値以上である場合（ステップＳ２００２：Ｙｅｓ）、ＳＱＬ文監視プログラム８１は、ＳＱＬ文監視プログラム８１の計測モードを、定期計測モードへ変更して（ステップＳ２００４）、処理を終了する。定期計測モードとは、ＳＱＬ文監視プログラム８１により１秒間隔など所定時間間隔でＳＱＬ文を計測するモードである。これにより、全ＳＱＬ文計測モードに比べて、計測するＳＱＬ文を間引くことができる。したがって、計算負荷に応じてＳＱＬ文監視処理を実行することができる。
　以上により、ＳＱＬ文監視プログラム８１は、過去の履歴（ベースライン）に基づき計測モードを変更する。通常、ＨＴＴＰリクエスト数が少ない期間には、ＤＢサーバ９４にの多少の負荷が許容される全ＳＱＬ文計測モードが実行され、それ以外の期間では、ＤＢサーバ９４への負荷が少ない定期計測モードが実行される。これにより、ＨＴＴＰリクエストとＳＱＬ文との対応関係を求めやすいＨＴＴＰリクエスト数が少ない期間に、多数のＳＱＬ文を得ることができ、対応関係の取得の効率化を図ることができる。
　なお、実施例３では、全ＳＱＬ文計測モードと定期計測モードとに切り替える例を説明したが、ステップＳ２００３においては、ステップＳ２００４の定期計測モードの計測周期よりも短い周期であってもよい。また、ステップＳ２００２においてＨＴＴＰリクエスト数としきい値とを比較するが、しきい値を複数用意してしきい値に応じて段階的に計測モードの計測周期を変更することとしてもよい。
　以上に説明したように、本発明の実施の形態によれば、外乱ＨＴＴＰリクエストが少ない期間を選択することにより、計算量の削減を図るとともに、外乱ＨＴＴＰリクエストの種別を不揃いにすることにより、処理性能に遅延を示したＨＴＴＰリクエストの原因候補となるＳＱＬ文の絞り込み精度の向上を図ることができる。
　なお、上述した実施の形態では、ＨＴＴＰリクエストとＳＱＬ文との組み合わせについて説明したが、当該組み合わせには限定されない。たとえば、ＨＴＴＰリクエストの替わりに電子メールを適用してもよい。すなわち、異なる２つの独立した方式でデータの流れを観測する場合に適用することができる。同様に、監視対象となる計算機システム９５の構成も、図２、図１０および図１８の構成に限られない。
　なお、実施例１において手法２を適用した場合、監視計算機１０は、第１の装置が受信した第１のリクエスト集合と、第１の装置からの要求により第２の装置で処理された第２のリクエスト集合と、を記憶し、前記第１のリクエスト集合の中の調査対象リクエストと同一種別である同種別リクエスト群を前記第１のリクエスト集合の中から取得し、前記調査対象リクエストおよび前記同種別リクエスト群の各リクエストについて、前記第１の装置から前記第２の装置に送信されてから前記第２の装置から前記第１の装置にレスポンスが送信されるまでの処理期間中に前記第１の装置から前記第２の装置に送信され前記第２の装置から前記第１の装置にレスポンスが送信された、前記調査対象リクエストの種別とは異なる他の種別のリクエストを、前記第１のリクエスト集合の中から取得し、前記調査対象リクエストおよび前記同種別リクエスト群の各リクエストについて、取得しされた前記他の種別のリクエストとの組み合わせを生成し、生成された組み合わせの集合の中から、ある組み合わせ内の前記異なる種別のリクエストと一致する他の組み合わせを削除し、削除後における前記調査対象リクエストおよび前記同種別リクエスト群の各リクエストについて、前記処理期間中に前記第２の装置で処理された第２のリクエストを前記第２のリクエスト集合から取得し、前記削除後における前記調査対象リクエストおよび前記同種別リクエスト群の各リクエストについて、取得した前記第２のリクエストとの相関値を算出し、算出結果を出力する。
　また、実施例１において手法１を適用した場合、監視計算機１０は、第１の装置が受信した第１のリクエスト集合と、第１の装置からの要求により前記第２の装置で処理された第２のリクエスト集合と、を記憶し、前記第１のリクエスト集合の中の調査対象リクエストと同一種別である同種別リクエスト群を前記第１のリクエスト集合の中から取得し、前記調査対象リクエストおよび前記同種別リクエスト群の各リクエストについて、前記第１の装置から前記第２の装置に送信されてから前記第２の装置から前記第１の装置にレスポンスが送信されるまでの処理期間中に前記第１の装置から前記第２の装置に送信され前記第２の装置から前記第１の装置にレスポンスが送信された、前記調査対象リクエストの種別とは異なる他の種別のリクエストを、前記第１のリクエスト集合の中から取得し、前記調査対象リクエストおよび前記同種別リクエスト群のうち、取得された前記他の種別のリクエストの個数が所定数以上、または、昇順で所定順位以下のリクエストを削除し、削除後における前記調査対象リクエストおよび前記同種別リクエスト群の各リクエストについて、前記処理期間中に前記第２の装置で処理された第２のリクエストを前記第２のリクエスト集合から取得し、前記削除後における前記調査対象リクエストおよび前記同種別リクエスト群の各リクエストについて、取得した前記第２のリクエストとの相関値を算出し、算出結果を出力する。
　また、実施例２において手法２を適用した場合、監視計算機１０は、第１の装置が受信した第１のリクエスト集合と、前記第１の装置からの要求により第２の装置で処理された第２のリクエスト集合と、前記第１のリクエスト集合内の第１のリクエストについて前記第１のリクエストと同一種別である同種別リクエスト群が対応付けられた対応情報と、前記第１のリクエストと前記第２のリクエスト集合内の第２のリクエストと前記第２のリクエストの出現数とを関連付けた計数情報と、を記憶し、前記第１のリクエスト集合の中から前記対応情報に追加されていない第１の追加対象リクエストを選択し、選択した前記第１の追加対象リクエストについて、前記第１の装置から前記第２の装置に送信されてから前記第２の装置から前記第１の装置にレスポンスが送信されるまでの処理期間中に前記第１の装置から前記第２の装置に送信され前記第２の装置から前記第１の装置にレスポンスが送信された、前記第１の追加対象リクエストの種別とは異なる他の種別のリクエストを、前記第１のリクエスト集合および前記対応情報の各々の中から取得し、前記第１のリクエスト集合から取得された前記他の種別のリクエストと前記対応情報から取得された前記他の種別のリクエストとが重複するか否かを判定し、重複していない場合、前記対応情報に、前記第１の追加対象リクエストおよび前記第１のリクエスト集合から取得された前記他の種別のリクエストを追加し、前記第１の追加対象リクエストの処理期間中に前記第２の装置で処理された第２の追加対象リクエストと当該第２の追加対象リクエストの出現数とを、前記第２のリクエスト集合から特定し、前記第１の追加対象リクエストと前記第２の追加対象リクエストと前記第２の追加対象リクエストの出現数とに基づいて、前記計数情報を更新する。
　また、実施例２において手法１を適用した場合、監視計算機１０は、第１の装置が受信した第１のリクエスト集合と、前記第１の装置からの要求により前記第２の装置で処理された第２のリクエスト集合と、前記第１のリクエスト集合内の第１のリクエストについて前記第１のリクエストと同一種別である同種別リクエスト群が対応付けられた対応情報と、前記第１のリクエストと前記第２のリクエスト集合内の第２のリクエストと前記第２のリクエストの出現数とを関連付けた計数情報と、を記憶し、前記第１のリクエスト集合の中から前記対応情報に追加されていない第１の追加対象リクエストを選択し、選択した前記第１の追加対象リクエストについて、前記第１の装置から前記第２の装置に送信されてから前記第２の装置から前記第１の装置にレスポンスが送信されるまでの処理期間中に前記第１の装置から前記第２の装置に送信され前記第２の装置から前記第１の装置にレスポンスが送信された、前記第１の追加対象リクエストの種別とは異なる他の種別のリクエストを、前記第１のリクエスト集合の中から取得し、前記対応情報に、前記第１の追加対象リクエストおよび前記第１のリクエスト集合から特定された前記他の種別のリクエストを追加し、前記第１の追加対象リクエストの処理期間中に前記第２の装置で処理された第２の追加対象リクエストと当該第２の追加対象リクエストの出現数とを、前記第２のリクエスト集合から特定し、前記第１の追加対象リクエストと前記第２の追加対象リクエストと前記第２の追加対象リクエストの出現数とに基づいて、前記計数情報を更新し、前記対応情報に追加された前記第１の追加対象リクエストについて、前記第１の追加対象リクエストの種別とは異なる他の種別のリクエストの個数を前記対応情報から計数し、計数結果が所定数以上である場合、前記対応情報に追加された前記第１の追加対象リクエストおよび前記第１のリクエスト集合から特定された前記他の種別のリクエストを前記対応情報から削除し、前記計数情報から前記出現数を減算することにより前記計数情報を更新する。
　以上、本発明を添付の図面を参照して詳細に説明したが、本発明はこのような具体的構成に限定されるものではなく、添付した請求の範囲の趣旨内における様々な変更及び同等の構成を含むものである。

Claims (12)

  1. 　第１の装置および第２の装置に接続される特定装置であって、
    　プログラムを実行するプロセッサと、前記プロセッサが実行するプログラムを格納するメモリと、前記第１の装置との間の通信を制御し、前記第２の装置との間の通信を制御するインターフェースとを備え、
    　前記メモリは、前記第１の装置が受信した第１のリクエスト集合と、前記第１の装置からの要求により前記第２の装置で処理された第２のリクエスト集合と、を記憶し、
    　前記プロセッサは、
    　前記第１のリクエスト集合の中の調査対象リクエストと同一種別である同種別リクエスト群を前記第１のリクエスト集合の中から取得し、
    　前記調査対象リクエストおよび前記同種別リクエスト群の各リクエストについて、前記第１の装置から前記第２の装置に送信されてから前記第２の装置から前記第１の装置にレスポンスが送信されるまでの処理期間中に前記第１の装置から前記第２の装置に送信され前記第２の装置から前記第１の装置にレスポンスが送信された、前記調査対象リクエストの種別とは異なる他の種別のリクエストを、前記第１のリクエスト集合の中から取得し、
    　前記調査対象リクエストおよび前記同種別リクエスト群の各リクエストについて、取得された前記他の種別のリクエストとの組み合わせを生成し、
    　生成された組み合わせの集合の中から、ある組み合わせ内の前記異なる種別のリクエストと一致する他の組み合わせを削除し、
    　削除後における前記調査対象リクエストおよび前記同種別リクエスト群の各リクエストについて、前記処理期間中に前記第２の装置で処理された第２のリクエストを前記第２のリクエスト集合から取得し、
    　前記削除後における前記調査対象リクエストおよび前記同種別リクエスト群の各リクエストについて、取得した前記第２のリクエストとの相関値を算出し、
    　算出結果を出力する、
    ことを特徴とする特定装置。
  2. 　前記プロセッサは、
    　前記調査対象リクエストおよび前記同種別リクエスト群のうち、特定された前記他の種別のリクエストの個数が所定数以上、または、昇順で所定順位以下のリクエストを削除する第１の削除処理を実行し、
    　前記第１の削除処理後における前記調査対象リクエストおよび前記同種別リクエスト群の各リクエストについて、取得された前記他の種別のリクエストとの組み合わせを生成し、
    　生成された組み合わせの集合の中から、ある組み合わせ内の前記異なる種別のリクエストと一致する他の組み合わせを削除する第２の削除処理を実行し、
    　前記第２のリクエストを前記第２のリクエスト集合から取得する処理では、前記第２の削除処理後における前記調査対象リクエストおよび前記同種別リクエスト群の各リクエストについて、前記処理期間中に前記第２の装置で処理された第２のリクエストを前記第２のリクエスト集合から取得し、
    　前記第２のリクエストとの相関値を算出する処理では、前記第２の削除処理後における前記調査対象リクエストおよび前記同種別リクエスト群の各リクエストについて、取得した前記第２のリクエストとの相関値を算出する、
    ことを特徴とする請求項１に記載の特定装置。
  3. 　前記プロセッサは、
    　前記同種別リクエスト群の各リクエストについて、当該リクエストの処理期間の期間長と、前記他の種別のリクエストの個数と、の間に所定強度以上の相関の有無を判定し、
    　所定強度以上の相関がない場合、前記他の種別のリクエストとの組み合わせを生成する、
    ことを特徴とする請求項２に記載の特定装置。
  4. 　前記プロセッサは、
    　前記所定強度以上の相関有りと判定された場合、前記同種別リクエスト群のうち、前記処理期間の期間長がしきい値を超過する同種別リクエストを取得し、
    　前記第２のリクエストを前記第２のリクエスト集合から取得する処理では、前記処理期間の期間長がしきい値を超過する同種別リクエストについて、前記処理期間中に前記第２の装置で処理された第２のリクエストを前記第２のリクエスト集合から取得する、
    ことを特徴とする請求項３に記載の特定装置。
  5. 　前記プロセッサは、
    　前記処理期間中に前記第２の装置で処理された第２のリクエストから、前記同種別リクエストが前記第１の装置に受信される前から前記第２の装置で処理されたリクエストを削除する、
    ことを特徴とする請求項１に記載の特定装置。
  6. 　前記プロセッサは、
    　前記処理期間中に前記第２の装置で処理された第２のリクエストから、処理期間の期間長が一定時間未満のリクエストを削除する、
    ことを特徴とする請求項１に記載の特定装置。
  7. 　前記プロセッサは、
    　前記第１のリクエスト集合の中から操作入力により前記調査対象リクエストを選択することを特徴とする請求項１に記載の特定装置。
  8. 　前記メモリには、前記第１のリクエスト集合のリクエスト数に対する前記第２の装置の経時的な負荷変動の予測値を示す予測情報が記憶されており、
    　前記プロセッサは、
    　現在時刻における負荷変動の予測値を前記予測情報から特定し、
    　特定した前記負荷変動の予測値に応じて前記第２の装置による処理間隔を変更する、
    ことを特徴とする請求項１に記載の特定装置。
  9. 　第１の装置および第２の装置に接続される特定装置に実行させる特定プログラムであって、
    　前記特定装置は、プログラムを実行するプロセッサと、前記プロセッサが実行するプログラムを格納するメモリと、前記第１の装置との間の通信を制御し、前記第２の装置との間の通信を制御するインターフェースとを備え、
    　前記メモリは、前記第１の装置が受信した第１のリクエスト集合と、前記第１の装置からの要求により前記第２の装置で処理された第２のリクエスト集合と、前記第１のリクエスト集合内の第１のリクエストについて前記第１のリクエストと同一種別である同種別リクエスト群が対応付けられた対応情報と、前記第１のリクエストと前記第２のリクエスト集合内の第２のリクエストと前記第２のリクエストの出現数とを関連付けた計数情報と、を記憶し、
    　前記プロセッサに、
    　前記第１のリクエスト集合の中から前記対応情報に追加されていない第１の追加対象リクエストを選択させ、
    　選択した前記第１の追加対象リクエストについて、前記第１の装置から前記第２の装置に送信されてから前記第２の装置から前記第１の装置にレスポンスが送信されるまでの処理期間中に前記第１の装置から前記第２の装置に送信され前記第２の装置から前記第１の装置にレスポンスが送信された、前記第１の追加対象リクエストの種別とは異なる他の種別のリクエストを、前記第１のリクエスト集合および前記対応情報の各々の中から取得させ、
    　前記第１のリクエスト集合から取得された前記他の種別のリクエストと前記対応情報から取得された前記他の種別のリクエストとが重複するか否かを判定させ、
    　重複していない場合、前記対応情報に、前記第１の追加対象リクエストおよび前記第１のリクエスト集合から取得された前記他の種別のリクエストを追加させ、
    　前記第１の追加対象リクエストの処理期間中に前記第２の装置で処理された第２の追加対象リクエストと当該第２の追加対象リクエストの出現数とを、前記第２のリクエスト集合から特定させ、
    　前記第１の追加対象リクエストと前記第２の追加対象リクエストと前記第２の追加対象リクエストの出現数とに基づいて、前記計数情報を更新させる、
    ことを特徴とする特定プログラム。
  10. 　前記プロセッサに、
    　前記対応情報に追加された前記第１の追加対象リクエストについて、前記第１の追加対象リクエストの種別とは異なる他の種別のリクエストの個数を前記対応情報から計数させ、
    　計数結果が所定数以上である場合、前記対応情報に追加された前記第１の追加対象リクエストおよび前記第１のリクエスト集合から特定された前記他の種別のリクエストを前記対応情報から削除させ、
    　前記計数情報から前記出現数を減算することにより前記計数情報を更新させる、
    ことを特徴とする請求項９に記載の特定プログラム。
  11. 　前記プロセッサに、
    　前記対応情報に記憶されている前記第１の追加対象リクエストの種別とは異なる他の種別のリクエストの個数がしきい値以上である場合、前記他の種別のリクエストの重複判定を実行させ、しきい値未満の場合、前記他の種別のリクエストの重複判定を実行させないことを特徴とする請求項９に記載の特定プログラム。
  12. 　前記プロセッサに、
    　前記第１のリクエスト集合に記憶されている前記第１の追加対象リクエストの種別とは異なる他の種別のリクエストの個数が、前記対応情報に記憶されている前記第１の追加対象リクエストの種別とは異なる他の種別のリクエストの個数より大きいか否かを判定させ、
    　大きい場合、前記他の種別のリクエストの重複判定を実行させ、大きくない場合、前記他の種別のリクエストの重複判定を実行させないことを特徴とする請求項９に記載の特定プログラム。
PCT/JP2013/062471 2013-04-26 2013-04-26 特定装置、特定方法、および特定プログラム WO2014174681A1 (ja)

Priority Applications (3)

Application Number Priority Date Filing Date Title
PCT/JP2013/062471 WO2014174681A1 (ja) 2013-04-26 2013-04-26 特定装置、特定方法、および特定プログラム
JP2015513472A JP6031597B2 (ja) 2013-04-26 2013-04-26 特定装置、特定方法、および特定プログラム
US14/427,954 US9705772B2 (en) 2013-04-26 2013-04-26 Identification apparatus, identification method and identification program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2013/062471 WO2014174681A1 (ja) 2013-04-26 2013-04-26 特定装置、特定方法、および特定プログラム

Publications (1)

Publication Number Publication Date
WO2014174681A1 true WO2014174681A1 (ja) 2014-10-30

Family

ID=51791285

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2013/062471 WO2014174681A1 (ja) 2013-04-26 2013-04-26 特定装置、特定方法、および特定プログラム

Country Status (3)

Country Link
US (1) US9705772B2 (ja)
JP (1) JP6031597B2 (ja)
WO (1) WO2014174681A1 (ja)

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016189604A1 (ja) * 2015-05-22 2016-12-01 株式会社日立製作所 電文解析装置及び電文解析方法
WO2017018377A1 (ja) * 2015-07-30 2017-02-02 日本電信電話株式会社 分析方法、分析装置、および分析プログラム
CN106571975A (zh) * 2016-10-19 2017-04-19 武汉斗鱼网络科技有限公司 一种通信数据的容错方法及装置
JP2018532171A (ja) * 2016-09-28 2018-11-01 平安科技（深▲せん▼）有限公司 Ｓｑｌ審査方法、サーバ及び記憶デバイス

Families Citing this family (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
EP2852097B1 (en) * 2013-09-20 2016-08-10 CoScale NV Efficient data center monitoring
KR101842666B1 (ko) * 2013-10-10 2018-05-14 구글 엘엘씨 통신들을 관리하기 위한 시스템들, 방법들 및 컴퓨터 프로그램 제품들
US10218591B2 (en) * 2014-06-23 2019-02-26 Oracle International Corporation Embedded performance monitoring of a DBMS
JP2016031749A (ja) * 2014-07-30 2016-03-07 富士通株式会社 パケット監視装置、パケット監視方法及びパケット監視プログラム

Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006011683A (ja) * 2004-06-24 2006-01-12 Fujitsu Ltd システム分析プログラム、システム分析方法及びシステム分析装置
WO2009025039A1 (ja) * 2007-08-22 2009-02-26 Fujitsu Limited システム分析プログラム、システム分析方法およびシステム分析装置
JP2010176609A (ja) * 2009-02-02 2010-08-12 Fujitsu Ltd 処理時間定義生成プログラム、処理時間定義生成方法及び情報処理装置

Family Cites Families (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP5471859B2 (ja) * 2010-06-10 2014-04-16 富士通株式会社 解析プログラム、解析方法、および解析装置
JP2012198818A (ja) 2011-03-22 2012-10-18 Fujitsu Ltd 分析装置、分析プログラム、分析方法およびシステム

Patent Citations (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2006011683A (ja) * 2004-06-24 2006-01-12 Fujitsu Ltd システム分析プログラム、システム分析方法及びシステム分析装置
WO2009025039A1 (ja) * 2007-08-22 2009-02-26 Fujitsu Limited システム分析プログラム、システム分析方法およびシステム分析装置
JP2010176609A (ja) * 2009-02-02 2010-08-12 Fujitsu Ltd 処理時間定義生成プログラム、処理時間定義生成方法及び情報処理装置

Cited By (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
WO2016189604A1 (ja) * 2015-05-22 2016-12-01 株式会社日立製作所 電文解析装置及び電文解析方法
WO2017018377A1 (ja) * 2015-07-30 2017-02-02 日本電信電話株式会社 分析方法、分析装置、および分析プログラム
JPWO2017018377A1 (ja) * 2015-07-30 2017-12-07 日本電信電話株式会社 分析方法、分析装置、および分析プログラム
US10516685B2 (en) 2015-07-30 2019-12-24 Nippon Telegraph And Telephone Corporation Analysis method, analysis device and analysis program
JP2018532171A (ja) * 2016-09-28 2018-11-01 平安科技（深▲せん▼）有限公司 Ｓｑｌ審査方法、サーバ及び記憶デバイス
CN106571975A (zh) * 2016-10-19 2017-04-19 武汉斗鱼网络科技有限公司 一种通信数据的容错方法及装置
CN106571975B (zh) * 2016-10-19 2020-04-10 武汉斗鱼网络科技有限公司 一种通信数据的容错方法及装置

Also Published As

Publication number Publication date
JPWO2014174681A1 (ja) 2017-02-23
US20150222514A1 (en) 2015-08-06
US9705772B2 (en) 2017-07-11
JP6031597B2 (ja) 2016-11-24

Similar Documents

Publication Publication Date Title
JP6031597B2 (ja) 特定装置、特定方法、および特定プログラム
US9262767B2 (en) Systems and methods for generating statistics from search engine query logs
JP5815563B2 (ja) ｅコマーストランザクションデータ会計のための方法およびシステム
CN104685490B (zh) 结构化和非结构化数据自适应分组的系统和方法
KR101547721B1 (ko) 검출 이벤트에 따른 액션 실행을 지원하는 시스템, 검출 이벤트에 다른 액션 실행을 지원하는 방법, 지원 장치 및 컴퓨터 프로그램
RU2691595C2 (ru) Конструируемый поток данных для улучшенной обработки событий
US10592327B2 (en) Apparatus, system, and method for analyzing logs
JP5479463B2 (ja) 分散型検索の結果のマネタイズおよび優先順位付け
WO2013094032A1 (ja) 情報処理装置、情報処理方法、およびプログラム
CN109558411A (zh) 一种基于区块链数据的下链同步方法及装置
US20130159280A1 (en) Analyzing and Representing Interpersonal Relations
CN105359181A (zh) 基于在线内容评估品牌的价值
US20240104088A1 (en) Real time system for ingestion, aggregation, and identity association of data from user actions performed on websites or applications
US11989251B2 (en) Reconstructing browser interaction from session data having incomplete tracking data
CN106445968B (zh) 一种数据合并方法及装置
EP4120096A1 (en) Method and device for data retrieval, electronic device, and storage medium
WO2019142391A1 (ja) データ分析支援システム及びデータ分析支援方法
US11741131B1 (en) Fragmented upload and re-stitching of journey instances detected within event data
US8326977B2 (en) Recording medium storing system analyzing program, system analyzing apparatus, and system analyzing method
JP2014235632A (ja) 文書管理システム、文書管理システムの制御方法、及び、プログラム
US20220318830A1 (en) Delivery of data-driven & cross-platform experiences based on behavioral cohorts & identity resolution
US20210349884A1 (en) Automated dataset description and understanding
JP2018112876A (ja) 情報処理装置、情報処理方法、およびコンピュータプログラム
JP2019032781A (ja) データ統合支援システム及びデータ統合支援方法
JP5354208B2 (ja) デフォルト値設定システム及びデフォルト値設定方法

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 13883115

Country of ref document: EP

Kind code of ref document: A1

WWE Wipo information: entry into national phase

Ref document number: 14427954

Country of ref document: US

ENP Entry into the national phase

Ref document number: 2015513472

Country of ref document: JP

Kind code of ref document: A

NENP Non-entry into the national phase

Ref country code: DE

122 Ep: pct application non-entry in european phase

Ref document number: 13883115

Country of ref document: EP

Kind code of ref document: A1