JP6471110B2 - Suspected failure location estimation apparatus, failure location estimation method, and failure location estimation program - Google Patents

Description

  The present invention relates to a technique for estimating a suspected failure location on a communication network.

  In order to evaluate the performance of an E2E (End to End) service provided on a communication network, the applicant of the present application has proposed a technique for identifying a degradation location using MIB (Management Information Base) information (patent) Reference 1).

JP 2006-33715 A

However, the technology described in Patent Document 1 assumes an E2E service closed within one operator, and it is difficult to acquire MIB information of other operators. It is difficult to apply to services.
In addition, the technique described in Patent Document 1 collects and analyzes MIB information from all devices on a route even when an E2E service is closed within one service provider when the service is large-scale. It is difficult.

On the other hand, the applicant of the present application has proposed a technique for estimating a suspected failure location in an E2E service across multiple operators (Japanese Patent Application No. 2015-156626, unpublished at the time of application).
In this technique, it is estimated that a node most frequently included in a communication service in which a failure has occurred is a suspected failure location based on a plurality of service monitoring information.

  However, this technique does not mention a specific method of E2E service monitoring. In addition, such a technique targets a single failure and cannot quickly cope with multiple failures. In addition, such a technique requires (estimated) configuration information of an ISP network that is not generally disclosed in order to estimate a suspected failure location.

  The present invention was devised in view of the above circumstances, and a suspected failure location estimating apparatus capable of suitably estimating a suspected failure location even in an E2E service or a large-scale E2E service across multiple operators, It is an object of the present invention to provide a failure suspected place estimation method and a failure suspected place estimation program.

  In order to solve the above-mentioned problem, the present invention is a failure suspected place estimation device that estimates a suspected place in a communication network between a user terminal device and a web server device in a cloud network, a collecting unit that collects web page reading time information relating to the time required for reading the web page, responsiveness information relating to responsiveness in the cloud network, and performance information relating to the performance of the web server device; and the collected web An estimation unit configured to estimate the suspected fault location in the communication network based on page reading time information, the responsiveness information, and the performance information.

  According to such a configuration, a suspected failure location can be suitably estimated even in an E2E service or a large-scale E2E service straddling a plurality of operators.

  The communication network includes a network that connects the user terminal device and the cloud network in a communicable manner, the collection unit collects location information of the user terminal device, and the estimation unit The configuration may be such that when it is estimated that the location is the suspected failure location, the suspected failure location in the network is narrowed down based on the collected location information.

  According to such a configuration, the suspected failure location is narrowed down based on the location information of the user terminal device when the network is the suspected failure location, so that the suspected failure location can be estimated more appropriately.

  Moreover, this invention is a failure suspected place estimation method by the failure suspected place estimation apparatus which estimates the suspected place of failure in the communication network of a user terminal device and the web server apparatus in a cloud network, Comprising: Collection for collecting web page reading time information relating to the time required for reading web pages in each part of the communication network, responsiveness information relating to responsiveness in the cloud network, and performance information relating to the performance of the web server device And a step of estimating the suspected fault location in the communication network based on the collected web page reading time information, the responsiveness information, and the performance information. It is characterized by that.

  The communication network includes a network that connects the user terminal device and the cloud network in a communicable manner, and in the collecting step, the failure suspected place estimating device collects position information of the user terminal device, In the estimation step, when the suspected fault location estimating apparatus estimates that the network is the suspected fault location, the suspected fault location in the network is narrowed down based on the collected location information. There may be.

  The present invention can also be embodied as an API cooperation program that causes a computer to function as the suspected failure point estimation apparatus.

  According to the present invention, it is possible to suitably estimate a suspected failure location even in an E2E service or a large-scale E2E service across a plurality of business operators.

