AppDynamics Concepts

The first step in implementing AppDynamics in your environment is to get acquainted with how AppDynamics models an application environment. This helps you understand how best to map your specific environment to the model. 

The model of your application environment will serve as the framework around which AppDynamics presents performance information.  

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.

Implementing an AppDynamics deployment 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. Once you have instrumented and mapped your application environment, AppDynamics uses a tag, trace, and learn approach to identify business transactions across the environment. 

In terms of the AppDynamics model, the various services and processes in the monitored environment are called nodes or backends. One or more nodes belong to a tier, which is a group of identical nodes. The entities interact to provide business transactions. The set of nodes and business transactions are all contained in a business application. The following sections takes a closer look at the parts of the model.  

Business Applications

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.

AppDynamics correlates performance metrics among interacting services to provide a complete picture of the application's performance. Modeling the interacting services as part of the same business application enables the agents to do things like trace the root cause of poor performance in a front-end service to a slow SQL call made from another service.

Structurally in the AppDynamics model, business applications contain tiers and tiers contain nodes.

See Cross Application Flow for information about tracing flow across different business applications.

Nodes

A node is the basic unit of the application environment monitored by an AppDynamics application agent or machine agent.

An application monitoring agent, or app agent, monitors the performance of your application. A machine agent monitors the performance of the hardware, operating system and network on which the application agents are installed.

You install application agents on:

• JVMs
• Windows .NET applications (IIS applications, standalone executables, or Windows services)
• PHP Runtime Instances
• Node.js processes

You install machine agents on virtual or physical machine operating systems.

When you instrument an application, you specify the name of the node, tier, and business application under which the agent reports data to the Controller. The method for doing this is different for each platform. See the section for your platform under Instrument Applications for details.

Tiers

Business applications contain tiers, which are logical constructs that represent an instrumented service (such as a web application) or multiple services that perform the exact same functionality and may even run the same code. You may describe these services as "applications" in your organization, but if they interact with one another AppDynamics usually models them as tiers in the same "business application".

A tier is composed of one node or multiple redundant nodes. Nodes grouped into a tier may have redundant functionality or may not. An example of a multi-node tier with redundant nodes is a set of clustered application servers or services. An example of a multi-node tier with different nodes is a set of services that do not interact with each other but for which you want to roll up performance metrics as a unit.

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 machine agent cannot belong to more than one tier. However you can install more than one machine agent on a machine.

Backends

A backend is a component that is not instrumented by an AppDynamics agent, but the model allows you to monitor the flows from the instrumented nodes to backends. These flows often reveal the root cause of a problem that is first identified on an instrumented node. Backends include databases and other remote services.

Business Transactions

The business transaction is the mechanism by which AppDynamics Application Performance Management orders and monitors application traffic.

Business transactions represent either a category or a type of user request. They depict the primary functions of your application. Examples of business transactions include:

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

Application users don’t complain that the server seems to be experiencing memory leaks or that its database connection is slow. Instead, users say they cannot log into the application or notice that it takes too long to complete a checkout. That is why AppDynamics uses business transactions to identify and troubleshoot real-world problems in production. Organizing application traffic into business transactions aligns the traffic with the primary functions of a web business. This approach focuses on how your users are experiencing the site. Monitoring business transactions lets you know if functionality is currently available (users can log in, check out, view their data, and so on), whether user requests are being performed in a timely manner, and where the cause of the problem is if a problem is identified.

By default the application agent automatically detects the business transactions in your application, but you can configure transaction detection to meet your needs.

In a complex environment business transactions are typically distributed over multiple tiers. One tier is the entry point for the business transaction. Transaction correlation maintains the business transaction context across all tiers traversed by a distributed transaction.

For more information about business transactions see Monitor Business Transactions.

Mapping your Environment to the AppDynamics Model

When you instrument an application server or other component you want to monitor, you identify the name of the business application, tier and node in AppDynamics with which to associate the node. When the agent registers with a Controller, it identifies itself using the node, tier, and application name you configure. 

The process of assigning entities to applications and tiers is how you map your application environment to the AppDynamics model. Whether a given application server belongs in one application or another, for example, are the mapping decisions you need to make, informed by the nature of your application and how you want to monitor them.

If you are using a self-service trial, you can accept the default model associations generated by AppDynamics. For example, if not otherwise specified, a new monitored application will be associated with MyApp business application. The node will be identified by the server type. You can refine the AppDynamics model of your environment as you gain an understanding of how best to match the model to your environment.

For a production deployment, you can specify the values in the agent configuration, as described in Instrument Applications.  

For more background information, see Mapping Your Applications in AppDynamics. 

Baselines and Thresholds

The AppDynamics Platform uses both self-learned baselines and configurable thresholds to help identify application issues. A complex distributed application has a large number of performance metrics and each metric is important in one or more contexts. In such environments, it is difficult to:

• Determine the values or ranges that are normal for a particular metric
• Set meaningful thresholds on which to base and receive relevant alerts
• Determine what is a "normal" metric when the application or infrastructure undergoes change

For these reasons, anomaly detection based on dynamic baselines or thresholds is one of the most important features of the AppDynamics platform.

The AppDynamics platform automatically calculates dynamic baselines for your metrics,  defining what is "normal" for each metric based on actual usage. Then the platform uses these baselines to identify subsequent metrics whose values fall out of this normal range. Static thresholds that are tedious to set up and, in rapidly changing application environments, error-prone, are no longer needed.

Once you have set up your baselines, you can create health rules that use those baselines. You can set a default baseline and you can configure and use other baselines as the basis for any health rule. You can then define policies tied to those health rules to trigger alerts or other remedial actions to let you know when performance problems are occurring or may be about to occur.  See Alert and Respond and Health Rules and Detect Anomalies Using Dynamic Baselines for more detail.

AppDynamics thresholds help you to maintain service level agreements (SLAs) and ensure optimum performance levels for your system by detecting slow, very slow, and stalled transactions. Thresholds provide a flexible way to associate the right business context with a slow request to isolate the root cause. See Set Performance Boundaries Using Thresholds.