Tests
Last updated
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.
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.
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.
As a quick start, the short video tutorial Configuring BGP Tests should get you up to speed in no time.
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.
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/.
This category of tests measures network performance and path between an agent and a target device. Video tutorial: Configuring Network Tests.
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.
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.
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.
BGP 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.
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.
The agent-to-agent test below depicts a connection error between Cloud Agent Wellington, New Zealand and Cloud Agent Johannesburg, South Africa.
BGP test
This suite of tests is dedicated to Domain Name System performance measurements. Two video tutorials are available: Configuring 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 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.
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.
The below example depicts an iterative query made to authoritative servers for google.com:
Other included tests:
BGP test
Agent-to-server 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.
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.
Below is the test validating a record for thousandeyes.com.
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:
For example:
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:
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.
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.
Below is a sample DNSSEC test to A record for dnssec-tools.org.
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.
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.
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
Here is an HTTP Server view for a test measuring the availability of the https://thousandeyes.okta.com/ service:
Agent-to-server test
BGP routing 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.
Provide metrics regarding the in-browser use experience.
Identify objects preventing or prolonging page load completion.
Monitor performance across content providers.
Below is a page load test targeting Google:
HTTP server test
Agent-to-server test
BGP 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.
Emulate common user interactions, such as completing a purchase.
Alert on degradation of site performance.
Below is a test that performs a login and a search:
HTTP server test
Agent-to-server test
BGP test
For additional guidance on creating a Transaction test, see
A File Transfer Protocol server is an essential storage component of modern enterprises. This test supports FTP, FTPS, and SFTP protocols.
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.
Here is an FTP test to speedtest.tele2.net:21.
Agent-to-server test
BGP test
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: Configuring Voice Tests and Using Voice Test Views.
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.
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.
Here is a SIP Server test targeting an internal VoIP server.
Agent-to-server 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.
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
Here is an RTP Stream test between two Cloud Agents displaying Packet Delay Variation
Agent-to-server test
BGP test
Endpoint Agent tests are classified in below manner:
Video Tutorial: Getting Started: Endpoint Agent Test Types
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:
Compare user experience across your organization.
Identifying networks experiencing performance degradation.
Identify DOM components affecting application performance.
Identify network and wireless connectivity issues.
Below is a Browser Sessions view showing latency from an Endpoint Agent and visited domain details.
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.
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.
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.
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.
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.
Alert on HTTP availability and performance metrics by office or group of agents.
Monitor web application performance from company workstations.
Here is an Endpoint HTTP Server test on google.com.
Here is a sample Endpoint HTTP Server test.
For more information on playing with test settings, see Working With Test Settings.
Transferring tests between Account Groups or Organizations: Changing Ownership of Test.
The test data can also be shared by a public link as described in Sharing Test Data.
ThousandEyes also offers alert notification when a configured event occurs. See Alerts.
Retaining Data Beyond the 90-Day Limit explains how to permanently save events of interest.