It is a schematic diagram which shows the communication network to which the failure suspected place estimation apparatus which concerns on embodiment of this invention was applied. It is a schematic diagram which shows the web page reading time information measured by NavigationTiming API. It is a table | surface which shows the list of the measured values by NavigationTiming API. It is a table | surface which shows the list of the measured values by CloudWatch API. It is a table | surface which shows the list of the measured value by Geolocation API. It is a figure for demonstrating the method of determining the threshold value of a measured value, (a) is a graph which shows an example of a time-dependent change of a measured value, (b) is a graph which shows an example of a time-dependent change of the ratio of a measured value. It is. It is a flowchart for demonstrating the operation example of a failure suspected location estimation apparatus. It is a flowchart for demonstrating the operation example of a failure suspected location estimation apparatus.

  Next, embodiments of the present invention will be described with reference to the drawings. As shown in FIG. 1, a suspected failure point estimation device 100 according to an embodiment of the present invention is a device that estimates a suspected failure point in a communication network 1 that connects a user terminal device 2 and a web server device 70.

  The communication network 1 is a network 3 on the side of a plurality of user terminal devices 2, a plurality of access networks 20 that are communicably connected to the user terminal devices 2, and a plurality of ISPs (Internet) that are communicably connected to the access network 20. Service Provider) network 30 and an Internet network 40 that is communicably connected to the ISP network 30.

  The access network 20 is a network that is initially connected to the user terminal device 2 and is laid in a range of municipalities or prefectures. The ISP network 30 is a network managed by each telecommunications carrier, and is laid in a wide range across a plurality of prefectures. Here, which ISP network 30 is used when the user terminal device 2 communicates with the web server device 70 is determined or changed by a different rule for each communication carrier.

  In addition, the communication network 1 can communicate with a load balancer (ELB: Elastic Load Balancer) 50 and a load balancer 50 that are connected to the Internet network 40 as a network structure on the web server device 70 side, that is, a cloud network 4. A DC (Data Communication) network 60 to be connected and a plurality of web server devices 70 to be communicably connected to the DC network 60 are provided.

  In addition, the communication network 1 includes a DNS (Domain Name System) server device 80 and an IP Geolocation DB (Internet Protocol Geolocation DataBase) device 90.

  The DNS server device 80 is included in the access network 20, the ISP network 30 or the Internet network 40, has a database in which domain names and IP addresses are associated, and returns a domain name or IP address in response to an inquiry. Device.

  The IP Geolocation DB device 90 is included in the Internet network 40, and is a database in which an IP address is associated with the name and location information (latitude, longitude, etc.) of the device to which the IP address is assigned. In the database, the host name of the device to which the IP address is assigned, the ISP name of the ISP network 30 to which the device belongs, the organization name, coordinates, and the like may be associated with the IP address. As the IP Geolocation DB device 90, database devices such as DB-IP, ipinfo.io, and MAXMIND can be used.

<Sustained failure location estimation device>
The suspected failure location estimation apparatus 100 is a device that estimates a suspected failure location in the communication network 1. The suspected failure point estimation apparatus 100 is configured by a CPU (Central Processing Unit), a ROM (Read-Only Memory), a RAM (Random Access Memory), an input / output circuit, and the like. Unit 102.

≪Collection Department≫
The collection unit 101 collects (acquires) the following information in order to estimate the suspected failure location, and outputs the collected information to the estimation unit 102.
1. 1. Web page read time information measured by a navigation timing API (Application Programming Interface) when the user terminal device 2 accesses the web server device 2. 2. location information of the user terminal device 2 measured by the user terminal device 2 using the Geolocation API; 3. Response information in the cloud network 4 measured by the load balancer 50 using the Cloud Watch API. 4. Performance information of the web server device 70 measured by the web server device 70 using the Cloud Watch API Location information of the web server device 70 stored in the IP Geolocation DB device 90 and ISP information (for example, the name of the ISP network 30, that is, the ISP name)

