Available to All Stackdriver Pro Customers who Sign up by December 31st, 2013
Setting up an effective monitoring solution requires collecting data about the performance and health of your systems on many levels. You want metrics information about the performance of your instance and also some information about any services such as web servers or database servers running on them. You also want to be able to look at data from your cloud provider about the underlying host and any platform services you may depend on. But it’s also incredibly valuable to be able to have an understanding of the availability of your system from the outside to know that it is responding from multiple locations around the world.
Today, we are announcing Stackdriver’s Endpoint Monitoring, which lets you fill in this last piece of monitoring the full stack of your application by setting up periodic checks of an endpoint within your environment from a number of locations around the world and using those to make decisions about the health of your resources and provide actionable alerts.
With Stackdriver Endpoint Monitoring, a customer can configure and see information about how an instance or resource is responding to HTTP requests from multiple locations with all of the other information about those resources. For example, let’s say for example that we want to monitor the health of the Stackdriver data ingest API. This API is exposed as a set of endpoints over HTTPS. We could check one or more of these but we also have a special endpoint, /status, which checks to ensure that all of the backing database and queue connections are functioning normally and returns an error if not. We follow this pattern with all of our HTTP-based services and applications, providing a standard URL to ensure the health of the application or API running on the instance.
When configuring an endpoint check, customers set up the ability to regularly hit a URL via HTTP or HTTPs on an instance or a load balancer. The response of that resource is used to determine the success or failure of the check along with an optional check for a string in the body of the response to help ensure things are functioning correctly.
As with the rest of the Stackdriver, these checks can also be applied to a group of resources within your environment so that they are applied to many resources within your environment as you take advantage of the cloud to grow, shrink and replace your environment without requiring manual reconfiguration of the checks that you use. So if you are using autoscaling to adjust the number of web application nodes running behind an ELB, with Stackdriver you can set up endpoint checks on the ELB as well as on all of the nodes which are a part of your autoscaling group even though the group is dynamically changing based on the demand to your website.
Stackdriver’s endpoint monitoring also ties in with the alerting system to allow you to set up notifications for when a resource is unhealthy. These checks can then notify you via any of the channels that Stackdriver provides for alerting notifications.
Once you receive a notification about one of these violations, you can see when the problem began occurring in the context of all of the other metrics throughout the stack of your application that are being collected, stored and displayed in Stackdriver.
Initially, we are checking the state of your endpoints across three different locations and supporting using HTTP and HTTPs to hit the endpoints.
We’re excited to cover the full stack of your application from the cloud provider all the way to looking at the external health of your application and to bring that all together into one location and look forward to extending the capability in the future!
Note: The endpoint monitoring feature set will be included in a new premium Stackdriver subscription that will be announced later this month. All Stackdriver Pro customers who sign up by December 31st, 2013 will be automatically upgraded to the premium plan at no additional cost.