Getting Started with Cloud and Enterprise Agents
ThousandEyes Cloud and Enterprise Agents provide you with an "outside-in", "inside-out" or "inside-in" vantage point for insights into the performance and dependencies of your application, regardless of how the application is delivered (internal to your datacenter, as SAAS, or from a third-party datacenter).
This article helps you get started with using Cloud Agents and deploying Enterprise Agents to your environment.
Prerequisites
For this guide, we assume you have read the previous getting-started guide:
Overview
This getting-started guide introduces the following concepts, procedures, and best practices for deploying Enterprise Agents and leveraging Cloud Agents:
Agents and Vantage Points
ThousandEyes' global vantage points are lightweight Linux-based software agents that allow users to run a variety of layered monitoring tests, in order to gain insight into network and application performance and user experience.
ThousandEyes uses the terms global vantage points, vantage points, and agents throughout our documentation. These terms all refer to the same Linux-based software agents.
ThousandEyes provides three types of vantage points: Cloud Agents, Enterprise Agents, and Endpoint Agents. Although each type of vantage point provides similar capabilities, they each serve different purposes, and exist in different environments.
This section provides a basic introduction into Cloud Agents and Enterprise Agents
Cloud Agents
Cloud Agents are globally distributed vantage points, managed and maintained by the ThousandEyes Operations team, deployed in tier 2 and tier 3 Internet Service Providers, Internet exchange points, and cloud providers such as AWS, Google, Azure, and Alibaba. These vantage points are capable of running all network, DNS, web, transaction, and voice layer tests available within the ThousandEyes platform, and are available for use by all ThousandEyes customers on a unit consumption basis. You can use Cloud Agents to provide an "outside-in" or comparison view in places where campuses are located or where users and customers will be accessing sites. One of the advantages of using Cloud Agents is that you don't have to deploy any servers and can get service and network health visibility right away; then later you can add Enterprise Agents based on your requirements.
For more information about the location of ThousandEyes Cloud Agents, see the Cloud Agent World Map.
Enterprise Agents
Enterprise Agents are vantage points deployed locally (behind the firewalls of an organization) by customers to monitor their data centers, cloud VPCs/VNETs, branch offices, and other internal or Internet-based network assets. These vantage points are installed as either a package for a supported Linux distribution (see Supported Enterprise Agent Operating Systems), or as a pre-packaged virtual appliance that can be deployed into a number of different hypervisor or hardware platforms.
Enterprise Agents should be placed where you want to run your test. For example, if you want to monitor your SaaS applications, Enterprise Agents should be placed at all locations where you have significant concentrations of users. In most cases, this means that each office will have a single Enterprise Agent. For some very large campuses, multiple agents can be deployed to monitor different parts of the campus.
Unless your requirements dictate that you have floor and/or VLAN-based visibility, it is not usually necessary to install an Enterprise Agent on every floor of an office.
If ThousandEyes is used for monitoring application dependencies, such as external APIs, you should deploy an Enterprise Agent in the same datacenter as the application or use Cloud Agents. This will allow you to configure tests to the external API and quickly isolate issues.
The following sections cover installing an agent for monitoring user applications from campus locations.
Placement Inside the Location
The Enterprise Agent should be placed as close to the users as possible. Deploying the agent on an access switch, such as the Cisco Catalyst 9300, is a very efficient way to achieve that goal. If an access switch is not an option for deployment, you can use any deployment method mentioned in the Enterprise Agents documentation, taking into consideration that the agent should be deployed as close to the users as possible.
Choosing the Right Network
For most use cases, the best network to install the agent on is the same network as the user. This ensures that all dependencies that a user has (such as QoS policies, firewall policies, and routing) are also applicable to the ThousandEyes test traffic.
If multiple networks with distinct traffic policies exist (such as "users", "guests", and "voice"), multiple test sources will be needed. This can be achieved by either deploying multiple Enterprise Agents, or by configuring the multi-interface function.
Adding a New Enterprise Agent
To add an Enterprise Agent:
Log into the ThousandEyes web application.
Navigate to Cloud & Enterprise Agents > Agent Settings > Enterprise Agents > Agents:
Click Add New Enterprise Agent. If this button is not visible, you'll need to review your user permissions. For more information, see Role-Based Access Control.
After clicking the button, the installation menu panel will appear. This panel displays the installation options, system requirements, and the account group token, and links to the specific installation guides for each method.
Note: The account group token is the unique key that links an Enterprise Agent to a ThousandEyes account group. Treat this token like a password.
Follow the steps in the installation guide for your deployment method. When your new agent is successfully added, it will appear in the Enterprise Agents > Agents view.
The Status/Last Contact column will show a green circle icon and the Just Now status for your newly created Enterprise Agent.
Your Enterprise Agent is now ready to use. We recommend you take the following steps with all new agents:
Give them a descriptive agent name and hostname, to ensure they are easily identifiable.
Add them to a single account group, then share them with other account groups for use in tests.
ThousandEyes recommends that you assign all Enterprise Agents to a single account group and share them with other account groups for use in specific tests. This is the best practice because it ensures that one team is responsible for managing all agents.
Enterprise Agents do not consume any licenses. It is the tests running on those agents that consume units. For more information, see About Our Consumption Model.
Some Cisco platforms include ThousandEyes units as part of their license, as outlined in the Cisco Device Entitlements section.
Preparing the Network
Enterprise Agents need to connect to the ThousandEyes platform to function, and they need to be able to perform tests that send detailed output to the platform.
All communication with the ThousandEyes platform from the Enterprise Agent is initiated by the agent, and so there is no requirement to configure inbound access from the ThousandEyes platform to the Enterprise Agent.
Network access for testing is dependent on the test type configured. For example, an HTTP test requires different ports and protocols than a DNS or voice test. For more information about test types, see Getting Started with Tests.
In order for the path visualization to properly function, you will need to allow ICMP error messages inbound to the Enterprise Agents. If a well-behaved stateful firewall is used, this should work automatically if outbound traffic is permitted, but in some cases, specific access will need to be configured.
The exact destination and protocols depend on your installation type, the tests performed, and the ThousandEyes region your account is provisioned in. For detailed firewall configuration requirements, see Firewall Configuration for Enterprise Agents.
Adding Agent Labels
When you configure a test, you can use an agent label to assign multiple agents to that test. This makes agent selection easier, and ensures testing is configured consistently. In addition, these labels can be used to make dynamic dashboards that automatically adjust when the testing changes.
The same label can be applied to both Cloud and Enterprise Agents, and multiple labels can be applied to the same agent.
We recommend that you use labels to group similar agents together. For example, you could add labels for network segments (like "LAN", "VOICE", or "GUEST"), locations (countries, cities, regions etc), or internal classifications (like "Large Branch", "Datacenter" etc). You could also create labels specifically for Cloud Agents, such as a label for all agents used to monitor global websites and another for regional locations etc.
For more information on creating labels, see Working with Labels for Agent and Test Groups.
Sharing Enterprise Agents Across Account Groups
As previously mentioned, ThousandEyes recommends that you assign all Enterprise Agents to a single account group, and then share access to the account groups that will be using the agents for testing, as shown in the following example:
By deploying agents this way, you ensure that there is a single place in the platform where all Enterprise Agents are visible, making management of these agents easier and more consistent, while maintaining control over who can initiate tests from individual agents.
Setting Up Agent Notifications
Now that your Enterprise Agents are up and running, you will want to ensure they remain in a healthy state. One way to achieve this is to make sure you receive notifications when an error condition occurs.
Notification rules for Enterprise Agent conditions can be configured from the Cloud & Enterprise Agents > Agent Settings > Enterprise Agents > Notifications page of the ThousandEyes web application.
These notification rules/conditions can be set for:
Agents being offline.
Clock offset for an agent.
Agent software being outdated.
Analyzing Agent Utilization
Each test running on a ThousandEyes Enterprise Agent is assigned dedicated time in the test queues belonging to the agent. An Enterprise Agent can only run one task per queue at a time. This mechanism ensures that each test has dedicated resources, and that multiple tests won't interfere with each other.
Agent utilization is mostly dependent on server response times and queue utilization, so it will not help to add more resources to an overloaded agent. Adding more members to a cluster, or removing unnecessary tests, are the only ways to reduce agent load.
For more information about Enterprise Agent clustering and utilization, see Enterprise Agent Utilization.
Last updated
