Thank you to everyone who joined SDxCentral for its latest DemoFriday featuring ThousandEyes on network analytics. Attendees got to see an exciting demo on utilizing the ThousandEyes technology to sniff out broken links, bogged-down interfaces, routing mishaps, as well as ISP problem areas. After the demo, ThousandEyes was nice enough to take some questions on network analytics from the attendees. Read the whole Q&A below!
ThousandEyes uses network analytics in order to detect faulty links, ISP troubles, and more. How do you get the performance information on the path tracing view?
ThousandEyes: Visual path tracing in the Path Visualization view is done through a TCP style of traceroute, rather than ICMP, which provides a number of advantages. First off, TCP tends to follow the paths that real network traffic follows. Second, TCP gets a lot more information back from external networks than ICMP would, and a typical traceroute would. Third, TCP-based path tracing can see Equal Cost Multi-Path (ECMP) links which fan out of multiple switches or aggregation devices and you’ll see multiple paths rather than a single path from a single traceroute. We do that by sending a series of specifically timed packets to understand loss and latency on each link and interface.
What’s the frequency of the data collection, and what’s the overhead that’s created by that?
ThousandEyes: Data collection frequency depends on the type of test you’re running. Let’s take as an example the Web and network tests that we looked at in the demo. In terms of data collection frequency, you can schedule it to what you want it to be, up to two minutes or as long as hours in between. Collecting that detailed level of data takes time, a number of seconds, to send out trains of packets to understand what’s happening from a network topology perspective and to measure the performance. We also have a number of tests that run differently, DNS and routing have slightly different frequencies. Generally most of our tests can run at a two minute frequency. So no, you can’t DDoS yourself.
There isn’t a lot of overhead on this. It’s dozens of packets to generate the information. The only tests that use significant bandwidth are full page load and transaction tests which use a browser on our agent to load a page. In those cases it’s whatever the bandwidth of the asset you’re accessing, like a video or image.
How can I integrate ThousandEyes with other systems, like ticketing?
ThousandEyes: ThousandEyes has a few options in terms of integration. We have some specific out-of-the-box integrations for products like PagerDuty for alerting and on-call systems. We also have a very robust API with excellent documentation that you can access directly from the Dashboard itself. At the top of the application you can save and share data, and get the API key to query the data from that specific view. We have a number of customers that have integrated this with ticketing systems or displays in their NOC. And you can use Webhooks to plug into a ServiceNow or Nagios or something else you already have deployed.
What kind of variables and conditions can I alert on?
ThousandEyes: One of the the most valuable features within ThousandEyes is the alerting functionality. You can take some interesting, custom actions. The biggest problem we hear from network monitoring users in terms of alerting is that there are too many false positives. We’ve built several features to make it easy to fine tune and customize the thresholds that are important for your environment. You can, for instance, only alert when multiple rounds of errors have occurred or when multiple locations detect faults. You can also alert on specific components on a page; for example, you want to be alerted if your Google display ads aren’t loading appropriately. There is a lot of richness of metrics to customize, from DNS and routing information, to network and application and page load information. And the alerts are modular, so that you can set up one that works and apply it to any additional test that inherit the same configuration.
You can share test information. Who has access to that data?
ThousandEyes: ThousandEyes has Interactive Sharing capabilities: you can share a snapshot of a specific time slice of any of these views and you’ll get a fully interactive link that one of your team members could use. Or a service provider could view it, even if they don’t have a ThousandEyes login. Alternatively, you could share a stream of live data with people who do have a ThousandEyes account. We have a number of the largest SaaS providers and hosting providers already using ThousandEyes and familiar with the data. They use ThousandEyes information to help troubleshoot customer environments a lot more easily and to collaborate more in terms of network troubleshooting. For instance, we announced a partnership with Microsoft to do this for their CRM application. So you can share a link with Microsoft or whomever your service provider may be and they can have more actionable data that they can use to work your ticket faster and to tell who’s end the problem is on.
What’s the data security model?
ThousandEyes: ThousandEyes is a software-as-a-service (SaaS) application. That means that monitoring data from the probes is sent back to ThousandEyes collectors in our data center. Within our data center we crunch, analyze, and store the data so our customers can access it via UI and API. There are a number of security protections built in for the collection of the data, the transport of the data and the storage of the information. Data is encrypted between the probes and our collector and then stored within our databases.
We have a robust Information Security function within ThousandEyes that performs regular audits, penetration testing, and vulnerability testing to ensure the confidentiality and integrity of our data. We work with many of the largest financial institutions and technology firms in the world who have performed their own assessments and signed off on the security measures.
A note on the information collected. Our synthetic probes collect information that is generally publicly available, such as reverse DNS hostnames and IP addresses. We do not collect information from packets transiting the wire itself.