Business Transaction Detection

AppDynamics automatically discovers business transactions based its default match rules. The default match rules can take you a long way towards having a useful list of business transactions. Nevertheless, you should review and, if necessary, modify the business transaction detection configuration to best suit your requirements and application environment. 

You can refine how AppDynamics generates business transactions based on the existing detection scheme, configure exclude rules for business transactions, or customize the naming scheme for detected transactions. 

After you have finished configuring detection rules, you can migrate the rules between applications and tiers using the REST API. For more information, see Import and Export Transaction Detection Configuration.  

Viewing and Modifying Transaction Detection Settings

You can customize match rules for entry points in the Controller UI from the Transaction Detection tab in the Configuration > Instrumentation configuration page. 

The transaction detection configuration can apply to the entire business application or to a particular tier. See Configuration Inheritance for information on how configuration granularity and inheritance works.

Automatic Transaction Detection Rules

An entry point specifies the method, URIs, or other callable resources that represent the start point of a business transactions. The Controller includes many pre-set entry points configurations. You can view entry points in the Controller UI in the Transaction Detection tab in the instrumentation page. 

You can customize how AppDynamics generates business transactions based on entry point traffic by configuring a custom match rule. When creating a new transaction detection rule for a given application type (such as Java or .NET) you first choose the framework for that type. For example, for a new .NET custom match rule, you have several technology or framework choices, such as ASP.NET, Web Service, or a .NET class or method.

The subsequent configuration options depend on the framework or technology you chose. The PHP web choices, for example, let you specify HTTP-oriented match criteria, such as HTTP method, URI, and query parameters. 

For details on creating custom match rules, see Configure Custom Match Rules.

Disabling Transaction Monitoring

As determined by the Enabled check box in the Transaction Monitoring column of the transaction detection list or in a custom match rule, entry point detection can be enabled or disabled. When it is disabled, it means that the agent stops counting, measuring, and recording all activity on servers of that entry type at the application or tier. 

You may want to disable transaction monitoring 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 where disabling monitoring may be useful 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 so that only the Spring Beans, which are enabled by default, are discovered and monitored.

For each entry point type, you can enable and disable automatic transaction detection. If automatic detection was enabled and then you disable it: 

• The agent stops reporting metrics for the transactions previously detected by the now disabled entry point and detects only transactions based on custom rules. However, the disabled transaction is not deleted or excluded. You can delete the transaction in the Business Transactions list page by selecting the business transaction, and then clicking More Actions > Delete Transactions.
• No new transactions based on auto detection for the disabled type are discovered. 
• Calls to methods and operations of the disabled entry point type are no longer auto-detected.
• Custom rules for the entry point type remain active and the agent reports metrics for transaction detected by them.

Exit point detection remains enabled.

Refining Business Transaction Naming

AppDynamics assigns names to discovered business transactions based on naming rules for that type of entry point. The naming logic varies depending on the application technology. For example:

• For some web-oriented technologies such as Java Servlets, ASP.NET, or PHP Web, detection rules name the transaction using the first two segments of the URI by default. 
• For message-oriented technologies such as an asynchronous message listener or message driven bean (JMS), the transaction is named using the destination name (the queue name) or the listener class name (if the destination name is not available.) 
• For Web services, the name used is the Web service name plus the operation name.

For certain entry point types, you can modify the default configuration for business transaction naming globally by clicking the Configure Naming link in the Transaction Detection tab. (Alternatively, configure custom match rules to apply specific naming rules to a subset of the traffic for that traffic type.)

Additionally, certain PHP entry points allow you to use the Virtual Host in the transaction name:

For more about the detection and naming by application type, see the instrumentation page specific for that application type, such as Configure Transaction Detection for PHP and Configure Business Transaction Detection for .NET.