Here, in the user terminal device 2, for example, a program (Javascript (registered trademark)) for automatically collecting various types of information is inserted by the following three methods.
1. A web server device 70 (web service provider) prepares a web page in which Javascript is embedded in advance.
2. Prepare a proxy, etc., and forcibly insert Javascript into all web pages that pass through the proxy.
3. The user is requested to register a web page in which Javascript is embedded in a bookmarklet or the like of the user terminal device 2.
By executing the Javascript, the user terminal device 2 collects web page reading time information, location information, and access destination URL (Uniform Resource Locater) of the access destination web server device 70, and uses the collected information as Ajax (Asynchronous JavaScript). + XML) or the like, and transmits it to the suspected fault location estimation apparatus 100.

  The collection unit 101 obtains an access destination IP address corresponding to the access destination URL by referring to the DNS server device 80 using the collected access destination URL (nslookup). Subsequently, the collection unit 101 acquires the location information and ISP information of the web server device 70 corresponding to the access destination IP address by referring to the IP Geolocation device using the acquired access destination IP address.

  As a method for collecting the location information of the user terminal device 2 by the Geolocation API, the user terminal device 2 uses getCurrentPosition that acquires the location information only once, watchPosition that periodically monitors and acquires the location information, and watchPosition. Any one of clearWatch that clears the monitoring of position information is used.

  Note that the location information of the user terminal device 2 can also be obtained by the collection unit 101 referring to the IP Geolocation device using the IP address of the user terminal device 2.

<Web page reading time information by Navigation Timing API>
The Navigation Timing API is a method of measuring where and how long it takes in the communication network 1 when the user terminal device 2 displays a web page with a browser. As shown in FIG. 2, the processes measured by the Navigation Timing API include Prompt for unload, redirect, unload, App cache, DNS, TCP, Request, Response, Processing, DOM Content Loaded, and load.

The user terminal device 2 measures the time information shown below as the web page reading time information by the Navigation Timing API, and transmits the measurement result to the suspected failure point estimation device 100.
-StartTime (navigationStart): Prompt for unload end time-redirectStart: redirect start time-redirectEnd: redirect end time-unloadEventStart: unload start time-unloadEventEnd: unload end time-fetchStart: App cache start time-domainLookupStart : DomainLookup start time in DNS server device 80 domainLookupEnd: domainLookup end time in DNS server device 80 connectStart: TCP (Transmission Control Protocol) connection start time secureconnectionStart: TCP secureConnection start time connectEnd: TCP connection End time • requestStart: Request start time • responseStart: Response start time • responseEnd: Response end time • domLoading: Processing start time, byte analysis of HTML (Hyper Text Markup Language) document received by browser first Start time (HTML document itself Body reading start time)
・ DomInteractive: The time when the browser completes the HTML analysis and the DOM (Document Object Model) construction is completed (the reading start time of images and other resources that can be acquired asynchronously when the reading of the HTML document is completed)
-DomComplete: Processing end time, download completion time of all resources (images, etc.) on the web page-domContentLoadedEventStart: DOMContentLoaded start time-domContentLoadedEventEnd: DOMContentLoaded end time-loadEventStart: load start time-loadEventEnd: load End time of

  The collection unit 101 receives the web page reading time information (time information) transmitted by the user terminal device 2, and based on the received web page reading time information, the measured values 01 to 13 (web page reading time information) And the calculated measurement values 01 to 13 are output to the estimation unit 102.

The measured values 01 to 13 will be described with reference to FIG.
The measured value 01 is the total web page reading time.
(Measured value 01) = (loadEventEnd) − (navigationStart)
If the measured value 01 is long, there is a possibility that a failure has occurred somewhere in the communication network 1.
The measured value 02 is the time required for redirect.
(Measured value 02) = (redirectEnd) − (redirectStart)
When the measured value 02 is long, there is a possibility that a failure has occurred in the user terminal device 2.
The measurement value 03 is the time required for unloading.
(Measured value 03) = (unloadEventEnd) − (unloadEventStart)
When the measured value 03 is long, there is a possibility that a failure has occurred in the user terminal device 2.
The measured value 04 is the time required for App cache.
(Measured value 04) = (domainLookupStart)-(fetchStart)
When the measured value 04 is long, there is a possibility that a failure has occurred in the user terminal device 2.
The measured value 05 is a time required for DNS (name resolution).
(Measured value 05) = (domainLookupEnd)-(domainLookupStart)
When the measured value 05 is long, there is a possibility that a failure has occurred in at least one of the user terminal device 2, the access network 20, the ISP network 30, and the DNS server device 80.

