FIELD

The described embodiments relate generally to network-based services. More particularly, the present embodiments relate to a technique for monitoring a status of network-based services that include service dependencies.

BACKGROUND

Cloud-based services have become ubiquitous in today's digital economy. Mobile devices include a large number of applications configured to request data from one or more services accessed via the Internet. For example, a ride-sharing application can be utilized to order a car that is directed to pick a user up at a location provided by a global positioning system (GPS) sensor in the user's mobile device. Real-time data such as stock prices and sports scores can be delivered to an application that aggregates data on a display screen. A cloud-based storage service enables files to be shared or processed by a number of devices permitted to access to the cloud-based storage service. A cloud-based computing service enables large quantities of computing power located in remote data centers to be utilized by a client device on demand to solve complex problems that involve large amounts of computations (e.g., processing of raw scientific data). The examples of types of services that have been implemented on the Internet are substantial in diversity and number.

Notably, a service can be deployed in multiple regions and multiple availability zones within each region in order to ensure high-availability of the service to client devices. Redundancy is one way to eliminate single points of failure, which involves establishing service instances on servers in multiple availability zones at varying geographic locations around the world. The Domain Name System (DNS) provides a means for locating a service endpoint on the Internet by associating or responding to a lookup by host name with a network address such as an Internet Protocol (IP) version 4 (IPv4) or version 6 (IPv6) network address. Additionally, the DNS servers can employ or integrate a capability to monitor the statuses of the services across the different IP addresses as part of the DNS system itself. In turn, the DNS servers can add or remove associations between a host name for the service and different IP addresses based on the status of the service. In this manner, the requests from client devices directed to the host name for the service can be prevented from being transmitted to a service instance that is experiencing downtime. Unfortunately, conventional techniques for monitoring the status of a service are poorly implemented. For example, services can be classified as unavailable when a problem is related to dependencies associated with other services that are experiencing downtime. Furthermore, when a service is classified as unavailable, techniques for reclassifying the service as available (when appropriate) are typically ineffective, thereby increasing the downtime perceived by the client devices.

SUMMARY

In view of the foregoing, what is desired is an improved technique for monitoring the status of a service with various service dependencies. Accordingly, and as set forth in greater detail herein, this application describes various embodiments that relate to a technique for (1) determining a status of a service instance, and (2) reporting the status of the service instance to a health check engine upstream of the service instance, thereby enabling a Domain Name System (DNS) server to classify, with accuracy and speed, an association of a host name for the service and a network address corresponding to the service instance.

According to some embodiments, a DNS server can implement a health check engine that monitors the status of a service in order to implement round-robin DNS services among a plurality of regions and/or availability zones. In this regard, each service instance for the service can include a monitoring agent configured to (1) monitor the status of the service instance, and (2) respond to health check messages received from the health check engine. According to some embodiments, the monitoring agent can be configured to (1) collect statistics associated with one or more service dependencies of the service instance during a tracking window, (2) calculate at least one ratio based on the statistics collected during the tracking window, and (3) generate the status of the service instance by comparing the at least one ratio to a threshold value.

In some embodiments, the monitoring agent for a service instance collects statistics associated with each service dependency in one or more service dependencies. According to some embodiments, the statistics for a service dependency associated with a network interface can include one or more of (1) a number of additional requests transmitted to the service dependency via the network interface, (2) a number of successful responses received from the service dependency, and (3) a number of failed responses received from the service dependency, where the statistics are collected during a period of time. In turn, the monitoring agent analyzes the statistics to determine a status of the service instance. The status of the service instance reflects, in the aggregate, the status of each service dependency of the one or more service dependencies. In various embodiments, the monitoring agent can be configured to calculate, for each service dependency, a ratio of successful responses to failed responses received from the service dependency. The status of the service instance is then determined by comparing each ratio associated with a service dependency to a threshold value. In particular, the status of the service instance is construed as a first state (e.g., positive) when the ratio for each service dependency is above the threshold value, and construed as a second state (e.g., negative) when the ratio for any service dependency is below the threshold value.

In some embodiments, the monitoring agent monitors the responses generated by the service instance to determine the status of the service instance instead of monitoring the responses received from the service dependencies. The responses generated by the service instance will reflect the responses received from the service dependencies, in the aggregate, because any failed response received from a service dependency will cause the response generated by the service instance to also be a failed response. Additionally, the monitoring agent can be configured to calculate a ratio of successful responses to failed responses generated by the service instance, and compare the ratio to a threshold value to determine a status of the service instance.

In some embodiments, the statistics are checked to determine if the ratio is statistically relevant before determining the status of the service instance. When the statistics collected during the tracking window indicate that the ratio is based on a number of requests received by the service instance during the tracking window—or, alternatively, a number of additional requests transmitted to one or more of the service dependencies during the tracking window—that is less than a threshold value, the status of the service instance is maintained as determined during a previous tracking window.

In some embodiments, a server computing device can implement a load balancer for a service that includes a distributed implementation of a number of service instances executing on a plurality of server computing devices. According to some embodiments, the load balancer can include a monitoring agent configured to monitor the status of the service based on the status of each of the service instances. In particular, the monitoring agent can be configured to (1) receive a health check message from a health check engine over a network interface, (2) generate a status of the service based on the status of the service instances, and (3) transmit the status of the service to the health check engine. In some embodiments, the monitoring agent can be configured to (1) forward the health check message to the service instances, (2) receive a response to the health check message from each service instance, (3) calculate a ratio based on a number of positive responses and a number of negative responses in the responses received from the service instances, and (4) compare the ratio to a threshold value to determine the status of the service.

In some embodiments, the status of a service instance or the status of the service can be reflected in a hypertext transfer protocol (HTTP) response message. In particular, a status code and/or a status message can be selected and included in the HTTP response message that reflects a state of the status of the service or service instance. According to some embodiments, the selected status code can be a standard HTTP status code (e.g., 200 Okay, 503 Service Unavailable, etc). However, custom status codes and/or status messages can also be included in the HTTP response message to indicate the state of the status of a service or service instance. Alternatively, a message body of the HTTP response message can reflect the state of the status of the service or service instance.

Other aspects and advantages of the application will become apparent from the following detailed description taken in conjunction with the accompanying drawings which illustrate, by way of example, the principles of the described embodiments.

