Sometimes you need to fine-tune your entry point detection configuration, for example:
- When you are not seeing expected business transactions
- When you see All Other Traffic business transactions in your business transaction list, as shown here:
To analyze your current configuration try one or more of the following tactics:
- Confirm that you have the right entry point for the start of your business transaction, see Organizing Traffic as Business Transactions.
- Review the application architecture and make sure the expected business transactions are not part of another transaction in an upstream tier.
- Review the existing rules and if necessary, modify them using one or more of the following techniques:
- Combine business transactions using custom match rules.
- Exclude some entry points.
- Create and fine-tune custom match rules to define entry points precisely.
There is a default limit of 50 business transactions per agent and 200 business transactions per business application. If you need to increase the limits, set it in the max-business-transactions property in <php-agent-root>/proxy/conf/app-agent-config.xml. There is a hard limit of 100 business transactions per agent.
The following flow chart suggests a process for analyzing your entry point detection scheme.
1 Confirm Business Relevance
The first step in determining the entry point configuration that is right for your application is to decide which transactions you want to monitor. Because business transactions begin with specific entry points, this may require talking to application developers and architects to confirm the correct set of entry points. Be sure you are measuring the right things.
Once you know what you want to monitor, you can examine the business transactions currently being detected and determine your next steps.
This topic describes several techniques for modifying your entry point configuration.
2 Exclude Business Transactions
Use exclude rules to prevent the agent from detecting entry points for business transactions that you do not need to monitor.
Here are some scenarios where exclude rules might be useful.
Business Transaction Discovery at the Next Layer of Application Component Logic
By default, the agent detects PHP MVC requests based on the module*:controller:*action. When an incoming PHP MVC request starts at some control logic in your code that triggers different business logic based on the action, you may prefer to use just the action as the business transaction name. You can create an PHP MVC exclude rule using the match criteria on the action name to prevent certain business transactions from being discovered.
The following rule excludes entry points in which the action starts with indexAction.
Use an Exclude Rule as a Filter
You can use an exclude rule as a filter to allow the eligible requests and ignore everything else.
For example, you want to use default discovery rules to identify the correct entry poiunts. Your application receives URI ranges that start with : /a, /b ... /z, but you want to monitor only URIs only that start with /a and /b. Create an exclude rule that matches on Doesn't Start With /a or /b as shown here:
3 Combine Business Transactions
When you need to reduce the number of entry points that are automatically discovered, you can use a custom match rule to combine multiple potential entry points into a single entry point.
For example, if you have PHP MVC entry points that are automatically detected as
and you want just a single transaction for catalog, create a custom match rule matching only on "catalog".
Or if you have PHP Web entry points that are detected as
and you want just a single transaction for all clothing, create a custom match rule matching only on "clothing".
Or you want the agent to ignore case in the URI, so that /appdynamics.com and /APPDYNAMICS.com are detected as a single transaction, not two transactions.
After you have created a custom match rule, delete the old business transactions that were originally discovered. Deleting a business transaction deletes all historical data regarding that transaction. When the agent detects the transaction again, it uses the new custom match rule rather than the default discovery rule. See 5 Delete Unnecessary Business Transactions.
4 Split PHP Web Business Transactions
Using a dynamic value to customize business transaction discovery is called transaction splitting. Transaction spitting allows you to fine-tune detection or exclusion based on a parameter or user data. For the PHP agent, this feature is available for PHP Web type entry points only.
For example, the agent detects the URI /company/careers but you want to track separate business transactions for /careers/engineering, /careers/marketing, /careers/sales, and so on. Create a custom match rule with transaction splitting.
Or you want to split a URI that contains a parameter as in /myonline/store/shop?productid=dvd, /myonline/store/shop?productid=cd, /myonline/store./shop?productid=book.
5 Delete Unnecessary Business Transactions
After you have modified the business transaction discovery configuration, you should delete the old transactions that were discovered using the old discovey rules.
If you delete a business transaction and you have not changed the entry point configuration, the agent will rediscover it. However, if you have modified the transaction detection rules then delete the old business transaction, it will not be rediscovered.
You delete business transactions from the business transaction list in the AppDynamics console. See the information about the Delete operation at Business Transactions List Operations.