The measured value 06 is the time required for internal processing from DNS (name resolution) to TCP-SYN transmission.
(Measured value 06) = (connectStart)-(domainLookupEnd)
When the measured value 06 is long, there is a possibility that a failure has occurred in the user terminal device 2.
The measured value 07 is the time required for the TCP connection process (3-way handshake).
(Measured value 07) = (connectEnd) − (connectStart)
When the measured value 07 is long, at least one of the user terminal device 2, the access network 20, the ISP network 30, the Internet network 40, the DC network 60, the web server device 70, VM (Vertial Machine), and webAPL (APpLication). A failure may have occurred. Here, the web server device 70 is virtualized by mounting virtualization software (Hypervisor or the like) as a virtualization layer on a hardware resource, and one virtual machine for management is used as a VM (Vertial Machine). And a plurality of virtual machines. Further, one or more webAPLs are operating in one VM.
The measured value 08 is the time required for internal processing from TCP connection completion to HTTP request transmission.
(Measured value 08) = (requestStart) − (connectEnd)
When the measured value 08 is long, there is a possibility that a failure has occurred in the user terminal device 2.
The measured value 09 is the time required from the HTTP request transmission to the first HTTP response reception.
(Measured value 09) = (responseStart) − (requestStart)
The measured value 09 is the round trip time of the user terminal device 2 → webAPL → user terminal device 2.
When the measured value 09 is long, there is a possibility that a failure has occurred in at least one of the access network 20, the ISP network 30, the Internet network 40, the DC network 60, the web server device 70, the VM, and the webAPL.
The measured value 10 is the time required for receiving the HTTP request.
(Measured value 10) = (responseEnd) − (responseStart)
The measured value 10 is a one-way passage time of the web APL → user terminal device 2.
When the measurement value 10 is long, there is a possibility that a failure has occurred in at least one of the access network 20, the ISP network 30, the Internet network 40, the DC network 60, the web server device 70, the VM, and the webAPL.

The measurement value 11 is the time required for internal processing from the completion of HTTP response reception to the start of HTML document reading.
(Measured value 11) = (domLoading) − (responseEnd)
When the measured value 11 is long, there is a possibility that a failure has occurred in the user terminal device 2.
The measured value 12 is the time required for reading the HTML document.
(Measured value 12) = (domInteractive) − (domLoading)
When the measured value 12 is long, there is a possibility that a failure has occurred in the user terminal device 2.
The measured value 13 is the time required for reading an image (asynchronously).
(Measured value 13) = (domComplete) − (domInteractive)
When the measured value 13 is long, there is a possibility that a failure has occurred in the user terminal device 2.

<Response information by CloudWatch API>
The CloudWatch API is a method for measuring responsiveness information related to responsiveness in the cloud network 4. The load balancer 50 in the cloud network 4 measures the following responsiveness information using the CloudWatch API, and transmits the measurement result to the failure suspected place estimation apparatus 100.
Latency (unit: seconds): Elapsed time until the load balancer 50 sends a request and receives a response

<Performance information by CloudWatch API>
The CloudWatch API is a method for measuring performance information related to the performance of the web server device 70. The web server device (VM, that is, EC2) 70 measures performance information shown below by CloudWatch API, and transmits the measurement result to the suspected failure point estimation device 100.
-CPU Utilization (unit:%): Ratio of allocated EC2 compute units currently used on the instance-NetworkIn (unit: Byte): Number of bytes received by the specified instance, on one instance Network traffic amount to one application of the network / NetworkOut (unit: Byte): This is the number of bytes transmitted from the specified instance, and the network traffic amount from one application on one instance. In this embodiment, the performance of the web server device 70 It can be said that the performance information is operating state information related to the operating state of the web server device 70.

  The collection unit 101 receives the responsiveness information transmitted by the load balancer 50, calculates measurement values 14-18 (responsiveness information) based on the received responsiveness information, and calculates the calculated measurement values 14-14. 18 is output to the estimation unit 102.

