Best Practices for Implementing Account Groups
Last updated
Last updated
When starting out with ThousandEyes, you may wonder if creating quotas and account groups is needed. While larger organizations are more likely to reap the full benefits of these structures, we always recommend planning for expansion. If you don’t, chances are high that you’ll reach a moment in time when you wish you had done this sooner, and time-consuming rework might be needed.
The highest level of separation in ThousandEyes is an organization. Each customer has their own organization, linked to a contract with ThousandEyes. An account group is a feature to divide an organization into logical entities, separating operations while enabling the shared usage of licenses, enterprise agents, tests, and dashboards. If you are not already familiar with account groups, review .
It's important to remember that there is no right or wrong way to build account groups and quotas. What’s most important is that it should work for your organization. In this best-practice guide, we will describe common patterns for designing and implementing account groups, as well as describe how some successful customers have configured account groups for their organizations.
Before you start your journey, consider who will perform the following functions in the platform:
Test Creation and Maintenance
Will you have a central team responsible for creating all ThousandEyes tests? Or is this something that will be spread over multiple teams? Or will this be part of an automated CI/CD (Continuous Integration and Delivery) pipeline?
Outage Response and Test Data Analysis
A large part of work in ThousandEyes is analyzing the root cause of outages. Who will do this in your organization? Is there a central operations team? SRE team? Or will each application group do their own support?
Dashboard Creation and Visualizing Test Data
Dashboards provide a quick overview of the data ThousandEyes collects. Some organizations prefer detailed dashboards, diving into every metric of a single application used by a single team. Other organizations build dashboards with a landscape-wide overview of all data, but with less detail.
Alert Routing and Response
Another important consideration is where alerts will be sent, and how you will set the severity of alerts. Are all alerts going to a central location, for example a central AIOps platform, or ITSM service; or will different teams have different alert systems?
Asking yourself these questions before setting up the account group will help you determine the best solution to fit your organization and its teams. You can use these prompts to make an access-and-support plan for your ThousandEyes environment before you even begin. There is no absolute right or wrong, but there is right or wrong for your organization.
Now that you have asked yourself some questions about how your organization will use ThousandEyes, it's time to look at common methods of separating an organization into account groups.
The most common way of separating account groups is by function. In this model, each logical set of test targets is grouped under a single account group. You can navigate to Manage > Account Settings > User and Roles > Account Groups to view and manage account groups. The following example shows how that could look:
This is usually how organizations start their account group journey. Each application owner gets its own account group and users; and all tests, dashboards, alert rules, etc. are configured in this section. This model works analogously to having a separate account for each application, but with shared resources.
The clear advantage here is that each application owner has their own environment, and users are not distracted by tests and settings they don’t need in their jobs. Each application group can decide on their own how their tests should be configured, which dashboards make sense, and where to send alerts.
This also means that every group must make their own decisions on how their tests should be configured, which dashboards make sense, and where to send alerts. This might result in duplication of work and will make it challenging to keep settings consistent between groups. Another downside is that it's not trivial to build dashboards and alert rules that span multiple applications.
Another common way of separating account groups is by maturity of the tests. When we set up a test, we want to make sure that we are testing the right target, and that all infrastructure is in place (firewall rules, service accounts, etc.) so that transactions behave as expected and that alert rules are tuned to the proper metrics to prevent false positives and alert fatigue.
To make sure that every test is a “clean” test, we recommend building new tests in a separate “development” or “staging” account group managed by the test developer.
In many cases this is not the monitoring team, but an application owner or developer. In the “development” or “staging” account group, you can experiment with test settings and alert rules, and determine the best test approaches for each target. During test development, alerts are not sent to the resolution teams, but only to the developers of the test.
Note that alert rules and integrations can’t be moved or copied between account groups. So if you use this test-maturity method, these elements must be re-created. This can be accomplished using the ThousandEyes API or in the ThousandEyes platform UI.
One big advantage to configuring ThousandEyes resources in one account group versus isolating resources in separate account groups is how easy it is to share and maintain resources.
The account group token used to connect an Enterprise Agent to the ThousandEyes platform is unique per account group. This makes it possible to deploy an Enterprise Agent inside an account group, and it will only be visible to this account group.
There are situations where this makes sense, but in general it is not considered best practice.
The best practice is to assign all Enterprise Agents to a single account group, and share access from there, as shown in the following example. Navigate to Network & App Synthetics > Agent Settings; then click on the associated agent to access the pop out window and update the account groups.
By deploying agents this way, you ensure that there is a single place in the platform where all Enterprise Agents are visible. This makes management of these agents easier and more consistent, while maintaining control over who can initiate tests from different agents. There are legitimate reasons to choose otherwise; make sure the reasons to do so outweigh the added management complexity.
The next resource that can be shared is tests. The account group where the test is created remains the “owner” of the test, and it will be reflected in the unit consumption under Manage > Account Settings > Usage and Billing.
To share a test with other account groups:
Navigate to Network & App Synthetics > Test Settings and click the test to see its configuration.
On the Basic Configuration tab, find the General Information section.
In the Sharing field, use the dropdown arrow to select the account groups that should have visibility to this test.
In the receiving account group, shared tests display with a link icon:
To share a dashboard:
Go to Dashboards and select the dashboard you want to share.
In the upper right, click the ... control and select Edit Dashboard.
In the Account Group Visibility field, select All account groups, Only current account group, or Specific account groups.
So far we have discussed what account groups are, how to share resources among them, and some common ways of separating account groups. In the following sections we will explore advanced scenarios based on successful ThousandEyes customers: what works, what doesn’t, and the pitfalls.
The first manageable pattern is a strict separation of account groups. In this pattern, the groups share the same pool of licenses and Enterprise Agents, but not tests or dashboards. This works great if there is little to no overlap in monitoring needs. Each group monitors their own applications and is responsible for their own alerts and response to alerts.
The following example describes the ThousandEyes implementation for a global enterprise, with over 500 applications monitored in ThousandEyes. The ThousandEyes platform is managed by a central monitoring team responsible for all monitoring tooling.
This team provides “monitoring as a service” to application owners. They use ThousandEyes to provide global application availability monitoring and synthetic performance monitoring.
Each test in ThousandEyes starts in a development account group. The application owner is responsible for setting up the right test targets and creating correct synthetic test scripts where applicable; the monitoring team will provide support when needed. Once the test is deemed production-ready, the ownership of that test is transferred to the central monitoring account group. This is a single account group where all production tests reside.
All alerting and alert integration is done via this central group. All alerts are sent to downstream AIOps tooling for further alert processing, integration and correlation.
Application owners get their tests and dashboards shared back to them in a separate account group for detailed analysis. If needed, application owners can make their own dashboads and dashboard snapshots, without cluttering the central monitoring group.
Using this model, you must take care with the maintainability of the central test account group. Many tests will reside there, so you'll need a strict naming and labeling convention. Otherwise, you can easily lose oversight. This structure works best if you use automation to maintain the central monitoring account group.
Another common and maintainable pattern is distributed testing and alerting, but with centralized dashboards.
Each test where a central dashboard needs to be created is shared into this account group. Use this account group to create the “overview” dashboards. People who are primarily interested in dashboards can have this group as their only or default login account group.
One thing to consider is that labels are account group-specific. Any labeling made in the test's original account group will not transfer to the “dashboard” account group.
A pattern to avoid is the so-called “mix-and-match sharing”. Imagine an organization that started with a strict separation of tests based on functionality. While working with the different tests and account groups, the organization sees a need to share data. The organization didn’t follow the “Centralized Reporting” pattern, but decided to share specific tests and dashboards on an ad-hoc basis.
Doing this will make it harder for users to keep track of what is tested where and who is responsible for each test. In practice, we see users not maintaining structure in their account groups. The result is that the organization tests the same targets from multiple account groups, and users have a hard time finding a test when they need to troubleshoot.
All patterns discussed in the previous sections apply to Cloud and Enterprise Agents, with their associated testing and dashboarding. Currently, it is not possible to share Endpoint Agents or Endpoint Agent tests with different account groups. Because of this restriction, most customers keep all Endpoint Agents in a single account group, with one exception:
For high-profile or "sensitive" users, it can make sense to have an exception to the rule of all Endpoint Agents in a single account group. Many large organizations have a separate IT process for sensitive users such as executives, HR, critical employees, or employees with access to medical data. If your organization has procedures for these categories of users, we recommend that you follow the same pattern in ThousandEyes: create an account group for the sensitive users' Endpoint Agents, and limit access to that account group to only those personnel who support the sensitive users. Endpoint Agent licenses are assigned to your organization and can be transferred between your account groups.
Account groups give ThousandEyes users a powerful instrument in building a scalable and easy-to-manage monitoring platform. As with many design choices, there is no clear good or bad. The most important thing to do is to make choices based on how your organization works, and to implement your choices consistently.
Once the test and all settings are ready for production, the test can be moved to the “production” account group, and alerts can be forwarded to the corresponding operations team responsible for monitoring production targets. To transfer test ownership, navigate to Network & App Synthetics > Test Settings, click the ... control next to the test, and select Transfer Ownership. This brings up a window similar to the one below. For more information, see .
Both the and the show a very strict separation of account groups. While easy and clean, in real life most separations are not this clean, and most customers want to share resources between account groups. The following sections explain what can be shared, and maintainable patterns for this sharing.
What goes for Enterprise Agents and tests also goes for : They can be shared among different account groups. Sharing can be configured in the Dashboard Details pane on a per-dashboard basis, to either allow all, none, or specific account groups access to the dashboard.
By default, units and other licenses are shared across multiple account groups, and each account group can use the complete license allocation. This is not always the desired situation. By setting up you can control the allocation of units between account groups. A full description of quotas is outside the scope of this document.
This pattern usually starts off as complete separation of account groups. Each application team has their own tests, and after a while a need for data sharing arrives, usually in the form of an “overview” or “management” dashboard with multiple applications. The most common pitfall is moving into the anti-pattern: , so caution is required.
To keep the ThousandEyes instance organized, the best practice is to create a dedicated account group for all dashboards. The below example shows a test that is in the Microsoft 365 account group and is being shared to the centralized account group called Dashboards. See the section for details on sharing tests.
Both the pattern and the pattern can be combined with the of having separate, or shared, development account groups for each “production” account group.
