Tests

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 is one test type that uses different vantage points, not described above - routing layer tests. Their vantage point specifics are outlined in the corresponding sections below. Regardless of the outlined data collection vantage point differences, tests from this layer 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?.

To further understand differences between agent types, see Comparison of Agent Types.

Cloud and Enterprise Agent-Based Tests

ThousandEyes tests are classified into categories based on layers of operation, as shown in the following diagram:

Routing Layer

Routing layer tests provide methods for collecting internet routing-related information.

BGP Test

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.

As a quick start, the short video tutorial Working with BGP Tests should get you up to speed in no time.

Typical BGP Test Use Cases

  • 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/.

Network Layer

This category of tests measures network performance and path between an agent and a target device. Video tutorials: Working with Network Tests and Working with Path Visualization.

Agent-to-Server Test

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.

Other Included Tests

  • BGP test

Agent-to-Agent Test

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.

Typical Use Cases

  • Measure bi-directional network throughput.

  • Measuring network connectivity characteristics between:

    • Multiple data centers.

    • Regional branch offices connecting to data centers.

    • Regional branch offices connecting to IAAS cloud environments.

    • Data centers connecting to IAAS environments.

  • Branch office to HQ network quality via VPN and so on.

  • Detect packet dropping network nodes on the path between source to destination.

  • Evaluating the return path by performing bi-directional testing. Measure network performance and throughput between locations.

  • Compare end-to-end network performance and characteristics between the forwarding and return paths.

  • Measuring network characteristics between data centers, offices, and cloud environments.

  • Evaluate network connections for specific applications.

  • Detect latency and loss along the network path.

Example Agent-to-Agent Test Results

The agent-to-agent test below depicts a connection error between Cloud Agent Wellington, New Zealand and Cloud Agent Johannesburg, South Africa.

Other Included Tests

  • BGP test

DNS Layer

This suite of tests is dedicated to Domain Name System performance measurements. Two video tutorials are available: Working with DNS Tests and DNS Monitoring with ThousandEyes. Note that these video tutorials use an older version of the ThousandEyes application navigation and views. The information about DNS, the different DNS tests available, and the screens for configuring DNS tests are still accurate.

DNS Server Test

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:

Other included tests:

  • BGP test

  • Agent-to-server test

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.

Example DNS Trace Test Results

Below is the test validating a record for thousandeyes.com.

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

For example:

;; ERROR: Dead end for login.microsoftonline.com A

This error is returned when:

  1. an answer has not been received, and

  2. 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 Test

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.

  • Validate DNS records based in DNSSEC.

  • Observe the DNSSEC Trust Chain and Data Chain.

Example DNSSEC Test Results

Below is a sample DNSSEC test to A record for dnssec-tools.org.

Web Layer

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):

  1. DNS: The domain part of the test target URL is resolved to an IP address.

  2. Connect: A TCP 3-way handshake is performed.

  3. SSL (optional): Security mechanisms are negotiated.

  4. Send: An HTTP request is sent.

  5. Receive: An HTTP response is waited for and received.

  6. HTTP: The HTTP response code is validated.

  7. 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:

Other Included Tests

  • Agent-to-server test

  • 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.

  • Monitor performance across content providers.

Example of Page Load Test Results

Below is a page load test targeting Google:

Other Included Tests

  • HTTP server test

  • Agent-to-server test

  • BGP test

Transaction Test

Transaction tests emulate user interactions with a website. This test performs a series of scripted steps - such as entering data into a form or clicking a button - and provides completion time and performance metrics obtained while performing scripted actions. Transaction tests use the Selenium WebDriver engine. Tests scripts are created using JavaScript, from the ThousandEyes Recorder IDE or within the test settings. You can set screenshots and markers at different points within the script to identify important points within the transaction workflow.

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 test that performs a login and a search:

Other Included Tests

  • HTTP server test

  • Agent-to-server test

  • BGP test

For additional guidance on creating a Transaction test, see

FTP Server Test

A File Transfer Protocol server is an essential storage component of modern enterprises. This test supports FTP, FTPS, and SFTP protocols.

Typical Use Cases

  • Verify availability and performance of FTP server.

  • Read, write, and list files within a user's directory.

  • Verify SSH operation by selecting SFTP and performing a list test to any SSH enabled server.

Example FTP Test Results

Here is an FTP test to speedtest.tele2.net:21.

Other Included Tests

  • Agent-to-server test

  • BGP test

Voice Layer

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.

Other Included Tests

  • Agent-to-server test

RTP Stream Test

RTP Stream test measures the quality of Real-Time Protocol Voice stream between ThousandEyes agents acting as VoIP User Agents. For guidance on creating RTP Stream test, see RTP Stream Test Settings.

Typical Use Cases

  • Identify the node responsible for degraded RTP Stream.

  • Analyze effects of BGP Route changes on RTP Stream.

  • Measure call audio quality in terms of

    • Mean Opinion Score

    • Loss

    • Discards

    • Latency

    • Packet Delay Variation

Example RTP Stream Test Results

Here is an RTP Stream test between two Cloud Agents displaying Packet Delay Variation

Other Included Tests

  • Agent-to-server test

  • BGP test

Endpoint Agent-Based Tests

Endpoint Agent tests are classified in below manner:

Video Tutorial: Getting Started with Endpoint Agent

Unscheduled Tests

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:

Typical Use Cases

  • Compare user experience across your organization.

  • Identifying networks experiencing performance degradation.

  • Identify DOM components affecting application performance.

  • Identify network and wireless connectivity issues.

Example User Sessions:

Below is a Browser Sessions view showing latency from an Endpoint Agent and visited domain details.

Scheduled Tests

An Endpoint Agent also supports scheduled tests capability limited to Web- HTTP Server and Network:- Agent to Server test. Creating Scheduled Tests on Endpoint Agents guides you through the process of creating a scheduled test on Endpoint Agents. Endpoint Agent Views - Scheduled Tests helps understand data.

Network - Agent to Server

An agent-to-server test measures round-trip network performance between an agent and a remote server. The target may be either be an IP address or hostname.

Typical Use Cases

  • Measuring round-trip network performance from multiple vantage points.

  • Monitor for, and comparing performance as a result of, network path changes.

  • 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

Here is an Endpoint-based agent-to-server test targeting thousandeyes.com with ICMP probing. The link highlighted in red is experiencing higher link delay.

Web - HTTP Server Test

An HTTP Server test measures the availability and performance of an HTTP service, whether public or private. HTTP server tests included network layer agent-to-server tests using either TCP or ICMP.

Typical Use Cases

  • Alert on HTTP availability and performance metrics by office or group of agents.

  • Monitor web application performance from company workstations.

Example HTTP Server Test Results

Here is an Endpoint HTTP Server test on google.com.

Here is a sample Endpoint HTTP Server test.

Related Articles

PreviousObtaining a list of ThousandEyes Agent IP Addresses with te-iplistNextHTTP Server Tests

Last updated