ThousandEyes Peers Into Cloud Performance

While outsourcing applications or infrastructure to the public cloud relieves IT of some operational burdens, IT still has to monitor that infrastructure. Companies often overlook the complexity of troubleshooting a cloud app integrated with local infrastructure. If there’s a performance problem, is it the cloud provider's fault? A congested link on the Internet path between the application and the consumer? A problem on the LAN?

How does one find the root cause without the provider and IT department pointing fingers at each other? This is the problem that ThousandEyes wants to address. ThousandEyes was founded in January 2010 to address the challenge of network performance management in the cloud era. I saw a presentation from ThousandEyes at Network Field Day 6, and have also played with a trial version of the service.

The startup sees the issue of cloud consumption as three separate problem domains for businesses: performance of the local network, performance across the path transiting the Internet and performance of the cloud application or service itself. The company combines metrics from these three domains into one interface that lets customers zoom in on the root problem.

ThousandEyes is itself a cloud service. It gathers performance data using two types of agents. Private agents are Linux packages or virtual machines that are installed by ThousandEyes customers into the customers' infrastructure. Public agents, which are maintained by ThousandEyes, are distributed globally in key locations. The company says it has partnerships pending with a number of cloud providers, but it did not disclose those partners at Network Field Day.

[Cloud services can also protect companies. Find out how in “Cloud-Based Security Helps Aspen Fend Off Malware.”]

The agent performs transactional measurements (such as execute a task much like an end user would) and sends all of its measurements to data collectors maintained by ThousandEyes. The data is organized into a hierarchy of elements that can be reviewed individually, but in the context of the overall transaction.

The service provides real-time monitoring and tracks historical failures. Customers can share failure reports with anyone they like, including their cloud providers. This is a useful feature because a customer can present a provider with hard data about a performance problem, which should (I hope) cut down on finger-pointing.

Next Page: Looking At ThousandEyesOne of the networks I support is running a trial of a couple of private ThousandEyes agents to get a feel for the interface and data generated. To help illustrate the discussion thus far, I've shared a few slightly obfuscated screenshots of the actual ThousandEyes interface.

IT folks should remember that ThousandEyes is a SaaS application. There is no local ThousandEyes server that an IT department must load. The screenshots are taken from the ThousandEyes app running in the cloud.

Once logged in, the Dashboard view presents to the user a summary of the agents running under their account, with some key metrics.

screenshot

In the screen below, I drilled into a view called "Network > Path Visualization". This view shows the end-to-end path between agent and endpoint. In this case, the endpoints happen to be local agents on a private infrastructure. However, ThousandEyes will show the details of an Internet path in the same way. I chose to color links that have higher than 50ms of latency; the link shows up in red here.

While 50ms of latency happens to be completely normal for particular link that traverses a few thousand miles, I wanted to illustrate how ThousandEyes makes it easy to highlight the slowest links in what could be a long chain of links forming an end-to-end path.

screenshot

I also drilled into the "Web > HTTP Server" view. I noticed that during the overnight hours, there was a jump in response time between the private agent and the test HTTPS transaction to google.com. I highlighted the spike on the graph, and ThousandEyes broke down the details of the transaction during that time. A slow DNS lookup becomes quickly obvious as the root cause of the spike.

screenshot

This is valuable in a couple of ways. First, the ability to go back to a point in time is critical. As IT departments frequently are asked to explain issues that happened in the past, being able to look at the historical state of the infrastructure is useful.

Second, the transaction breakdown is equally important. The issue could have been one of at least three things in this case: DNS lookup, initial TCP session establishment, or SSL certificate exchange. In this presentation of the agent data, there's no guesswork required. ThousandEyes points out DNS as the problem.

I chose to share this data with a third party via the "Share This Screen" component of the interface. The idea behind screen sharing is to allow anyone who is not a ThousandEyes user to see an important slice of agent data.

With this tool, an IT department noticing an issue with the Internet pathway or in the cloud application can share the ThousandEyes data with the appropriate parties. That gives everyone in the transaction pathway access to a common baseline of technical knowledge, moving the troubleshooting process along.

screenshot

Third parties receive an email, as shown below, with an embedded link. When they click the link, they are provided unauthenticated access to the very limited data slice you have shared with them.

screenshot

These screenshots are a simple overview of ThousandEyes. You can create more complex HTTP transaction tests and view complete Internet paths. ThousandEyes understands Internet paths along with BGP, and presents that data in views other than what I showed here.

Pricing for ThousandEyes private agents is $99 per agent per month. Private agents are portable, so corporations interested in deploying an agent on-demand to help resolve a temporary problem can do so.

Given that ThousandEyes is a startup, there's not a huge range of transactions available at this point: HTTP, basic TCP, ICMP. Therefore, there's no mechanism to do, say, rich MS Exchange server monitoring. But considering the target market, being able to do rich HTTP transaction monitoring (the bread and butter of SaaS) was the right place for TE to start.

While the pricing model is typical for cloud services (essentially, you lease the service by the month), ThousandEyes could get expensive if you want to run a lot of agents. You need to evaluate what exactly you want to monitor from where, then decide if the cost makes sense. There are other performance monitoring products that are obscenely priced, so $99 per agent per month may sound reasonable to some customers.