The measurement values 14 to 18 will be described with reference to FIG.
The measured value 14 is an RTT (Round Trip Time) between the load balancer 50 and the webAPL (VM).
(Measured value 14) = (Latency)
When the measured value 14 is long, there is a possibility that a failure has occurred in at least one of the DC network 60, the web server device 70, the VM, and the webAPL.
The measured value 15 is the CPU usage rate of webAPL.
(Measured value 15) = (CPU Utilization)
When the measured value 15 is large, there is a possibility that a failure has occurred in at least one of the web server device 70, VM, and webAPL.
The measurement value 16 is the amount of network traffic flowing into the webAPL.
(Measured value 16) = (NetworkIn)
If the measured value 16 suddenly decreases, a failure has occurred in at least one of the user terminal device 2, the access network 20, the ISP network 30, the Internet network 40, the DC network 60, the web server device 70, and the VM, or There is a risk that the traffic volume is simply decreasing.
The measured value 17 is an outflow amount of network traffic from the webAPL.
(Measured value 17) = (NetworkOut)
When the measured value 17 decreases rapidly, a failure has occurred in at least one of the user terminal device 2, the access network 20, the ISP network 30, the Internet network 40, the DC network 60, the web server device 70, the VM, and the web APL. Or, there is a possibility that the traffic volume is simply decreasing.
The measured value 18 is a traffic processing rate in webAPL.
(Measured value 18) = (NetworkOut) / (NetworkIn)
When the measured value 18 is small, there is a possibility that a failure has occurred in the webAPL.

  Instead of the method in which the collection unit 101 calculates the measured values 01 to 18, the user terminal device 2 and the load balancer 50 calculate the measured values 01 to 18, respectively, and transmit them to the suspected fault location estimating apparatus 100. It may be.

<Location information by Geolocation API>
The Geolocation API is a technique for measuring position information of the user terminal device 2. The user terminal device 2 measures the position information shown in FIG. 5 by the Geolocation API, and transmits the measurement result to the suspected failure point estimation device 100.
・ Latitude: latitude ・ longitude: longitude ・ altitude: altitude ・ accuracy: error in latitude and longitude ・ altitudeAccuracy: error in altitude ・ heading: direction ・ speed: speed

≪Estimation part≫
The estimation unit 102 acquires measurement values 01 to 18 that are collected and calculated by the collection unit 101, and estimates a suspected failure location based on the acquired measurement values 01 to 18. Further, when the estimation unit 102 estimates that the network 3 is a suspected failure location, the estimation unit 102 narrows down the suspected failure location in the network 3 based on the collected location information of the user terminal device 2. The method for estimating and narrowing down the suspected failure location will be described in detail in the following operation example.

