Modifying the Default Business Transaction Configuration
Sometimes you need to fine-tune your business transaction configuration, such as when:
- You do not see business transactions that you expect to see based on how your application should be represented in AppDynamics. See Organizing Traffic as Business Transactions.
- You see the All Other Traffic business transaction in the Business Transactions List, for example:
AppDynamics creates the All Other Traffic business transaction when a business transaction limit is reached. You can modify the transaction discovery configuration to reduce the number of business transactions.
To modify your business transaction configuration follow this suggested methodology.
1. Confirm Business Relevance
The first step in analyzing the business transaction configuration that is right for your application is to confirm which transactions you want to monitor. Talk with your application developers and architects about which are the most important processes to monitor. The discussion will help you identify the correct entry points, which define the beginnings of your business transactions. Be sure you are measuring the right things. See Organizing Traffic as Business Transactions.
Once you know what you want to monitor, you can examine the business transactions being detected and determine your next steps.
2. Review the Architecture
If you are missing an expected business transaction, review the application architecture and make sure the expected business transaction is not part of another transaction initiated by another tier. Also make sure the application/tier/node configuration is correct. See Mapping Application Services to the AppDynamics Model.
3. Modify Automatic Detection Criteria
While AppDynamics discovers many business transactions automatically, you may need to modify these mechanisms to detect additional ones or to disable ones that are not critical to monitor.
Configuration is hierarchical for a business application and its tiers, and has both a "global" scope and a more granular "custom" scope. See Hierarchical Configuration Model and How AppDynamics Identifies Business Transactions Using Entry Points.
To change discovery mechanisms you can:
- Disable Entry Point Discovery
- Customize Detection Settings
- Combine Business Transactions
- Use Dynamic Values to Split a Business Transaction
Disable Entry Point Discovery
In the Transaction Detection window for the application or tier, you can completely disable transaction monitoring for a type of entry point. You may want to do this when:
- You know that all the business transactions of a specific entry point type don't need to be monitored.
- You want to use custom transaction discovery configurations instead.
Another example is when Servlets implement Spring Beans and you are interested in monitoring the transaction starting at the Spring Bean level. In this case you can disable Servlet discovery and then only the Spring Beans, which are enabled by default, are discovered and monitored. See Exclude Spring Beans Of Specific Packages.
Customize Detection Settings
You can use custom match rules on entry points to establish a set of transactions that give a good and distinct representation of the business activity while not being too granular. See Configure Business Transaction Detection and Java Web Application Entry Points.
For example, by default AppDynamics uses the first two segments of a URI to identify Servlet-based business transactions. Depending on your application code, you may need to use either fewer or more segments of a URI to get the correct granularity to identify the transactions.
For another example, you may have a business transaction initiated by code that does not use a standard framework, and you need to define a custom POJO entry point.
Combine Business Transactions
You can combine multiple business transactions by changing the auto-discovery rules at the global application or tier level and/or by creating custom match rules at more granular levels. Both techniques help you configure what business transactions to monitor.
For example, you may have many Servlet-based business transactions that are auto-discovered using the first two segments of the URI.
If it makes more sense to use only the first segment, you can change the auto-discovery rule to specify only the first segment.
Use Dynamic Values to Split a Business Transaction
The process of using a dynamic value to customize business transaction discovery is called transaction splitting. Transaction spitting allows you to fine-tune transaction detection or exclusion based on a parameter or user data.
For example, you could create a new business transaction configuration that uses the "color" parameter to separate products/outdoor transactions.
See more Servlet examples:
- Automatic Naming Configurations for Servlet-Based Business Transactions
- Custom Naming Configurations for Servlet-Based Business Transactions
- Advanced Servlet Transaction Detection Scenarios
Collect Extra Traffic into a Catch-all Transaction
After configuring the most important entry points, consider creating a new "catch-all" rule to collect and name all other website traffic. This will help manage the number of business transactions you see in lists and flow maps.
Create a custom match "catch-all" rule where:
- Entry point type is "Servlet" (the most commonly encountered entry point type in Java environments)
- Priority is "0"
- Match value is "URI is not empty"
Make sure the Priority is "0" so that it will be discovered last. Any operations that don't match your customized detection rules will be discovered by this "catch-all" rule.
Note: The "catch-all" rule also captures all web service and Struts traffic. This is because custom rules are evaluated before exclude rules, and there are default exclude rules for web service and Struts traffic. The "catch-all" rule will evaluate first and put what would normally be excluded by default into the "catch-all" business transaction.
4. Exclude Business Transactions
There are two ways to exclude auto-discovered business transactions that you do not need to monitor.
- The Exclude Action in the UI: Excluding transactions from the UI is helpful if you think you may want to resume monitoring the transaction in the future, as the underlying configuration is still present. For example, a transaction may not have traffic now but you anticipate that it will in the future.
- Configure Exclude Rules: One reason to use exclude rules over the Exclude action in the UI is mainly for efficiency, as you can exclude whole classes of business transactions using string match rule conditions. See Creating Exclude Rules.
Exclude Action in the UI
When you exclude a business transaction from the UI, AppDynamics retains existing metrics for the business transaction, but no longer monitors it. Excluded transactions do not count against the maximum number of transactions allowed per application or per agent. Excluding transactions using this method is helpful if you think you may want to resume monitoring the transaction in the future.
The exclude action in the UI is most useful for web service, POJO, and EJB business transactions, where a single class or web service detects many methods/operations, and you want to monitor some but not all of them. In this case it's onerous to set up custom exclude rules, and much simpler to select the subset you do not want and exclude them via the UI.
In the Business Transaction List you can select one or more transactions and either right-click Exclude Transactions or select Actions -> Exclude Transactions.
To resume monitoring the business transaction, you can "un-exclude" it from the View Excluded Transactions window.
Configure Exclude Rules
Exclude rules prevent detection of business transactions that match certain criteria. You might want to use exclude rules in the following situations:
- AppDynamics is detecting business transactions that you are not interested in monitoring.
- A detected business transaction has no traffic and probably will not have interesting traffic in the future.
- You need to trim the total number of business transactions in order to stay under the agent and Controller limits.
- You need to substitute a default entry point with a more appropriate entry point using a custom match rule.
To customize exclude rules you can:
Change the Default Exclude Rule Settings
Several entry points are excluded by default and you can edit them in the Transaction Detection panel.
Create New Exclude Rules
You can create new exclude rules using custom match conditions that provides fine granularity over business transaction detection.
For example an exclude rule can:
- Skip an EJB control class and use the business logic classes
- Behave like a filter that allows eligible requests and ignores the rest
- Exclude Spring Beans of specific packages.
5. Rename Business Transactions
By default, all business transactions are identified using default naming schemes for different types of requests. For ease of use you can change the label associated with the name. Use the Action -> Rename menu in the Business Transaction Dashboard or the Business Transaction List to give a user-friendly name to the transaction.
6. Group Business Transactions
When multiple business transactions are similar and you want to roll up their metrics, you can put multiple business transactions into a group. You get metrics for each transaction and for the group as a whole. Grouping in the UI makes your lists and flowcharts easier to read by reducing visual clutter.
7. Delete Old Unwanted Business Transactions
After you have modified the business transaction discovery configurations, you then need to delete the old, unwanted business transactions. If you delete a transaction and you have not changed the configuration, it will be rediscovered. However, when you have revised the transaction discovery rules properly for what you want to see and then delete the unwanted business transaction, it won't be rediscovered.
You can delete transactions from the Business Transaction List using More Actions.