AppDynamics Application Intelligence Platform
AppDynamics and your team may use different terminology to describe your application environment. This topic discusses how to map the services in your application environment to the AppDynamics model, which uses the terms "business applications", "tiers", and "nodes". For an overview of these terms see Logical Model.
Your distributed application environment most likely consists of various services, including:
AppDynamics maps your application environment into a hierarchical system of business applications, tiers, nodes and backends.
The node represents the actual application server that is instrumented by an AppDynamics app agent.
Business applications and tiers are logical constructs used to represent your environment in the AppDynamics model.
Business applications contain tiers and tiers contain nodes. A node cannot belong to more than one tier, and a tier cannot belong to more than one business application.
A backend is a component that is not instrumented by an AppDynamics app agent, but the model allows you to monitor the flows from the instrumented nodes to the backends. These flows often reveal the root cause of a problem that is first identified on an instrumented node.
The flowmap below describes a single business application for the Acme Online Book Store.
Because the services provided by the E-Commerce, Inventory, and Order Processing interacting tiers are all modeled as part of the same business application, it is possible, for example, for AppDynamics to trace the root cause of poor performance of a node in the front-end E-Commerce tier to a slow SQL call from the downstream Inventory tier to the INVENTORY-MySQL database. Without this correlation among the services, this information would not be available.
You can use a single AppDynamics business application to model all of the application environment's services that provide a complete set of functionality. Think of the business application as all the services that interact to support the application's mission. When these services (web applications, databases, remote services, etc.) interact, they are modeled as part of the same business application, and AppDynamics can correlate performance metrics among them to provide a complete picture of the application's performance. A complete picture helps you identify the root cause of any problems that are detected. If any of the services upon which the application depends are missing from the model, you may miss information about a component that is causing problems to appear in a different component. AppDynamics cannot provide correlation between separate business applications.
For example, a single shopping business application may be composed of an inventory application, a e-commerce front-end application, and databases. The inventory application and e-commerce front-end application could be modeled as tiers in a single AppDynamics "business application".
On the other hand, if you do not care about correlation among these services and instead want to maintain separate access control to the various components, you could model the services as separate business applications.
It is also appropriate to have multiple business applications for sets of services that do not interact with each other. A typical example of using multiple business applications is when you have separate staging, testing, and production environments for the same website. In this case the three business applications are essentially copies of each other.
An AppDynamics tier represents an instrumented service (such as a web application) or multiple services that perform the exact same functionality and may even run the same code. These services may be thought of as "applications" in your application environment, but if they interact with one another AppDynamics usually models them as tiers in the same "business application".
A tier can be composed of one node or multiple redundant nodes. One example of a multi-node tier is a set of clustered application servers or services.
There is no interaction among nodes within a single tier. Interaction occurs between tiers in a business application, as illustrated in the flowmap.
The mapping of tiers to business applications and of nodes to tiers occurs in the configuration of the app agent, either in the options to the app agent startup script or in the controller-info-xml file.
For example, in an all-Java environment, to map Node_8000 and Node_8003 to the E-Commerce tier in the AcmeOnLine business application, the startup options for Node_8000 would be
and for Node_8003
To map Node_8002 in the Inventory tier in the same business application, the configuration would be
and to map Node_8001 in the Order Processing tier in the same application
Details vary depending on the platform of the agent. See the installation and configuration properties documentation for the particular app agent that you are configuring.