<Operation example>
Next, an example of a method for estimating a suspected fault location using the NavigationTiming API and the CloudWatch API (specifically, a method for determining a threshold value after collecting measurement values) will be described with reference to FIGS. In addition, the estimation part 102 detects the quality degradation of E2E service by carrying out threshold determination of each measured value 01-14, and estimates a failure suspected place with the combination of each determination result. The estimation unit 102 sets a threshold value for each of the measurement values 01 to 14 based on an estimation result obtained by performing maximum likelihood estimation of the current measurement value based on the past measurement values, and the threshold value for each of the measurement values 01 to 14 Is stored in the estimation unit 102 in advance. Various distributions, averages, mode values, etc. can be used for setting the threshold. That is, the estimation unit 102 monitors the time change of the measurement values of the plurality of user terminal devices 2, and as shown in FIG. 6A, the measurement value regarding one user terminal device 2 increases rapidly, or FIG. ), It is estimated that there is a suspected failure location when the balance of the measurement values related to one user terminal device 2 with respect to other measurement values is lost. In the following operation example, since the measurement values 07 and 17 are not used, collection of these measurement values 07 and 17 can be omitted.

  As shown in FIG. 7, when the measured value 01 is less than the threshold value (Yes in step S1), the delay is not generated in the E2E service, so the estimation unit 102 is normal in service (no suspected failure location) ) (Step S2).

    On the other hand, when the measured value 01 is equal to or greater than the threshold value (No in step S1), a delay occurs in the E2E (End to End) service. Subsequently, when the measured value 14 is less than the threshold value (Yes in step S3), since no delay has occurred in the cloud network 4, the estimation unit 102 uses the user terminal device 2 and the network 3 (access network 20). The ISP network 30, the Internet network 40, and the DNS server device 80) are determined to have a suspected failure location (step S4).

  On the other hand, when the measured value 14 is equal to or greater than the threshold (No in step S3), a delay occurs in the cloud (the load balancer 50, the DC network 60, and the web server device 70). It is determined that there is a suspected failure location on the cloud side (step S5).

  After step S5, when the measured value 15 is less than the threshold value (Yes in step S11), the web server device 70, VM (Virtial Machine), and webAPL (A Programming Language) are normal, and therefore the estimation unit 102 The DC network 60 is determined to be a suspected failure location (step S12).

  If the measured value 15 is equal to or greater than the threshold (No in step S11) and the measured value 16 is less than the threshold (Yes in step S13), the CPU usage rate is high and the inflow traffic to the webAPL is Since the number has not increased, the estimation unit 102 determines that at least one of the web server device 70, VM, and webAPL is a suspected failure location (step S14).

  Further, when the measured value 16 is equal to or greater than the threshold value (No in step S13) and the measured value 18 is less than the threshold value (Yes in step S15), the inflow traffic amount to the webAPL is increased, and the webAPL Therefore, the estimation unit 102 determines that the webAPL is a suspected failure location (step S16).

  When the measured value 15 is equal to or greater than the threshold value, the measured value 16 is equal to or greater than the threshold value, and the measured value 18 is equal to or greater than the threshold value (No in steps S11, S13, and S15), the CPU usage rate is high and the flow into the webAPL Since the traffic volume increases and the processing rate of webAPL is normal, the estimation unit 102 determines that the service is normal (user usage has increased) (step S17).

  In addition, the threshold determination in steps S11, S13, and S15 may be performed by changing the order, or may be performed in parallel.

  Further, after step S4, as shown in FIG. 8, when any of the measured values 02 to 04, 06, 08, and 11 to 13 is less than the respective threshold values (Yes in step S21), the user terminal device 2 is normal, the estimation unit 102 determines that at least one of the access network 20, the ISP network 30, the Internet network 40, and the DNS server device 80 is a suspected failure location (step S22).

  If the measured value 05 is less than the threshold value after step S22 (Yes in step S23), the access network 20, the ISP network 30, and the DNS server device 80 are normal. It determines with it being a failure suspected location (step S24).

  Further, when the measured value 05 is equal to or greater than the threshold value (No in step S23) and the measured values 09 and 10 are both less than the respective threshold values (Yes in step S25), the access network 20 and the ISP network 30 are normal. Therefore, the estimation unit 102 determines that the DNS server device 80 is a suspected failure location (step S26).

  On the other hand, when the measured value 05 is equal to or greater than the threshold and any of the measured values 09 and 10 is equal to or greater than each threshold (No in steps S23 and S25), the access network 20 and the ISP network 30 are abnormal. Therefore, the estimation unit 102 determines that at least one of the access network 20, the ISP network 30, and the Internet network 40 is a suspected failure location (step S27).

  When the threshold values of the measurement values 02 to 04, 06, 08, and 11 to 13 are both equal to or greater than the respective threshold values (No in step S21), one of the processes in the user terminal device 2 is abnormal. Therefore, the estimation unit 102 determines that the user terminal device 2 is a suspected failure location (step S28).

  In addition, the threshold determination in steps S23 and S25 may be performed by changing the order, or may be performed in parallel.

  In addition, after step S27, the estimation unit 102 determines the failure based on the location information of the user terminal device 2 related to the determination result that at least one of the access network 20, the ISP network 30, and the Internet network 40 is a suspected failure location. The suspected places are narrowed down (step S29). For example, when the position information of the user terminal device 2 from which the determination result is obtained is concentrated in a certain area, the estimation unit 102 estimates that the access network 20 corresponding to the area is a suspected failure location. To do. Moreover, the estimation part 102 will be in the said wide range, when the positional information on the user terminal device 2 from which the said determination result was obtained covers wide range (for example, the range which straddles several (about two or three) prefectures). It is estimated that the corresponding ISP network 30 is a suspected failure location. In addition, the estimation unit 102 estimates that the Internet network 40 is a suspected failure location other than the above, that is, when the position information of the user terminal device 2 from which the determination result is obtained covers a wider range.

