Test Type Layers and Units
Last updated
Last updated
Units for Cloud and Enterprise Agent tests are calculated based on various factors including their test type. Units for Device Agent tests are not calculated based on the same factors. This article explains how the test type variable applies to Cloud and Enterprise Agents unit calculation. For information about Device Agent unit calculation, see Device Agent Consumption Model.
While the overal equation for calculating units is the same across all Cloud and Enterprise Agent tests (see Base Equation), different test types themselves have different unit rates, and their type and configuration is what alters the results of the equation, as described in Milli-Unit Cost by Test and Agent Type. Regardless of who the customer is, the unit rate for the test type itself doesn’t change.
Usage accrues per configured test, and per agent. Rate is based on agent type (either Cloud or Enterprise Agent), test type, test interval, and test timeout setting. For example, running a test on a single Cloud Agent is cheaper than running the same test on 10 Cloud Agents; running a test on an Enterprise Agent costs less than running it on a Cloud Agent; and running a test on a 5-minute interval is cheaper than running the same test every 2 minutes.
For an example calculation, see Example Calculation.
ThousandEyes test types include a “nesting” feature, as shown below. This diagram shows tests that are available from ThousandEyes Cloud and Enterprise Agents.
ThousandEyes test functionality is similar to that of the OSI stack, in that higher layers include lower ones. For example, the Network agent-to-server test also includes the BGP monitoring associated with the test target’s prefix. An HTTP server test includes both the Network agent-to-server test and BGP monitoring.
Due to their nature, the DNSSEC and DNS trace tests do not implicitly contain lower level tests.
Higher layer tests consume the same number of units regardless of how many tests nest beneath them. That is, an HTTP server test, which includes agent-to-server and BGP tests, will only accrue the cost of the HTTP server test to your account (see the Example Calculation for an example of how an HTTP server test is calculated in units). Conversely, disabling nested tests under a higher level test does not save on units. So, for the same HTTP server test, if you turned off the agent-to-server nested test, it would still accrue the same number of units to your account. In essence, nested tests are free, so they neither cost more, nor save more.
Designing an optimal ThousandEyes test suite is a custom process. There is no one-size-fits-all solution – a lot depends on your critical business initiatives, and how your company is organized. As a new customer, your ThousandEyes account team will guide you in defining your use cases and in establishing proof of value (POV).
Here are the rough steps that you can expect during the scoping process:
Outcomes. First, determine your desired business outcome. For example “I want my e-commerce site to be available in all regions, with priority given to Central and South America because that’s where 80% of my customers are today.”
Targets. Identify what assets you rely on for the desired business outcome. Assets are ThousandEyes test targets. For example, your e-commerce site would be one asset, and it might also rely on third-party cloud services, payment portals, or SaaS platforms.
Test types. Determine which ThousandEyes test types are relevant to monitoring each target.
Vantage points. Consider the type of vantage points needed, for example whether you need Cloud Agents, Enterprise Agents, or both. Remember, usage-based consumption is only part of the picture; you might want to also make use of ThousandEyes Endpoint Agent licences and/or Internet Insights packages as well.
Intervals. Identify an appropriate test frequency for each test. The test interval depends partly on your sensitivity to failure, i.e., how quickly you want to be alerted if something happens. For example, a social media streaming platform might want to know within two minutes if there’s a problem (before the news media starts reporting it) whereas for your company email portal, a five-minute interval might be enough. For very high-criticality test targets, you can use a one-minute testing interval with packet spreading as described on Packet Spreading for One-Minute Interval Tests.
Timeouts. For some tests, the timeout setting determines whether the test is deemed “successful” or not. You can also set alerts based on timeouts. Some agent locations or test targets may need a more generous timeout setting than others. When doing transaction scripts a longer timeout may be needed to complete the user journey.
Ideally, test intervals should be one, two, or five minutes except in special cases.
Don’t increase the time between tests just to save money. There are other ways to maximize value that won’t reduce your ability to quickly detect outages that matter to you.
Balancing test coverage against value optimization involves a series of trade-offs. If you reduce the test frequency, you’ll lose visibility and the ability to be proactive. For example, if you get an alert about an outage, but it only triggers an hour after the outage has started, a lot of users might be filing tickets and complaining – so, what have you saved?
ThousandEyes has developed a number of prescriptive recommendations and templates to facilitate common use cases such as Cisco Webex and Microsoft Office 365. Your ThousandEyes account team will guide you through these steps and help you achieve the maximum value from your tests and licensing agreements.
Customers seeking to exercise units from DNA subscription entitlements must request assistance in order to work with an account team.
Quotas are a way to allocate your total units across multiple account groups within your organization. Quotas are set by the customer for each account group. See Setting Quotas for more information.
