JP2009245374A - Load monitoring/analyzing apparatus, method, and program - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a technology for obtaining a warning (influence on service) of an increase in load of a server providing a service corresponding to the kind or content of a message of an application on the basis of a response time of the message (packet including a command or method, and status code) between a client and a server. <P>SOLUTION: A load monitoring/analyzing apparatus includes: a retrieval means 113 for retrieving a method of an SIP message or a status code; a means 114 for calculating a response time or a mean value of the response time on the basis of the time when the method of the SIP message is received or the time when the status code is received; a means 115 for comparing the difference between the response time and the mean value of the response time with a threshold registered in advance; and a threshold table 215. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a load monitoring analysis method, apparatus, and program.

  There are the following server load monitoring methods, but it is not enough to know the sign (impact on the service) of the load increase of the server providing the service corresponding to the message type and content of the application.

  Although the load monitoring of the entire server can be performed using the CPU usage rate of the server, it is difficult to know from the CPU usage rate monitoring to the influence of the service.

  In addition, there is load monitoring using active measurement in which a measurement packet (a GET method is issued for HTTP) is generated and transmitted, and the response time of the server is measured. However, since the measurement packet is generated, there is a problem of reducing the use efficiency of the communication path. On the other hand, there is a passive measurement that monitors traffic between nodes. An example will be described below.

  As an example of application traffic, SIP which is one of call processing protocols of VoIP (Voice over Internet Protocol) is cited. Normally, a SIP server is used for call processing. When the SIP server is overloaded, a status code of 503, for example, is returned to the client in response to a message (method and packet including a status code) from the client. If traffic is monitored focusing on this feature, the load on the SIP server can be grasped. However, when a status code indicating overload is issued, the SIP server is already overloaded, and it is difficult to grasp the signs of the load.

  ITU-T Y.M. 1530 shows call processing quality not limited to a specific protocol. In the VoIP promotion council, ITU-T Y. There is a discussion of applying 1530 to SIP and the like. According to non-patent literature, a connection or disconnection index calculated from the reception time and transmission time of a method and a status code at a terminal is proposed as call processing quality corresponding to SIP. This index is an index including the processing time and network delay of the SIP server existing between terminals.

  The SIP has been described above. When the server is overloaded, the server responds with a status code indicating an overload such as 503 for HTTP and 451 for SMTP.

  For example, Patent Document 1 has been proposed as a service for improving services on a network. Patent Document 1 states that “service levels of a plurality of services are periodically measured, and the measured measurement levels of each service are compared with a preset threshold value. For example, a service is prevented from being deteriorated by assigning a backup server to a service whose measurement level exceeds the threshold when the value exceeds the threshold and reinforcing the server. Measure Internet service level of response time such as HTTP or FTP for each server ”and“ If service level of service A is not satisfied, perform processing to reinforce server for service A ” Has been.

  On the other hand, the SIP application is disclosed in Patent Document 2, and “based on the definition step of the container definition file 61 that defines the call destination of the SIP Servlet container and the call from the SIP Servlet container based on the container definition step, Login or logout processing by calling an authentication action 34 for authenticating a SIP request or SIP response, a location server operation action 36 for connecting to and operating the location server 4, and a registrar action 38 for processing specific to the registrar application. To registrar framework 41, which is a framework for performing the processing, is disclosed. "Method for interpreting SIP packet and extracting SIP method" Is published.

  Furthermore, an example of measuring the response time is introduced in Patent Document 3, which provides “a method of logging information in a computer network having a web client connectable to a web server. In response to an HTTP request. Calculate the response time associated with the first HTTP request (and as a result of receiving a response to the request), then pass the calculated response time from the web client to the web server in a subsequent HTTP request; Log on the web server for later use of the information. In the preferred embodiment, the response time associated with the first HTTP request is passed in the cookie of the second HTTP request ".

  In addition, it has been introduced in Patent Document 4 that a traffic analysis unit obtains statistics of communication between a subscriber and a service server and obtains a response time from the statistics. A packet data analysis apparatus in a mobile communication network for generating billing information for each data service and monitoring the network based on protocol analysis, the packet data analysis apparatus comprising: a mobile communication switch providing a wireless data service to a subscriber; Packet data separation arranged between one of the packet control devices and the service server, and separating and receiving user packet data transmitted between the mobile communication switching device and one of the packet control devices and the service server And the user parameter received through the packet data separator. A traffic analysis unit that divides and analyzes network data according to a transmission direction, a statistical storage unit that stores and manages result data analyzed by the traffic analysis unit, and searches various data stored in the statistical storage unit And a statistical introduction section that provides user-desired statistical information ”.

  However, since the server issues a status code indicating overload at the time of overload, there is a problem that it is impossible to grasp a sign of an increase in load before the server becomes overloaded.

  Further, according to Non-Patent Document 1, the call processing delay is calculated from the reception time and transmission time of the method and status code using the time measurement point as a terminal. It is not known how much time each server between terminals occupies during this call processing delay. In other words, since it is unclear how much time it took each server to process, it is difficult to use call processing delay for the purpose of grasping the precursor of the load increase of each server.

  In status code monitoring indicating overload and time monitoring using the method described in Non-Patent Document 1, knowing the sign of an increase in the load on the server providing the service corresponding to the message type and content of the application (impact on the service) It is difficult.

  In particular, Patent Documents 1 to 4 do not disclose a method for grasping a sign of an increase in load before an overload occurs in SIP.

