The ThousandEyes platform enables you to test networked assets that your organization owns, and test SaaS-based assets to which your organization subscribes.
This article walks you through all available ThousandEyes test types, enabling you to decide what test type best fits your monitoring intentions. A list of typical usage scenarios is provided for each test type.
Classification of Agent Types
ThousandEyes collects data from various vantage points deployed around the internet and inside customer networks. For the most part, these vantage points are called "agents" - with a few exceptions outlined below. There are multiple types of agents available, each having a specific purpose:
Cloud and Enterprise Agents are hosts (or servers, if you will) containing ThousandEyes software capable of running instant or scheduled tests and device discoveries. The main (and almost only) difference between Cloud and Enterprise Agents is who deploys and manages them - Cloud Agents are deployed by ThousandEyes, on many locations across the globe, instantly available for your new tests. Enterprise Agents, on the other hand, are deployed by you, our customer, in locations of your interest - your data centers, your branch offices, and so on.
Endpoint Agents are your Windows or macOS workstations that have ThousandEyes Endpoint Agent software installed. These agents, whenever they are present in one of the defined networks, collect network and application layer performance data as your users are accessing websites or applications on configured domains. In addition to that, Endpoint Agents provide basic support for running scheduled tests. Pulse version of Endpoint Agents are also available dedicated to running scheduled tests, these can be installed on customer hosts.
There are two test types that are using different vantage points, not described above - routing layer test and DNS+ layer tests. Their vantage point specifics are outlined in the corresponding sections below. Regardless of the outlined data collection vantage point differences, tests from these two layers are listed in the Cloud and Enterprise Agent-Based Tests section below. Metrics calculated at various layers along with their significance are documented in ThousandEyes Metrics: What Do Your Results Mean?.
ThousandEyes tests are classified into categories based on layers of operation, as shown in the following diagram:
Routing layer tests provide methods for collecting internet routing-related information.
This test type operates on the lowest fabric of the internet - the BGP routing layer. Relevant BGP routing data is collected from ThousandEyes-provided BGP Monitors (a.k.a. "Public BGP Monitors"), from BGP peers that you connect to our infrastructure - the so-called Private BGP Monitors, or both at the same time. Collected data is presented as BGP Route Visualization, a view that presents information in a cohesive manner, pointing out relevant events on the timeline and in the ASN graph. A BGP test also offers the ability to include prefixes covered by target prefix.
Ensure network prefix reachability from multiple BGP vantage points on the internet.
Detect and alert on BGP route leaks or BGP route hijacking.
Validate and alert on active DDoS mitigation measures.
Monitor presence and activity of multiple upstream network providers.
Alert on unexpected path changes, unexpected upstream ASNs, route flapping, etc.
Example BGP Test Results
The following figure is showing BGP path change detected by the St. Petersburg public BGP Monitor, where the network path through ASN20485 is replaced by a path through ASN9002:
To get a sense of what interacting with collected BGP data feels like, you can review the contents of the test results depicted above interactively. To do so, visit this share-link: https://ascnkau.share.thousandeyes.com/.
An agent-to-server test measures network performance as seen from ThousandEyes agent(s) towards a remote server. The target could either be an IP address or a hostname. Measurements in an agent-to-server test combine parameters of both, forward and reverse paths. To measure direction-specific parameters an agent-to-agent test can be utilized.
Typical Agent-to-Server Test Use Cases
Measuring network performance when accessing the target remote server from agents assigned to test.
Understand network path changes between source to destination.
Verification of target availability.
Identify network degradation along the network path.
Verify network management of DSCP, MTU, and optimization.
Monitor ingress traffic load distribution across ISPs.
Example Agent-to-Server Test Results:
Below is the path visualization for a test targeting google.com. Restricted access to Google results in 100% packet loss from Cloud Agent Beijing, China (China Unicom). The red circles signify nodes with forwarding loss. Hovering over a specific node will provide a modal with detailed information.
An agent-to-agent test evaluates the performance of the underlying network between two physical sites. The source and target for performing measurements here are ThousandEyes agents and can be both a Cloud Agent, an Enterprise Agent or a combination of both. For more information, see the agent-to-agent test overview.
DNS Server tests provide record validation and service performance metrics. Upon selecting a specific domain and the servers to be queried, agents will run DNS and network layer performance metrics for all targeted servers. Complete information is available in Using the DNS Server View.
Typical Use Cases
Alert on incorrect DNS Record Mapping.
Measure DNS nameserver performance and availability.
Monitor network performance between agents and target servers.
Compare DNS results and performance from around the globe.
Verify GSLB and GeoDNS performance.
Example DNS Server Test Results
The below example depicts an iterative query made to authoritative servers for google.com:
To get your hands dirty with a DNS Server test, visit this share-link.
Other included tests:
DNS Trace Test
Large DNS zones are divided into various smaller child zones with each child zone having dedicated authoritative DNS servers. When a DNS request is made the parent zone will refer the request to authoritative DNS server in the child zone. In this scenario ensuring DNS requests are correctly pointed to authoritative servers by a parent server and also the authoritative server being correctly configured to assert authority becomes crucial. The DNS Trace test helps validate this critical delegation. A DNS Trace test will verify delegations from each parent zone to child zone.
Typical Use Cases
Verify the delegation of DNS records are being performed between parent and child zones as expected.
Observe the DNS hierarchy of a target domain from various vantage points.
Here is a sample test to see a DNS Trace test. Complete trace can be obtained by clicking View Trace link in the above screenshot.
Non-Authoritative Nameservers in DNS Trace Tests
During a DNS trace test, it is possible that a non-authoritative answer is received from a server in the path. The explanation below provides further details on what is happening and why.
Normally, a failed DNS Trace test terminates with the following error:
"Dead end for " + dnsName + " " + dnsType
;; ERROR: Dead end for login.microsoftonline.com A
This error is returned when:
an answer has not been received, and
no further referral data exists.
To successfully terminate a trace requires that the Answer section has one or more non-CNAME records, and the Authoritative Answer (AA) flag in the DNS header is set. Normally, when we have an answer, the answer comes from an authoritative nameserver which will set the AA flag. So, what happens when an answer is received, but it’s from an unconfirmed source?
We have observed that the Answer section can be populated by non-authoritative nameservers (spoofed or otherwise) without AA being set. In that situation, a different error message is returned. Whenever there is a non-zero Answer section that does not contain either a CNAME, or a record matching the type of the target record, you’ll see an error message similar to the following example:
;; ERROR: Server c.root-servers.net responded with AA flag unset (non-authoritative answer) for login.microsoftonline.com A
DNSSEC tests verify the digital signature of DNS resource records and hence validate the authenticity of resource records according to Domain Name System Security Extensions. A DNSSEC test adds security validation to a DNS trace test and complements it.
Typical Use Cases
Verify valid DNS signatures are being sent out along with DNS records.
Visit this share-link to get a sense of a DNS Trace test. Click Details to see the Trust Tree showing chain of trust and Data Chain showing actual resource records received during the test.
This set of tests touches on various Web technologies starting from the most basic measurement of availability of web server all the way up to performing precision transactions on a target. ThousandEyes also supports using Custom User-Agent Strings for Web layer based tests. Watch Working with Web Tests to get up-to-speed with Web Layer tests quickly.
HTTP Server Test
As the name suggests, an HTTP Server test measures the availability and performance of an HTTP service. Any HTTP service that is exposed to the internet (or intranet, if Enterprise Agents are deployed in your internal network) can be tested.
The HTTP Server test is performed as a series of steps (or phases):
DNS: The domain part of the test target URL is resolved to an IP address.
Connect: A TCP 3-way handshake is performed.
SSL (optional): Security mechanisms are negotiated.
Send: An HTTP request is sent.
Receive: An HTTP response is waited for and received.
HTTP: The HTTP response code is validated.
Content verification (optional): Verification of the received content is performed by matching it against a regular expression.
Many aspects of HTTP Server testing can be configured to suit your individual or corporate testing requirements - various authentication protocols are supported, custom headers can be added, SSL options tweaked and so on.
When HTTP Server test detects an issue, the results pinpoint the phase of a request in which the issue occurred, helping to decrease your mean time to repair. To assist the analysis, information from lower layers is included in this test type, namely agent-to-server network and a BGP routing layers are readily available when looking for the root cause.
Typical Use Cases
Alert on the HTTP service availability or performance issues
Effectively detect issues with HTTP services served from multiple data-centers concurrently
Measuring CDN delivery speed, comparison to origin-only serving
Example HTTP Server Test Results
Here is an HTTP Server view for a test measuring the availability of the https://thousandeyes.okta.com/ service:
To interactively review the test results depicted above, visit the share link and give it a go.
Other Included Tests
BGP routing test
Page Load Test
Page load tests use te-chromium, a browser based upon the Chromium browser codebase, to obtain in-browser site performance metrics. The metrics include the completed page load time and phase information for each DOM component. A complete explanation of how ThousandEyes presents DOM information is available here: Navigating Waterfall Charts for Page Load and Transaction Tests. Instant page load tests provide a screenshot upon test completion, while scheduled page load tests provide screenshots when errors are recorded. A list of permitted content types is available in Permitted Content Types.
Typical Use Cases
Provide metrics regarding the in-browser use experience.
Identify objects preventing or prolonging page load completion.
Typical Use Cases
Emulate common user interactions, such as completing a purchase.
Alert on degradation of site performance.
Example Transaction Test Results
Below is a sample test that performs login and a search:
Visit this share-link to get a sense of FTP Server tests.
Other Included Tests
Voice Layer tests look at whether a connection can be established (SIP), as well as testing the exchange of packets after the connection is made (RTP). SIP stands for Session Initiation Protocol and RTP is an acronym for Real-time Transport Protocol. These two actions enable Voice over IP connections. VoIP is a method for delivering voice communications and multimedia sessions over Internet Protocol (IP) networks. ThousandEyes provides a way to test the robustness and quality of these types of connections. Video tutorials: Working with Voice Tests and VoIP Monitoring with ThousandEyes.
SIP Server Test
A SIP Server test checks the availability of Session Initiation Protocol VoIP Server. Additionally, this test could be configured to perform SIP register. For more details, see Using the SIP Server View.
Typical Use Cases
Verifying performance of a VoIP SIP server.
Confirming the ability to perform SIP Register with a target server.
Identify the phase at which a SIP Register fails.
Observe the SIP Register and Options request and response.
Example SIP Server Test Results
Here is a SIP Server test targeting an internal VoIP server.
Endpoint Agents record in-browser and network performance metrics whenever users navigate to monitored domains from monitored networks. Instructions on Endpoint Agent installation and configuration can be found in Configuring Endpoint Agent Setup.
An Endpoint Agent offers various views for unscheduled tests as below: