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 organizes and 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.
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.
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 it's 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.
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. A leading consideration for most cases, however, is to organize 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 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 services (such as a web application). You may think of a node as a distinct application in your environment; however, in the AppDynamics model, they 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 (such as 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 machine agent cannot belong to more than one tier. However you can install more than one machine agent on a machine.
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.
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.
You can create health rules with conditions that use baselines, allowing you to trigger alerts or kick off other types of remedial actions when performance problems are occurring or may be about to occur. See Alert and Respond and Health Rules and 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 Transaction Thresholds.
Health Rules, Policies, and Actions
AppDynamics uses dynamic baselines to automatically establish what is considered normal behavior for your application. You can use policies and health rules against baselines or other health indicators for your application to detect and troubleshoot problems before users are affected. Health rules define metric conditions to monitor, such as when the "average response time is four times slower than the baseline".
AppDynamics supplies default health rules. You can customize the default health rules and create new rules specific to your environment.
The out-of-the-box health rules test business transaction performance as follows:
- Business Transaction response time is much higher than normal: Defines a critical condition as the combination of an average response time greater than the default baseline by 3 standard deviations and a load greater than 50 calls per minute. This rule defines a warning condition as the combination of an average response time greater than the default baseline by 2 standard deviations and a load greater than 100 calls per minute.
- Business Transaction error rate is much higher than normal: Defines a critical condition as the combination of an error rate greater than the default baseline by 3 standard deviations and an error rate greater than 10 errors per minute and a load greater than 50 calls per minute. This rule defines a warning condition as the combination of an error rate greater than the default baseline by 2 standard deviations and an error rate greater than 5 errors per minute and a load greater than 50 calls per minute.
You can configure policies to trigger actions when a health rule is violated or when any event occurs. Actions include notifications, diagnostic actions, auto-scaling capacity, running remediation scripts. See Alert and Respond.
Use the Metric Browser in the controller UI to view all of the metrics that the agents report.
Most of the metrics relate to the overall performance of the application or business transaction (load, average response time, error rate, etc.) or of the application server infrastructure (percentage CPU busy, percentage of memory used, etc).
- You can create special metrics called information points to report on how your business (as opposed to your application) is performing, for example your total revenue for a certain product or set of products. You can also use information points to report on how your code is performing, for example how many times a specific method is called and how long it is taking to execute.
- You can also create extensions that use the machine agent to report custom metrics that you define. These metrics are base-lined and reported in the controller, just like the built-in AppDynamics metrics.
You can access all the metrics programmatically, as well query and manipulate the application environment, using the AppDynamics REST API.
Snapshots give you a detailed picture of your application at a certain point in time. They usually include call graphs that allow you to drill down to the line of code that may be causing performance problems. The most common snapshots are transaction snapshots.