AppDynamics Application Intelligence Platform
Sometimes you need to fine-tune your business transaction configuration, such as when:
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.
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.
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.
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:
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:
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.
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.
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.
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:
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:
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.
There are two ways to exclude auto-discovered business transactions that you do not need to monitor.
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.
Exclude rules prevent detection of business transactions that match certain criteria. You might want to use exclude rules in the following situations:
To customize exclude rules you can:
Several entry points are excluded by default and you can edit them in the Transaction Detection panel.
You can create new exclude rules using custom match conditions that provides fine granularity over business transaction detection.
For example an exclude rule can:
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.
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.
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.