Getting Started with Cloud and Enterprise Agent Tests

This article focuses on introducing you to ThousandEyes Cloud and Enterprise Agent tests. You will learn how to determine which type of test provides the best visibility, how to create a basic test, and how to interpret data, so that you can quickly resolve service disruptions.

Prerequisites

This article assumes that you have previously read the following getting started documentation:

What is a Cloud and Enterprise Agent Test?

ThousandEyes helps organizations monitor their network and application performance using synthetic tests. These tests can be run on vantage points hosted all over the world (Cloud Agents) or deployed on customer hardware (Enterprise Agents), and allow organizations to make informed decisions about their network infrastructure and improve customer/user digital experience by helping troubleshoot issues with cloud-based or on-premises applications, services, and network connectivity.

ThousandEyes Test Types

ThousandEyes provides a number of synthetic tests that can be categorized by their Open Systems Interconnection (OSI) layer, as shown in the diagram below:

For more information about tests related to each layer, see the links below:

Network layer tests: These tests measure metrics like loss, latency, jitter, MTU, and path trace.
Routing layer tests: These tests measure metrics like routing path changes, reachability, and BGP updates.
DNS layer tests: These tests measure metrics like domain availability, resolution time, domain trace, and DNSSEC.
Web layer tests: These tests measure metrics like server availability, response time, throughput, redirects, response code, and page load performance.
Voice Layer tests: These tests measure SIP registration and RTP stream metrics.

Determining the Targets

ThousandEyes recommends that you start by monitoring your most business-critical targets in the following categories.

SaaS Applications

The most common use case for IT teams is monitoring business-critical cloud-hosted applications, such as Office365, Atlassian, Webex, or Slack.

These applications usually provide a public URL for each customer workspace, such as example.slack.com. While users share a single URL for web access, their requests can be served by different servers depending on the user's geolocation, resulting in different performance experiences based on connected networks and locations.

To emulate employee traffic, you need to configure tests that simulate how users connect to the network. We suggest using inside-out monitoring with Enterprise Agents deployed at each office network or VPN gateway.

ThousandEyes provides a number of agent deployment types, including virtual machines, Docker, NUCs, Raspberry Pis, and Cisco network devices. For more information on deployment types, see Getting Started with Enterprise Agents.

Internal Services

On-premises infrastructure that is hosted in a data center or server room (such as Active Directory, VoIP controllers, databases, or DNS resolvers) needs to be monitored to ensure a healthy network and application experience.

We recommend using HTTP, DNS, network, and VoIP tests that target critical on-premises services and applications from an Enterprise Agent deployed within your local area network (LAN).

If you plan on using Enterprise Agents to monitor internal servers or network equipment that use internal DNS names, make sure to update the DNS configuration to use your internal resolver so that the hostnames can be resolved and reflected in the path view and traceroute output.

WAN Sites

A modern WAN structure spreads user traffic among multiple locations connected by MPLS, EVPN, IPsec VPN, or SD-WAN. For users in an office to access a directory server hosted in a data center (DC), the network team needs to make sure their WAN links are constantly healthy. The application's backend could be hosted in different locations as well.

For example, the SRE team could manage a controller in DC1 and a database in DC2 to serve an application. In this example, any interruption of network services between DC1 and DC2 could cause service degradation for the application, and possibly result in a business-critical incident.

To ensure the highest availability of services, we suggest using agent-to-agent network tests with continuous monitoring between Enterprise Agents hosted in each of the WAN sites. Agent-to-agent tests can be configured to run bi-directional network tests every minute to detect network service disruptions or degradations. Additionally, agent-to-server tests can be configured to run with 1 second granularity for more sensitive services.

For more information about continuous monitoring, see Continuous Monitoring.

Cloud Sites

To address the need of a decoupled architecture, more and more businesses are shifting their services and workloads to cloud-hosting providers such as AWS, Azure, and Google Cloud.

For example, imagine that, rather than being hosted in a second datacenter, the SRE team migrates the database to AWS. In this instance, you can deploy an Enterprise Agent within the same AWS virtual private cloud (VPC) as your test target for an agent-to-agent test (in this case, the database service).

Alternatively, you can leverage the ThousandEyes Cloud Agents deployed in AWS, Azure, Google Cloud, and Alibaba Cloud.

For a full list of available Cloud Agents, see Cloud Agents.

Your Website

Many customers use ThousandEyes to monitor their public website's performance from all over the world. This outside-in visibility is not simple to measure, as it requires vantage points located everywhere.