The suspected failure location estimation apparatus 100 and the suspected failure location estimation method according to the embodiment of the present invention include web page reading time information (for example, measured by the NavigationTiming API), responsiveness information (for example, measured by the CloudWatch API), and performance information ( For example, the suspected failure location in the communication network 1 is estimated using (measured by CloudWatch API), and therefore the suspected failure location can be suitably estimated even in an E2E service or a large-scale E2E service across multiple operators.
Moreover, the failure suspected place estimation apparatus 100 and the failure suspected place estimation method can indirectly estimate that there is some influence on the trouble suspected place even for services other than the web service.

  Further, the suspected failure point estimation device 100 and the suspected failure location estimation method narrow down the suspected failure location based on the location information of the user terminal device 2 when the network 3 is the suspected failure location, so that the suspected failure location is more suitably selected. Can be estimated.

As mentioned above, although embodiment of this invention was described, this invention is not limited to the said embodiment, In the range which does not deviate from the summary of this invention, it can change suitably. For example, multiple suspected fault locations can be estimated more suitably by using a flow that moves to steps S13 and S15 after steps S12 and S14, or a flow that moves to step S25 after step S24. .
The present invention can also be embodied as a suspected failure location estimation program that causes a computer to function as the failure suspected location estimation apparatus 100.

DESCRIPTION OF SYMBOLS 1 Communication network 2 User terminal device 3 Network 4 Cloud network 70 Web server apparatus 100 Failure suspected part estimation apparatus 101 Collection part 102 Estimation part

Claims (6)

A suspected failure location estimation device for estimating a suspected failure location in a communication network between a user terminal device and a web server device in a cloud network,
A collection unit that collects web page reading time information relating to the time required for web page reading in each part of the communication network, responsiveness information relating to responsiveness in the cloud network, and performance information relating to the performance of the web server device. When,
Based on the collected web page reading time information, the responsiveness information, and the performance information, an estimation unit that estimates the suspected failure location in the communication network;
An apparatus for estimating a suspected fault location, comprising: The communication network includes a network that connects the user terminal device and the cloud network in a communicable manner,
The collection unit collects position information of the user terminal device,
The said estimation part narrows down the said suspected fault location in the said network based on the collected said positional information, when the said network presumes that it is the said suspected fault location. Failure suspected part estimation device. A suspected fault location estimation method by a suspected fault location estimation device that estimates a suspected fault location in a communication network between a user terminal device and a web server device in a cloud network,
Web page reading time information related to the time required for Web page reading in each part of the communication network, the responsiveness information related to the responsiveness in the cloud network, and the performance related to the performance of the web server device. A collection step for collecting information; and
An estimation step in which the suspected failure location estimation device estimates the suspected failure location in the communication network based on the collected web page reading time information, the responsiveness information, and the performance information;
A suspected failure point estimation method characterized by comprising: The communication network includes a network that connects the user terminal device and the cloud network in a communicable manner,
In the collecting step, the failure suspected place estimating device collects position information of the user terminal device,
In the estimation step, the suspected fault location estimating apparatus narrows down the suspected fault location in the network based on the collected location information when the network presumes that the network is the suspected fault location. The method for estimating a suspected fault location according to claim 3. A computer as a suspected failure location estimating device for estimating a suspected failure location in a communication network between a user terminal device and a web server device in a cloud network,
A collection unit that collects web page reading time information relating to the time required for web page reading in each part of the communication network, responsiveness information relating to responsiveness in the cloud network, and performance information relating to the performance of the web server device. ,
Based on the collected web page reading time information, the responsiveness information, and the performance information, an estimation unit that estimates the suspected failure location in the communication network,
Failure suspected part estimation program to function as. The communication network includes a network that connects the user terminal device and the cloud network in a communicable manner,
The collection unit collects position information of the user terminal device,
The said estimation part narrows down the said suspected fault location in the said network based on the collected said positional information, when it presumes that the said network is the said suspected fault location. Failure suspected part estimation program.

Images