On this page:
This topic introduces you to the tasks involved with deploying AppDynamics to its operating environment, including host preparation and Controller installation.
The system resources of the machine that hosts the Controller in a live environment must be able to support the expected workload.
Installing AppDynamics to a test or evaluation setting typically involves verifying system requirements, preparing the host, and then performing the Controller installation. These topics are described in Prepare the Controller Host and Install the Controller Using the Enterprise Console.
Deploying the Controller to its production operating environment normally introduces additional requirements and considerations. Security, availability, scalability, and performance all play an important role in production deployment planning. The following section lists the tasks related to deploying the Controller.
Depending on your specific requirements and environment, deployment tasks may include:
Deploying the Controller often calls for configuration changes to existing network components, such as to firewalls or load balancers in the network. If the Controller will reside behind a load balancer or reverse proxy, you need to set up traffic forwarding for the Controller. You may also need to open ports used by AppDynamics on firewalls or any other device through which traffic must traverse.
The following are general considerations for the environment in which you deploy AppDynamics. See AppDynamics Quick Start for other network configuration requirements.
AppDynamics adds a custom header to traffic in the monitored environment named singularityheader. This header enables AppDynamics to correlate traffic across tiers. It's important to ensure that any load balancer, proxy or firewall in the network between monitored tiers or between the tiers and the Controller preserves the header added by AppDynamics.
To ensure consistent event time reporting across the AppDynamics deployment, App Agents attempt to synchronize their time with the Controller time.
They do so by retrieving the time from the Controller every five minutes. App Agents then compare the Controller's time to its own local machine's clock time. If the times are different, whether ahead or behind, it applies a time skew based on the difference to the timestamps for the metrics it reports to the Controller.
If, despite the agent's attempt to report metrics based on the Controller time, the Controller receives metrics that are time-stamped ahead of its own time, the Controller rejects the metrics. To avoid this possibility, AppDynamics recommends maintaining clock-time consistency throughout your monitored environment.
During the installation process, you need to configure several accounts for the Controller. These include the embedded MySQL database account, a root user account in the Controller, and an administrator in the Controller.
Usernames and passwords should not include the & or ! characters. If a user account needs to access the Controller REST API, additional limitations on the use of special characters in usernames apply. See Manage Users and Groups for more information.
In most installations, the Controller operates in single tenant mode. In multi-tenant mode, the Controller UI context is divided into separate accounts. Each account has its own set of users, agents reporting to it, and application monitoring configuration.
You choose the tenancy mode at installation time. You can switch the tenancy mode from single-tenant to multi-tenant mode later. It is not possible to switch from multi-tenant to single tenant mode.
Having a single tenancy Controller is suitable for most installations. Only very large installations or installations that have very distinct sets of users may require multi-tenancy.
A summary of the differences between the modes follows:
For more information, see Controller Accounts (Multi-Tenancy).