ThousandEyes currently offers Cloud Agents in more than 240 locations around the world, and is continuously adding more. You can leverage these agents using HTTP, page load, and transaction tests to measure your website's performance. In addition to inside-out monitoring, this can detect outages from the user's perspective quickly, limiting impact.

Deploying Tests

Once you know what you want to monitor, you can decide on the type of test/s that best suit your needs.

Layered Tests

In a similar way to the OSI stack, layered tests build upon lower layer tests to create a more comprehensive view of correlated metrics. For example, an HTTP server test will incorporate an HTTP server connection, network layer agent-to-server test, and a BGP test, all monitoring the same target. In this way, users can measure metrics aligned to layers 3, 4, and 7 within the same round of a single test. The image below shows how tests are layered upon one another:

Other examples of layered tests are shown below, with the additional tests they include:

Transaction and page load tests:
- HTTP server test
- Agent-to-server test
- BGP test
HTTP, FTP, SIP, RTP, and DNS server tests:
- Agent-to-server test
- BGP test

For any test targeting a server, ThousandEyes recommends always keeping the Perform network measurements and Collect BPG data advanced options enabled.

Perform network measurements will configure the agent to collect metrics from each layer of the network stack in the same round, which will be useful when doing root cause analysis for issues.

As ISP routing updates are a common cause of network issues, Collect BGP data will configure the agent to monitor BGP in order to help understand the dynamic nature of the public internet.

The example image below shows the available views for an HTTP server test with both “Perform network measurements” and “Collect BGP data” enabled. These two settings ensure the layered test will provide details on both layer 4 (Overview, Path Visualization) and layer 3 (BGP Route Visualization), in addition to the HTTP server test data.

Bi-Directional Tests

While most layered tests are designed to monitor one-way traffic, from the source agent to the target, some tests, like agent-to-agent tests, are designed to monitor source-to-target and target-to-source measurements during the same round, and then combine the two results together. These bi-directional tests can be especially helpful for isolating asymmetric routing issues. For more information, see Agent-to-Agent Test Overview.

Standalone Tests

All ThousandEyes test types can also be performed as standalone tests, without additional layers. This can be useful alongside layered tests to support broader data collection. For example, DNS tests are not included in layered tests. For this reason, we suggest configuring a standalone DNS test alongside your layered test suite.

Templates and Onboarding Wizard

The default landing page in the ThousandEyes application is the Views page. If you are a new user, the Templates app opens an onboarding wizard to walk you through the first steps. The wizard offers a smooth path to getting started with ThousandEyes. Choose a pre-configured template to start monitoring one of the common SaaS-based applications you use.

When the wizard finishes and you see Setup completed successfully, the UI is now populated with the results of your setup.

Click through the steps of the page tour.
Explore the key elements of the Views screen:
- Test selector
- Timeline
- Path visualization
On the Dashboards screen, click the selector and choose Service Health Dashboard TEMPLATE.
On the Alert Rules screen, check out the default.
On the Test Settings screen, you'll see the results of the tests that the wizard configured for you.

The default page load test includes information from lower-layer tests: HTTP server, agent-to-server, and BGP tests. For more information about these test types, see:

Configuring Test Settings

Each test type has specific settings that need to be configured. You can find the detailed requirements for each test type by following the links in the ThousandEyes Test Types section of this article.

ThousandEyes provides a number of templates for new users to automatically generate tests based on pre-configured settings. For more information about templates, see the Onboarding Wizard documentation.

Creating a new test can be accomplished under the Cloud & Enterprise Agents > Test Settings menu by clicking on the Add New Test button. Most tests will require the basic configuration options to be filled out, while the advanced settings are optional, or pre-filled based on the default configuration.

URL / Target / Domain / Prefix: The target of the test.
Note: For agent-to-agent and RTP tests, the Target Agent is selected from the agent list.
Interval: The time between each test round. You can select from 1, 2, 5, 10, 15, 30 minutes, and 1 hour. BGP tests use 15 min by default.
Agents: Using the agent selector drop-down list, select the agents that will provide you with the best vantage points and visibility for your test. Use the search function and filters to find the agents you need.
Note: For BGP tests, all public monitors will be included by default.
Alerts: Enable or disable alerts, select alert rules, and select suppression windows. For more information, see Alerts.
Protocol / Ports / Probing Mode: Only required for network tests.
- For agent-to-server tests, select from ICMP or TCP.
- For agent-to-agent tests, select from TCP or UDP.
- For probing mode, select from SACK or SYN.
For more information, see Network Tests Explained.

