Herding Packets

In a prior post, I showed off ThousandEyes and how one of my clients uses it to monitor the BGP routing of their IP prefix. The same client also uses ThousandEyes for monitoring the web apps they host for their customers. Read on to see more about what ThousandEyes does for them!

In my previous post on ThousandEyes, I hinted at excellent web-application performance monitoring capability with ThousandEyes. My client has begun to use the service extensively for monitoring important public- and customer-facing bits of their web presence. This is the dashboard we see when logging in:

Notice that my client uses several private agents. ThousandEyes offers the ability to run tests from their cloud-based agents all over the Internet, but my client decided that the per-test pricing of this option was not as good of a value for them as running a couple of the flat-monthly-fee private agents. What they ended up deploying was a total of 3 private agents. One actually runs internally in their data center, and the other two run in public cloud instances (1&1 and AWS). This gives them data points from several vantage points around the Internet, for a flat monthly fee regardless of how many tests they’re running. In the screenshot above, you can see roll-up and trend stats for a variety of tests including BGP prefix monitoring (in which you can see the BGP routing convergence event that I described in my previous post), basic web server connection tests, and most interestingly, compound web transactions.

Drilling into a web transaction provides details about that transaction:

You can even see I’ve opened up a pop-up that shows the steps involved in the transaction. This compound transaction performs a login to the web app and a basic search transaction. This effectively tests the web server itself, the authentication layer, and the app/db tiers, all in one short transaction. In the background, you can see data on the average time for each step of the transaction. Not visible in the above screenshot is the data from each agent running the test, but clicking on one agent then loads a detailed waterfall diagram for the latest transaction test from that agent:

This waterfall diagram shows a breakdown of the load time of each element of each step of the transaction. Wow. Not that this is unheard of in an application performance tool, but ThousandEyes makes it seriously easy to implement and use.

Next we can view the status of web server test which pulls a single page. Again, note the breakdown of average load time showing DNS look-up time, TCP connect time, SSL negotiation time, etc. Each agent reports its latest stats:

You can see the internal agent running in the same data center has pretty much zero load time, but the agent running on the Internet has more latency for the page load. Not so surprising, but nice to quantify.

My customer’s application provides a different URL for each customer, and so they’ve taken to monitoring each of them from several points:

By testing the login page load for each customer URL from the two public-cloud probes as well as the internal probe, they can quickly correlate a failure or performance issue to an internal or external (of the data center) issue. Also notice in the timeline at the top that response time crept up during the previously described BGP event, but even more interestingly, the alert condition from the BGP event is overlaid on the timeline. This immediately gives the user a good idea of the cause (or at least a related event to investigate) when performance takes a dip.

In the portal settings, users can establish criteria for alert conditions, such as this:

The alert trigger rules are very flexible, and different email destinations can be specified to alert different teams as needed when an alert is triggered.

As you can see, for enterprises who provide a service to the public, external customers, or a remote workforce, ThousandEyes can easily provide insight into availability and performance from around the Internet. Leveraging ThousandEyes’ network of cloud-based probes can offer much more data and any large-scale SaaS provider would almost certainly want to see data from such a large collection of vantage points.

I’ve got another customer who may be looking to use ThousandEyes the “other” way, as a means to monitor the performance and SLA compliance of several critical cloud-based applications/services that they rely on to run their business. I’m looking forward to getting some experience with ThousandEyes in a “look out” deployment as well as the “look in” deployment I’ve already been working with.