This page applies to an earlier version of the AppDynamics App IQ Platform.
See the latest version of the documentation.

Skip to end of metadata
Go to start of metadata

On this page:

Related pages:

The first step in implementing AppDynamics in your environment is to get acquainted with how AppDynamics models an application environment. The model of your application environment will serve as the framework around which AppDynamics organizes and presents performance information. Determining how to model your application servers to servers, tiers, and business applications in the AppDynamics model is one of the first steps in implementing AppDynamics. 

Modeling Your Application Environment in AppDynamics

Your application environment most likely consists of various services, including:

  • Web applications served from an application server (JVM, IIS, PHP Web server, and more)
  • Databases or other data stores
  • Remote services such as message queues and caches

The services likely interact in a variety of ways to provide a set of cohesive user interactions with the application, such as a set of user services applicable to airline customers.

Deploying AppDynamics involves mapping the entities in your application environment (such as the JBoss service, MQSeries modules, and databases) and the services they provide (such as a login transaction, flight search, or purchase transaction) to the AppDynamics model.

However, AppDynamics can build the model for you with built-in configuration settings. If you're just starting to explore what AppDynamics can do, you can start by letting AppDynamics build the model for you and refine it later as your understanding of how best to map your environment to the AppDynamics model increases. 

Business Transactions

In the AppDynamics model, a business transaction represents a particular service provided by the monitored environment. In real-world terms, these could be services such as: 

  • In an e-commerce application, user logging in, searching for items, or adding items to the cart.
  • In a content portal, user requests for content such as sports, business, or entertainment news.
  • In a stock trading application, operations such as receiving a stock quote, buying, or selling stocks.

A business transaction gives you a view on performance data in the context of the various tiers that participate in processing a particular request. It is a type of user-initiated action in your environment defined by an entry point and a processing path across application servers, databases, and potentially many other infrastructure components. Each instance of a business transaction is an execution of that transaction in response to a particular user request. 

The flow map for a business transaction shows the touch points for the transaction. The following example shows the business transaction for processing an ecommerce transaction from its entry point tier (ECommerce-Services through to its exit point call to the ECommerce-Fulfillment business application: 

By orienting performance monitoring by business transaction, AppDynamics enables you to focus on the performance of your services from the perspective of users. It tells you if a service is available (users can log in, check out, or view their data), response times for users, and the cause of problems when they occur. 

AppDynamics builds business transactions by detecting the service requests at their entry point and following the request through the environment. If the path followed by the request processing flow represents an existing business transaction, the transaction counts as an instance of the existing business transaction. If it is new, AppDynamics registers the new business transaction.

Business Applications

A business application is the top-level container in the AppDynamics model. A business application contains a set of related services and business transactions.

In a small AppDynamics deployment, only a single business application may be needed to model the environment. In larger deployments, you may choose to divide the model of environment into several business applications.

The best way to organize business applications for you depends on your environment. You should consider organizing business applications in a way that reflects work teams in your organization, since role-based access controls in the Controller UI are oriented by business application.


A node in the AppDynamics model corresponds to a monitored server or JVM in the application environment. A node is the smallest unit of the modeled environment. In general, a node corresponds to an individual application server, JVM, or CLR on which you have installed an AppDynamics agent. 

Each node identifies itself in the AppDynamics model. When you configure the agent, you specify the name of the node, tier, and business application under which the agent reports data to the Controller. 


Business applications contain tiers, the unit in the AppDynamics model that collects one or more nodes. Each node represents an instrumented service like a web application. You may think of a node as a distinct application in your environment; however, in the AppDynamics model, the nodes are members of a tier, which, along with possibly many other tiers, compose the overall logical business application.

How you organize tiers depends on your mental model of your environment. You may choose to group identical nodes into a single tier, for example a cluster of redundant servers. But that's not strictly required. You can group any set of nodes, identical or not, for which you want performance metrics to be treated as a unit into a single tier.

The traffic in a business application flows between tiers, as indicated by lines on the flow map, which are annotated with performance metrics.

In the AppDynamics model:

  • There is no interaction among nodes within a single tier.
  • An application agent node cannot belong to more than one tier.


A backend is a component that is not instrumented by an AppDynamics agent but that participates in the processing of a business transaction instance. A backend may be a web server, database, message queue, or other type of service.

The agent recognizes calls to these services from instrumented code (called exit calls). If the the service is not instrumented and cannot continue the transaction context of the call, the agent determines that the service is a backend component. It picks up the transaction context at the response at the backend and continues to follow the context of the transaction from there.

Performance information is available for the backend call. For detailed transaction analysis in for the leg of a transaction processed by the backend, you need to instrument the database, web service, or other application.