In the metered subscription model, unit consumption is determined by test type, interval, timeout, and agent count. Before saving the test configuration, always check the Projected Usage field on the right panel to ensure your update will not exceed the organization's monthly unit allotment.

For more information, see Calculating Units.

Before creating any new test, ThousandEyes recommends running an instant test by clicking the Run Once button to verify the test is configured and working properly. Instant tests do not require many units, allowing you to understand the baseline functionality of a test, and determine which configuration options work best. This can be very useful when used in conjunction with creating alert rules for your tests.

Instant tests can also be run from the Cloud & Enterprise Agents > Views page. For more information about instant tests, see Working with Instant Tests.

Interpreting Test Results

The Cloud and Enterprise Agents > Views page shows the scheduled test data for the past 30 days. Users can view test data from multiple charts and tables, and drill down into the data to identify issues and determine the root cause.

For a detailed explanation of the components of a view, see Getting Started with Views.

The main components in a test view are:

The top panel contains the Test Selector and Global Filters.
The primary panel contains the Views List, Metric Selector, and Timeline.
The secondary panel contains the detailed metrics tabs, Path Visualization, and BGP Route Visualization.

Users can navigate through the views in a number of different ways. ThousandEyes recommends the following basic workflow:

Select the target test using the test selector.
Review the timeline of each test, and use the metric selector to view each available metric.
Once you find an event that stands out from the baseline, drill down into the detailed metrics tabs.
Try to identify the problematic agent in the table view, and click on it to filter the metrics by that agent.
Use the timeline to determine when the issues started for that agent.
Analyze the path visualization and BGP route visualization views for the specific round.

ThousandEyes agents collect multiple metrics for each test type. For more information on understanding your test results, see What do your results mean?.

To get started with the path visualization, see Getting Started with the Path Visualization.

Troubleshooting Test Data

In the example outage below, we walk through the process of analyzing the issue and identifying the root problem. The example outage can be seen in this saved snapshot: Example Outage.

The incident investigation starts with an alert triggered for the HTTP server’s availability:

Switching to the Table view, you can confirm that the Paris and San Francisco agents were affected:

To review one agent, either use the global filter to select the Paris IPv6 agent, or click on the agent in the table. By navigating to the Network Overview, you can see the agent is showing 100% packet loss:

If you switch to the Path Visualization, you can confirm that packets are being dropped in GTT's network, and there is no route to the IPv6 target in Microsoft's network.

This implies that Microsoft may not be advertising this prefix to their routing peers. This can be easily verified using the BGP route visualization layer.

As expected, you can confirm there was a path change involved with the target prefix, which caused reachability issues depicted by the BGP monitors. By selecting any monitor near Paris, you can see the path change details, which could impact the Paris agent network, and then make the necessary changes to correct the issue.

The ThousandEyes platform test view (navigate to Cloud & Enterprise Agents > Views) provides a Share button for users to share test data with other ThousandEyes users, or external stakeholders that may or may not have access to the platform. You can collaborate with the same graphical view of test results, allowing you to troubleshoot with colleagues, partners, or providers, regardless of whether they subscribe to the ThousandEyes platform.

For sharing test data to anyone that does not have a ThousandEyes account, use the “Snapshots” sharelink feature, which is a unique read-only ThousandEyes test results web page.

For limiting access to test data, and sharing among ThousandEyes users, create a “Saved Event” which is stored under the Sharing > Saved Events menu list.

In order to view or manage saved events, navigate to the Sharing > Saved Events menu. Click on the stacked icon next to the Event Type field to view an event, update the name of the saved event by clicking on the arrow icon, or delete it using the trashcan icon on the far right of the list.

Your user account will require the correct permissions to make these changes. For more information, see Role-Based Access Control.

For more information about sharing test data, see Sharing Test Data.

Shared By ThousandEyes

For some of the common SaaS-based applications, ThousandEyes has tests configured to monitor performance from Cloud Agents around the world. Instead of customers creating individual tests themselves, we share these tests with all customers. You can enable them using the Sharing > Shared by ThousandEyes menu. Find the tests relevant to your organization, and click the Enabled checkbox to subscribe.

Shared tests you subscribe to will appear in your available tests list as read-only.

You can then view the results of the test, or set up alerts for monitoring like any other test. Tests shared by ThousandEyes don't cost units, and are also useful as example configurations for how to monitor applications.