http: // www. telesa. or. jp / committee / voip / pdf / 0507_IPCall_protocol_ver1. pdf JP 2002-342296 A JP 2007-156971 A Japanese Patent Laid-Open No. 11-110312 JP 2006-506842 A

  Accordingly, an object to be solved by the present invention is to provide a server that provides a service corresponding to the message type and content of an application from the response time of a message (a packet including a command or method and a status code) between a client and a server. It is to provide technology that can grasp the precursors (impact on services) of the increase in the load on the service.

  Advantages obtained by using this technology will be described using SIP as an example. Since it can be seen that priority telephone calls (priority calls) and emergency calls (emergency calls) at the time of a disaster identified by referring to the SIP-URI of the message are connected to a server that has an indication of an increase in load, It is possible to take measures to avoid this in advance. In addition, referring to the SIP-URI of the message, it is possible to select a server with an indication of an increase in load, so that it is possible to expect an increase in the server and a countermeasure for call regulation before the server goes down. Hereinafter, the embodiment will be described using SIP as an example.

  A first invention for solving the above-described problems includes a search means 113 for searching a method and status code of a SIP message, a means for obtaining a response time from the method reception time and status code reception time of the SIP message, The means for obtaining the average value, the comparison means for comparing the difference between the response time and the average value of the response time with a threshold value registered in advance, and before the SIP server issues a status code indicating an overload by the comparison means, And determining means for determining a sign of an increase in load.

  A second invention for solving the above-described problems includes a search step for searching a method and status code of a SIP message, and a step of obtaining an average value of response time and response time from the method reception time and status code reception time of the SIP message. A comparison step that compares the difference between the response time and the average value of the response time with a threshold value registered in advance, and the comparison step provides a sign of an increase in the load on the SIP server before the SIP server issues a status code indicating an overload. And a determination step for determining.

  A third invention for solving the above-mentioned problem is a program for an information device, wherein the program searches the information processing device for a search process for retrieving a SIP message method and status code, a SIP message method reception time, and a status. The SIP server indicates an overload due to the process of obtaining the response time and the average value of the response time from the code reception time, the comparison process comparing the difference between the average value of the response time and the response time with a pre-registered threshold, and the comparison process It is characterized by functioning as a determination process for determining a sign of an increase in the load on the SIP server before issuing a status code.

  According to the present invention, from a response time of a message (a packet including a command or a method or a status code) between a client and a server, a sign of an increase in load on a server providing a service corresponding to the message type and content of the application ( Service impact).

  This is because, for example, in the case of SIP, the load monitoring / analyzing apparatus of the present invention is in the process of attempting a call to the status code indicating that proxy authentication is required for the method (INVITE) of the SIP message or to INVITE. A search means for searching for a status code indicating that there is a means, a means for obtaining an average response time or response time from the method reception time of the SIP message, the status code reception time, a difference between the average value of the response time and the response time, Comparison means for comparing with the registered threshold value, and determination means for judging a sign of an increase in the load on the SIP server before the SIP server issues a status code indicating an overload by checking whether or not the threshold value by the comparison means has been exceeded. Because it has.

  Response time is measured by monitoring traffic between the client and server or between the server and server, and an indication of the increase in the load on the server that provides the service corresponding to the message type and content of the application from the response time (impact on the service) I can know.

  Furthermore, by monitoring the traffic between the client and the server at a location close to the server, the influence of the network delay can be reduced, and a sign of an increase in the load on the server can be grasped more accurately.

  Hereinafter, embodiments of the present invention will be described using a plurality of examples.

  In addition, this invention is not limited to said embodiment, Embodiment can be changed suitably within the range of the technical idea of this invention.

  First, the configuration of the present invention will be described. A first embodiment of the present invention will be described with reference to FIGS. 1 and 10 showing the first embodiment. FIG. 1 is a diagram illustrating an example of a communication system using a load monitoring analysis method according to the present embodiment. The clients 61 and 62 and the servers 63 and 64 are connected to the load monitoring analyzers 71 and 72 via a network. The load monitoring / analyzing devices 71 and 72 perform load monitoring and analysis on the SIP packets of the clients 61 and 62 and the servers 63 and 64. Hereinafter, the load monitoring analyzer 71 will be described as an example. The load monitoring analyzers 71 and 72 have the same configuration.

  FIG. 10 shows the arrangement of the load monitoring / analyzing apparatus by taking a call flow shown in RFC 3665 (http://www.ietf.org/rfc/rfc3665.txt) as an example. The load monitoring / analyzing apparatus performs load monitoring / analysis on the traffic at the load monitoring / analyzing locations 501, 502, and 503 in FIG. Here, it is assumed that the client 61 in FIG. 10 is a speaker and the client 62 is a caller, and the load monitoring analyzer monitors the traffic at the load monitoring analysis points 501 and 502. When the client 61 in FIG. 9 is the called party and the client 62 is the talking party, the load monitoring / analyzing apparatus monitors the traffic at the load monitoring / analyzing points 503 and 502. M1 to M8 in FIG. 10 are numbers given to the messages for the sake of explanation.

  FIG. 2 is a block diagram showing a first embodiment of the present invention. The load monitoring analysis method according to the first embodiment of the present invention includes L2 (OSI reference model layer 2: data link layer), L3 (OSI reference model layer 3: network layer), L4 (OSI reference model layer 4). : Transport layer) termination processing unit 110, protocol identification unit 111, SIP session management unit 112, command, status code extraction unit 113, response time calculation unit 114, determination unit 115, SIP session management table 210, server list 211, command , Status code table 212, response time table 213, reference time table 214, and threshold value table 215.

  The L2, L3, and L4 termination processing units 110 perform termination processing for L2, L3, and L4. Since SIP can use TCP (Transmission Control Protocol), UDP (User Datagram Protocol), and SCTP (Stream Control Transmission Protocol, RFC 2960), stream reconstruction is performed when a TCP or SCTP packet is input.

  The protocol identification unit 111 identifies whether the packet is a SIP packet by the port number (5060), and passes only the SIP packet to subsequent processing. If it is a packet other than SIP, it is discarded. Here, FIG. 3 shows the configuration of the load monitoring analyzers 71 and 72 according to the present invention. A CPU 218 is provided inside the load monitoring analyzers 71 and 72, and the search unit 113, the termination processing unit 110, the response time calculation unit 114, the protocol identification unit 111, the determination unit 115, and the SIP session management unit 112 are in the program area. Stored.

  The SIP session management unit 112 manages the SIP session input to the load monitoring analyzer 71. Compared to the server list 211, only the message addressed to the server by the client or the message addressed to the client by the server is passed to the subsequent processing. The server list is a list of IP addresses of servers that are subject to load monitoring and analysis by the load monitoring and analyzing apparatus 71, and an example is shown in FIG.

  The search unit 113 performs a search to check whether the method and status code indicated in the method / status code list 212 are included in the header field of the SIP packet, and passes them to the response time calculation unit 114 if they match. If there is a mismatch, do nothing. An example of the method / status code list 212 is shown in FIG. A status code indicating that proxy authentication is required for INVITE and a status code indicating that a call is being attempted for INVITE are confirmed.

  FIG. 10 is a call flow for performing authentication only between the client 61 and the server 63. In FIG. 10, when the load monitoring / analysis location is 501, the load monitoring / analyzing apparatus 71 sets the status code 100 (M 6) corresponding to INVITE (M 1) and status code 407 (M 7) corresponding to INVITE (M 1) or INVITE (M 4). ). When the load monitoring / analysis portion is 502 in FIG. 10, the load monitoring / analysis apparatus 72 sets the status code 100 (M8) corresponding to INVITE (M5) as a processing target.

  FIG. 12 shows a call flow (RFC 3665) in which the client 61 authenticates not only the server 63 but also the server 64. The load monitoring and analyzing apparatus 71 includes status code 407 (M2) corresponding to INVITE (M1), status code 100 (M5) corresponding to INVITE (M4), and status code 407 (M9) corresponding to INVITE (M4). ), Status code 100 (M12) corresponding to INVITE (M11) is the processing target.

  Similarly, the load monitoring / analyzing device 72 sets the status code 407 (M7) corresponding to INVITE (M6) and the status code 100 (M14) corresponding to INVITE (M13) to be processed.

  The response time calculation unit 114 refers to the Call-ID and CSeq included in the header field of the SIP packet, and calculates the response time (time difference) from the reception time of the corresponding method and status code. The reception time of the method and the reception time of the status code are times when the load monitoring analyzer 71 receives the packet. The method reception time, status code reception time, and response time are registered in the response time table 213 and the reference time table 214 as shown in FIGS.

  The reference time table is a reference value for determining a sign of an increase in load. As the time registered in the reference time table 214, for example, an average value of response times for each domain of SIP-URI and an average value of response times for each SIP-URI are registered. FIG. 7 is an example showing an average response time for each domain of SIP-URI.

  The reason for processing in SIP-URI units or SIP-URI domain units will be described. An object of the present invention is to detect a sign of an increase in server load. Messages with the same SIP-URI or the same SIP-URI domain can be considered to be processed by the same server. For example, 1) user @ server. com, 2) client @ server. com, 3) user @ example. Consider a SIP-URI called com. It is considered that 1) and 2) are processed by the same server, and the server that processes 3) is different from the server that processes 1) and 2). As described above, the response time is evaluated in SIP-URI units or SIP-URI domain units.

  The determination unit 115 determines a sign of an increase in server load from the response time. When the difference between the response time and the value in the reference time table 214 is larger than the threshold in the threshold table 215, it is determined that there is a sign of an increase in server load.

  Next, the operation will be described. Next, the processing operation of the load monitoring / analyzing devices 71 and 72 according to the present invention will be described with reference to the flowchart showing the processing of the load monitoring / analyzing method in FIG. 9 and the call flow indicated by RFC 3665 in FIG. .

  The processing operation of the load monitoring analyzer 71 will be described below. The load monitoring / analysis device 72 differs in operation from the load monitoring / analysis device 71 because the packet to be processed is different. The load monitoring and analyzing apparatus 71 processes messages between the client and the server, and the load monitoring and analyzing apparatus 72 processes messages between the server and the server.

  When the load monitoring analyzer 71 receives a packet flowing on the network, the L2, L3, and L4 termination processing unit 110 performs termination processing (step S1). In the case of a TCP or SCTP packet, stream reconstruction is performed.

  Next, in order to process only the SIP packet, the protocol identification unit 111 passes only the packet having the port number 5060 to the subsequent processing. Packets other than 5060 are discarded here (step S2).

  The SIP session management unit 112 that has received the SIP packet refers to the source IP, destination IP, SIP-URI, etc. of the IP header of the SIP packet, and performs session management using the SIP session management table 210 (step S3). ). At this time, with reference to the server list 211 as shown in FIG. 4, only packets whose transmission source IP or transmission destination IP matches the IP of the server list are passed to the subsequent processing.

  In order to monitor the traffic between the servers, the load monitoring / analyzing device 71 passes only the packets that match the IPs in the server list to both the transmission source IP and the transmission destination IP.

  Receiving the packet, the search unit 113 performs a search to check whether the method and the status code registered in the status code list 212 are included in the header field of the SIP packet (step S4). A status code indicating that proxy authentication is required for INVITE and a status code indicating that a call is being attempted for INVITE are confirmed.

  When the load monitoring / analysis portion is 501 in FIG. 10, the load monitoring / analysis device 71 processes the status code 407 (M2) corresponding to INVITE (M1) and the status code 100 (M6) corresponding to INVITE (M4). And When the load monitoring / analysis portion is 502 in FIG. 10, the load monitoring / analysis apparatus 72 sets the status code 100 (M8) corresponding to INVITE (M5) as a processing target.

  FIG. 12 shows a call flow (RFC 3665) in which the client 61 authenticates not only the server 63 but also the server 64. When the load monitoring / analysis part is 501 in FIG. 12, the load monitoring / analyzing apparatus 71 uses INVITE (M1), status code 407 (M7) corresponding to INVITE (M4), status code 100 (M5) corresponding to INVITE (M4), and INVITE. The status code 407 (M9) corresponding to (M4) and the status code 100 (M12) corresponding to INVITE (M11) are processed.

  When the monitoring location is 502 in FIG. 12, the status code 407 (M7) corresponding to INVITE (M6) and the status code 100 (M14) corresponding to INVITE (M13) are processed.

  Subsequently, the response time calculation unit 114 registers the method and status code in the response time table 213, and calculates the response time when the method and status code are available (steps S5 and S6). If the received packet includes a method, Call-ID, CSeq, and reception time are registered in the corresponding row (method). The method and the status code are associated with each other by referring to the Call-ID and CSeq included in the header field of the SIP packet. While HTTP and SMTP are aimed at transferring text data (content), SIP focuses on session management. Therefore, in order to realize response time measurement based on the SIP message method and the status code reception time, the correspondence between the method in the session and the status code is made using the Call-ID and CSeq included in the SIP message. Do.

  An example will be described with reference to FIG. FIG. 6 is a response time table 213 in the case of measuring INVITE and 100 corresponding response times. For example, user1 @ server1. Suppose that the speaker INVITE (Call-ID: 12345678@sever1.com) is observed and the SIP-URI, Call-ID, CSeq, and INVITE reception times of the speaker and the caller are recorded in the table. Next, when the status code 100 is observed, the status code Call-ID and CSeq are confirmed. Call-ID is 12345678 @ sever1. com and CSeq are 1 INVITE, so user1 @ server1. com. The status code corresponding to the INVITE of the com, the reception time of the status code 100 is set in the user1 @ server1. com. Since the difference between the INVITE reception time and the 100 reception time corresponding to INVITE is 22 [ms], the response time is 22 [ms]. Further, by referring to the SIP-URI in the response time table 213 in FIG. 6, it can be determined whether the corresponding call is a priority call or an emergency call.

  The final determination unit 115 checks whether (response time obtained by the response time calculation unit 114) − (value indicated by the reference time table 214)> (value indicated by the threshold table 215).

  The threshold value table 215 holds a threshold value for each SIP-URI or each domain of the SIP-URI. FIG. 7 shows the INVITE for each domain and the average response time of 407, and FIG. 8 shows the threshold for each domain of SIP-URI. The processing content for obtaining the average response time will be described later.

  For example, user1 @ server1. com in response to INVITE of 407 is 22 [ms], from FIG. com has an average response time of 20 [ms], the domain server1.com in FIG. Since the threshold value of “com” is 50 [ms], 22 [ms] −20 [ms] = 2 [ms] <50 [ms], which is smaller than the threshold value. Therefore, it is determined that there is no sign of an increase in server load. If it is greater than the threshold, it is determined that there is a sign of an increase in server load (steps S7 and S8).

  The reason for processing in SIP-URI units or SIP-URI domain units will be described. An object of the present invention is to detect a sign of an increase in server load. Messages with the same SIP-URI or the same SIP-URI domain can be considered to be processed by the same server. For example, 1) user @ server. com, 2) client @ server. com, 3) user @ example. Consider a SIP-URI called com. It is considered that 1) and 2) are processed by the same server, and the server that processes 3) is different from the server that processes 1) and 2). As described above, the response time is evaluated in SIP-URI units or SIP-URI domain units.

  As shown in FIG. 10, by monitoring the traffic between the client and the server or between the server and the server and referring to the IP address and the measured response time, it is possible to know how much time it took each server to process. FIG. 10 shows that the client 61 is a speaker and the client 62 is a caller. Therefore, the load monitoring analyzer 71 knows the processing time of the server 63 and the load monitoring analyzer 72 knows the processing time of the server 64. I can do it.

  Further, the load monitoring and analyzing apparatus 71 can grasp which client's message is affected by the processing time of the server 63 by referring to the From SIP-URI. Also, by referring to From, it is possible to grasp which client message is affected by the processing time of the server 64.

  In FIG. 10, a load monitoring / analyzing apparatus is installed at the load monitoring / analyzing locations 501 and 502 to monitor the traffic. As shown in FIG. 12, the probe device may be installed at the load monitoring / analysis places 501 and 502, and the probe device and the load monitoring / analysis device may be connected. The probe device can perform processing equivalent to that in FIG. 10 by passing the monitored traffic to the load monitoring analyzer.

  Next, the processing contents for obtaining the average response time will be described with reference to FIG. Steps S1 to S6 in FIG. 11 are the same as steps S1 to S6 in FIG. The response time is registered as shown in FIG. 6. When the number of called parties having a domain for which an average response time is desired reaches the number preset by the network administrator (step S51), the response time of the domain Is averaged to obtain an average response time (step S52).

  Acquisition of the average response time may be performed in parallel with the normal processing of FIG. Further, the normal process of FIG. 9 may not be executed, and only FIG. 11 may be executed.

  14 to 18 show examples in which the load monitoring analysis method according to the second embodiment of the present invention is applied to an SMTP protocol server. In the second embodiment, in FIG. 14, clients 702 and 704 and servers 706 and 708 are connected to load monitoring / analyzing apparatuses 710 and 712 via a network. The load monitoring / analysis apparatuses 710 and 712 perform load monitoring and analysis on the SMTP packets of the clients 702 and 704 and the servers 706 and 708. Hereinafter, the load monitoring analyzer 710 will be described as an example. The load monitoring analyzers 710 and 712 have the same configuration.

  FIG. 15 is a flowchart showing a third embodiment of the present invention. The load monitoring analysis system according to the third embodiment of the present invention includes an L2, L3, L4 termination processing unit 110, a protocol identification unit 111, an SMTP session management unit 724, a command, status code extraction unit 113, and a response time calculation unit 114. , Determination section 115, SMTP session management table 728, server list 211, command, status code table 212, response time table 213, reference time table 214, and threshold value table 215. The block having the same name as FIG. 3 in the first embodiment according to the present invention is a block having the same function.

  In particular, functions different from those of the first embodiment will be described. The protocol identification unit 111 identifies whether the packet is an SMTP packet by using the port number (25), and passes only the SMTP packet to subsequent processing.

  The SMTP session management unit 724 manages the SMTP session input to the load monitoring analysis device 710. Compared to the server list 211, only the message addressed to the server by the client or the message addressed to the client by the server is passed to the subsequent processing.

  The search unit 113 performs a search to check whether the command and reply code shown in the command / reply code list 212 are included in the header field of the SMTP packet. If there is a mismatch, do nothing. An example of the command / reply code list 212 is shown in FIG. Check the Positive Preliminary reply for the command.

  Next, the operation will be described. The processing operation of the load monitoring and analyzing apparatus 720 according to the present invention will be described with reference to the flowchart showing the processing of the load monitoring and analyzing method in FIG. Each process is the same as that of Example 1 except step SC3. In particular, step SC3 different from the first embodiment will be described.

  Next, in order to process only the SMTP packet, the protocol identification unit 111 passes only the packet whose port number is 25 to the subsequent processing. Packets other than 25 are discarded here (step SB2).

  The SMTP session management unit 724 that has received the SMTP packet refers to the source IP, destination IP, From, To, and the like of the IP header of the SMTP packet, and performs session management using the SMTP session management table 728 (step SB3 ).

  The final determination unit 115 checks whether (response time obtained by the response time calculation unit 114) − (value indicated by the reference time table 214)> (value indicated by the threshold table 215). The threshold value table 215 holds a threshold value for each mail address or each domain of the mail address.

