Please do not share: Internal use only
What should I consider about Controller and application hierarchy when planning their configuration?
Table of Contents
Why Proper Configuration Matters
Configuration Use Cases and Trade-Offs
Overview
This article breaks down the AppDynamics Controller → Application → Tier → Node hierarchy to help you make more informed decisions when setting up your environment. Configuring your environment correctly from the start is crucial to getting the most value out of AppDynamics. Making changes later can be expensive and time-consuming, so it’s best to avoid it.
AppDynamics Hierarchy
To organize and present data in AppDynamics, your environment will be configured within our hierarchy: Controller → Application → Tier → Node. The Controller is the highest level of organization, while the Node is the smallest.
Controllers
Think of your Controller as a management tool for seeing your end-to-end application stack. It collects and presents performance data from your application, backend services, infrastructure, and end users.
Many customers use one Controller, but some organizations need several to:
- Distribute services to limit overhead.
- Evaluate features in different environments.
Applications
Controllers contain one or more Applications, depending on the deployment size and how you want to organize your environment. The concept of an Application differs based on your organization’s needs. An Application can represent your whole environment, a subset of your environment (e.g., a Data Center or Service) or a specific business unit (e.g., an entity that a Development Team is responsible for). For insight into how different companies organize Applications, click here.
Applications in the context of the AppDynamics hierarchy don’t always correlate to a software application in a 1:1 ratio. For some customers, it makes sense to have multiple Applications in order to:
- Monitor a large environment consisting of many microservices.
- Restrict access to certain data.
- Monitor a large number of Business Transactions.
- Monitor different development environments or geographical regions.
Tiers
An Application is composed of Tiers. A Tier is a logical cluster of language runtimes that offer the same service (i.e., Nodes). It represents what you want to deploy, such as a collection of containers orchestrated with Kubernetes.
When looking at a Flowmap in your Controller, you’ll notice that Tiers are connected by blue lines that indicate 1:1 mappings or blue icons that represent 1:many mappings. These lines may be associated with infrastructure elements that generate monitoring data like Apache Web Servers, queue managers, and load balancers.
Nodes
Tiers are made up of a cluster of Nodes. Each Node represents an instance of the service you designed, such as single container. A Node, with very few exceptions, is a single instance of a language runtime.
Why Proper Configuration Matters
It’s critical that you configure your environment properly before getting started with AppDynamics. It can be timely or expensive to fix later for several reasons:
- Changes to Application, Tier, or Node configurations are done agent-side and require a restart. This often requires a chain of approval and IT departments offer limited windows for performing them.
- These changes often need to go through a tight change control and development process.
- Changing containerized environments after deployment requires manual work, which can be prone to errors.
- Changing Tier and Node names might require alignment among many stakeholders.
Configuration Use Cases and Trade-Offs
Multiple teams are involved in configuring environments in AppDynamics. Depending on how you set yours up, you will need to make trade-offs around visibility. It is important to understand these trade-offs before implementing AppDynamics. Please see: What tradeoffs do I need to consider when configuring my Controller? and What tradeoffs do I need to consider when configuring my Applications?
