This post will go over what ThousandEyes is, and why you should be interested in learning how to use it. To see all the posts in this series expand the box below.
- Part 1 – The What and the Why <–You Are Here
- Part 2 – Lab build
- Part 3 – Enterprise and Endpoint Agent Installs
- Part 4.1 – SNMP Monitoring
- Part – 4.2 – Scenarios and Test Types
- Part – 4.3.1 – Scenario 1 – Enterprise agent to agent test configuration
- Part 4.3.2 – Scenario 2 – Enterprise DNS test configuration
- Part – 4.3.3 – Scenario 3 – Enterprise and Endpoint HTTP test configuration (Coming soon)
- Part – 4.3.4 – Scenario 4 – Enterprise Page Load test configuration (Coming less soon)
- Part – 4.3.5 – Scenario 5 – Enterprise Transaction test configuration and Endpoint Agent Browser Settings (Coming more less soon)
- Part – 4.4+ – Details TBD
There are some behind-the-scenes posts that go into more detail on how and why I took the approach that I did. Those can be found here:
- Behind the Scenes – The Lab Build
- Ok, there’s only one so far, but I plan to add more where it makes sense.
What is ThousandEyes?
I’m not in marketing, so I’m going to avoid all the “founded in” type stuff (if you want to read that stuff check out the ThousandEyes site: https://www.thousandeyes.com/about/) Instead, let’s talk about what it means to IT professionals, and more specifically network engineers. ThousandEyes is a monitoring tool (I know, one of many, but hear me out) that takes a different approach to monitoring. We’re all familiar with SNMP monitoring. Links go up, links go down. The problem with this sort of monitoring is … well, it sucks for actual performance monitoring. Sure, I can see the packet rate of a port. I can use Netflow to look at what type of traffic it is. None of this actually tells me how that link, or more importantly the service that uses that link, is performing. More importantly still, what the end-user experience is of that service using that link.
I’ll get more into how ThousandEyes operates shortly, but before that let’s take a look at why we care about it.
Why ThousandEyes?
“It’s slow”
I think it’s safe to say those two words are possibly the most annoying words to hear as an engineer. They are subjective, and often backed with little data. I can’t look for “slow” in SNMP logs. These types of issues typically result in spending hours looking at different interfaces, running tests, and often end with a shrug of the shoulders and either saying it’s a transient issue, or it’s on the other side.
“It’s a network problem”
There’s a phrase that can instantly raise the blood pressure of any network engineer. Again, this statement is often followed with no useful information. After that phrase is uttered the full weight of a Priority 1 outage is squarely focused on the network team, and now they shoulder the burden of proof before anything else happens. I’ve had issues drag on for months because people believed, without evidence, there was a network problem, and no matter what I provided, it wasn’t enough.
I’ve often referred to the Internet as the Wild West. Once traffic leaves the network I manage I lose visibility over it. Tools like Netflow and SNMP no longer help. I can’t leverage things like QoS to prioritize my traffic. Instead, I leave it to the magic of TCP to make sure the traffic gets to the destination. I’ve lost count of the number of calls where I’ve said “I see the traffic egress our perimeter, and it looked fine.” and similar statements.
I could go on, and on, and on. I’d wager most network engineers have had similar experiences.
Enter ThousandEyes
With ThousandEyes we have a tool that helps quickly determine if something is slow, and where that might be occurring. This moves the conversation from the realm of subjective user experience and wild accusations to objective, proactive detection of potential issues. This is done through the use of Agents and Tests (more on those in a future post). By running tests we can see hop-by-hop what is happening with that traffic, and most importantly, we can see it through networks that we don’t own.
What’s the objective of this blog series?
The target audience is primarily network engineers, but application developers, server administrators, and countless other people in the IT field would benefit from knowing what this tool can do.
I’ll be building out a virtual lab topology and running ThousandEyes inside it to show what the tool is capable of.
My goal is to show that the tool is incredibly easy to use and powerful. Over the years I’ve had plenty of vendors talk about how great their product is. Every vendor thinks whatever their product is will be the greatest product ever. I’ve watched sales reps move from vendor to vendor, and each new place happens to have the best widgets and gizmos. No sales pitch here. Just an IT guy that actually thinks this is an awesome tool, and it would be a great addition to most environments.
What’s Next?