It is a figure which shows an example of the communication system using the SIP load monitoring analyzer in a present Example. It is a block diagram which shows the structure of the 1st Example in this invention. It is a block diagram which shows the structure of the 1st Example in this invention. It is a figure which shows the example of the server list | wrist of 1st Example in this invention. It is a figure which shows the example of the method of 1st Example in this invention, and a status code list. It is a figure which shows the example of the response time table of 1st Example in this invention. It is a figure which shows the example of the reference | standard time table of 1st Example in this invention. It is a figure which shows the example of the threshold value table of 1st Example in this invention. It is a figure which shows the processing flow of 1st Example in this invention. It is a flowchart which shows the 1st Example in this invention. It is a figure which shows the processing flow of the reference | standard data generation of 1st Example in this invention. It is a flowchart which shows the 1st Example in this invention. It is a figure which shows an example of the communication system using the SMTP load monitoring analyzer of the 2nd Example in a present Example. It is a block diagram which shows the structure of the 2nd Example in this invention. It is a flowchart which shows the 2nd Example in this invention. It is a figure which shows the example of the threshold value table of 2nd Example in this invention.

Explanation of symbols

61, 62 Client 63, 64 Servers 71, 72, 73 Load monitoring analyzer 110 L2, L3, L4 termination processing unit 111 Protocol identification unit 112 SIP session management unit 113 Search unit 114 Response time calculation unit 115 Determination unit 210 SIP session management Table 211 Server list 212 Method, status code table 213 Response time table 214 Reference time table 215 Threshold table 501, 502, 503 Load monitoring analysis location 702, 704 Client 706, 708 Server 710, 712 Load monitoring analysis device 724 SMTP session management unit 728 SMTP session management table

