If you organize your web site users' most important activities into business transactions, you will get the maximum benefits and the shortest mean time to resolution (MTTR) from AppDynamics.
Application users don’t complain that the server seems to be experiencing memory leaks or that CPU is maxing out. 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, such as the Login and Checkout processes, to identify and troubleshoot real-world problems in production. AppDynamics automatically detects the business transactions in your application by looking for the business transactions' entry points. You can fine-tune how AppDynamics detects entry points.
To get optimal value from AppDynamics, make sure that your business transactions are set up to describe the traffic that you need to monitor and that they are not set up to monitor extraneous traffic that is not important to your success. Although you will derive some value from AppDynamics auto-discovery, you will significantly increase the utility of the product if your business transactions are tuned to reflect your organization's needs.
Identify Your Business Transactions
You can install AppDynamics and see how it auto-discovers business transactions in your environment, and then configure it to focus on the transactions that get the most traffic. On the other hand, you could do some upfront planning to select and name the operations you want to monitor. For example, you could:
- Interview the teams responsible for each application component or module to identify the key 5-20 operations that they feel are important to monitor. Identify which key operations must work well for the application to be successful. Ask questions about each operation such as:
- What is the business flow it represents?
- What information and metrics are expected?
- Who is interested and why?
- Can the information be obtained in another way, using other features of AppDynamics?
- Name the operations so that they are recognizable to everyone who monitors your application. Use these names for the business transactions. Show these names to business-level stakeholders and make sure the names make sense to everyone.
- Map the operations that you have identified to the appropriate business transaction entry points. The entry point to a business transaction is typically a method that begins every time the user request is invoked. Entry points are described in detail at Configure Business Transaction Detection.
You can keep fine tuning your business transaction configuration, excluding some transactions that you currently detect and adding others that you have not been detecting, as you learn more about which transactions give you the most useful information about your application.
Fine-Tune Your Business Transactions
You can help AppDynamics organize your application traffic in terms of business transactions by configuring how AppDynamics identifies your business transactions. There are many reasons why you might want to do this. The most common are:
- You are getting more monitoring information than you want about requests that are not essential to understanding your business, such as administrative console requests, heartbeat pings, and so on.
- You want to exclude whole classes of transactions: for example, URIs that match or do not match a certain pattern.
- The default automatic detection mechanism is not identifying the appropriate entry points for the business transactions. For example, you may want the agent to discover transactions based on a class/method combination instead of at a higher component level.
- The automatic detection mechanism is not identifying any business transactions in your application. This is typically the case if your application is not built with a framework that AppDynamics can auto-detect. You can configure AppDynamics to discover business transactions by creating custom match rules for determining the correct entry points.
- You want to split a single business transaction into multiple ones. For example, a login request may be detected as a single transaction, but you want to split into two transactions based on whether the request branches to a new-user or existing-user operation.
- If you have large number of transactions, you can analyze the All Other Traffic business transaction to decide how to configure business transactions that reflect your application's actual traffic patterns. For example, if one of the transactions in All Other Traffic is called frequently, you could configure a new business transaction for that traffic.
- Some auto-discovered business transactions may have little or no traffic, so there is no need to monitor them.
- Once you have identified and configured the most important business transactions, you can create a "catch-all" transaction to capture and name all the traffic that is not mapped to other business transactions.
To fine-tune your business transactions see Configure Business Transaction Detection.
The Optimal Set of Business Transactions
Before configuring the business transactions that are most helpful for your team, identify the optimal or right set of business transactions to monitor. The most important factor for identifying business transactions is functionality. When you analyze user requests, you can produce a manageable list of functionality that is related to service levels.
For example, in an e-commerce application the individual requests that "add items to the shopping cart" can be tracked as the "Add To Cart" business transaction. For a web portal or content site, you could define business transactions by the category of the content, such as "Politics", "Sports", etc. You could also create more granular business transactions, such as sub-transactions of "Sports" based on the type of sports.
The easiest way to determine the optimal number of business transactions is to consider the following:
- The number of unique types of requests present in the application
- The number of service levels per business transaction
AppDynamics recommends that you have only as many service levels as are necessary for a particular transaction. For example, a Login transaction represents the performance characteristics of all users who login to a system. The service level for a Login operation for any given time indicates the performance of the transaction. This data translates directly to what end users experience while logging in.
For web traffic, every unique URL is not a business transaction. Multiple URLs will map to the same type of request and therefore map to the same business transaction.
Organize Business Transactions into Groups
When multiple business transactions are similar and you want to roll up their metrics, you can put multiple business transactions into a group.
Usually you group transactions together when they represent a single business service and for reporting purposes you want the metrics combined into a single object - the business transaction group. For example, you have multiple services running on the same application server and they belong to a single AppDynamics business application. You create a single business transaction group for all transactions belonging to one service. In other words, you group the business transactions based on the service to which they belong. Then you have multiple business transaction groups and you can use the group metrics as indicators of the overall health of each business service.
Grouping in the UI can also provide a hierarchy of existing business transactions that need to be individually tracked but are related. For example, all transactions of a specific .war file (if one app server is used to deploy multiple applications as .war files), or all transactions of a specific entity, such as an organization, region, category and so on.
Grouping in the UI makes your lists and flowcharts easier to monitor. See Grouping Business Transactions.
If you have business transactions that you don't need to see at all, consider using exclude rules and/or modifying entry point detection. See Configure Business Transaction Detection.
- Configure Business Transaction Detection
- Hierarchical Configuration Model
- Match Rule Conditions
- All Other Traffic Business Transaction
- Business Transaction Configuration Methodology for Java
- Configure Transaction Detection for PHP
- Getter Chains in .NET Configurations
- POJOs and POCOs
- Business Transaction Dashboard
- Business Transactions List