Claims (13)

Search means for searching application traffic methods and status codes,
Means to determine the average response time and response time from the application traffic method reception time and status code reception time,
Comparison means for comparing the difference between the response time and the average value of the response time with a threshold value registered in advance,
A load monitoring / analyzing apparatus comprising: a determination unit configured to determine a sign of a server load increase before the server issues a status code indicating an overload by the comparison unit. Search means for searching application traffic methods and status codes,
Means to obtain the average response time and response time from the method reception time and status code reception time between the server and the client,
Comparison means for comparing the difference between the response time and the average value of the response time with a threshold value registered in advance,
Determining means for determining a sign of an increase in server load before the server issues a status code indicating an overload by the comparing means;
A load monitoring / analyzing apparatus for performing load monitoring / analysis of traffic between a client and a server or between a server and a server.   The response time and the average value of the response time are calculated for each URI (Uniform Resource Identifier) or address or URI or address domain, and the threshold is defined for each URI or address or URI or address domain. The load monitoring and analyzing apparatus according to claim 1 or 2.   Means for obtaining the response time and the average value of the response time are the response time of the status code indicating that proxy authentication is required for the SIP (Session Initiation Protocol) INVITE message, the average value of the response time, and the SIP INVITE. 3. The load monitoring / analyzing apparatus according to claim 1, wherein a response time of a status code indicating that a call is being attempted for a message and an average value of response times are obtained.   The means for obtaining an average value of the response time and the response time is to obtain an average value of the response time and the response time of a status code indicating a positive preparative reply for an SMTP (Simple Mail Transfer Protocol) message. Item 3. The load monitoring analyzer according to Item 1 or 2. A search step to search for application traffic methods and status codes;
Obtaining the average response time and response time from the application traffic method reception time and status code reception time;
A comparison step for comparing the difference between the average value of the response time and the response time with a threshold value registered in advance;
A load monitoring analysis method comprising: a step of determining, by the comparison step, a sign of an increase in server load before the server issues a status code indicating overload. A search step to search for application traffic methods and status codes;
The method of obtaining the average response time and response time from the method reception time and status code reception time between the server and the client,
A comparison step for comparing the difference between the average value of the response time and the response time with a threshold value registered in advance;
A step of determining, by the comparison step, a sign of an increase in the load on the server before the server issues a status code indicating an overload;
A load monitoring and analyzing method, characterized by performing load monitoring and analyzing traffic between a client and a server or between a server and a server by passive measurement.   7. The response time or an average value of the response time is calculated for each URI or address or URI or address domain, and the threshold is defined for each URI or address or URI or address domain. 7. The load monitoring analysis method according to 7.   The step of obtaining the response time and the average value of the response time includes the response time of the status code indicating that proxy authentication is required for the SIP INVITE message, the average value of the response time, and the call response to the SIP INVITE. 9. The load monitoring / analyzing method according to claim 7, wherein a response time of a status code indicating that a trial is being performed and an average value of response times are obtained. A program of an information device, wherein the program searches the information processing device for a method and a status code of application traffic;
Processing to obtain the average response time and response time from the application traffic method reception time and status code reception time,
Comparison processing for comparing the difference between the average value of the response time and the response time with a threshold value registered in advance,
The comparison function causes the server to function as a determination process for determining a sign of an increase in server load before issuing a status code indicating an overload. An information device program, wherein the program is an information processing device,
Search processing to search application traffic methods and status codes,
Processing to obtain the average response time and response time from the method reception time and status code reception time between the server and client,
Comparison processing for comparing the difference between the average value of the response time and the response time with a threshold value registered in advance,
A determination process for determining a sign of an increase in server load before the server issues a status code indicating an overload by the comparison process;
12. The program according to claim 11, wherein the program functions to perform load monitoring and analysis of traffic between a client and a server or between a server and a server by passive measurement. An information device program, wherein the program is an information processing device,
The average value of the response time or response time is calculated for each URI or address or URI or address domain, and the threshold is defined and functioned for each URI or address or URI or address domain. Item 11. The program according to Item 11. An information device program, wherein the program is an information processing device,
The processing for obtaining the average response time and response time is a status code response time and response time average value indicating that proxy authentication is required for SIP INVITE,
10. The program according to claim 9, wherein a response time of a status code indicating that a call is being attempted in response to a SIP INVITE message and an average value of response times are obtained and functioned.

Images