Pro 3.8 Documentation

AppDynamics Application Intelligence Platform

3.8.x Documentation

PDFs

Videos

Release Notes

Skip to end of metadata
Go to start of metadata
Transaction Detection

For details about your platform, see:

To get optimal value from AppDynamics, make sure that your business transactions are set up to describe the relevant 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. See Organizing Traffic as Business Transactions and All Other Traffic Business Transaction.

You specify how AppDynamics detects business transactions for your application by:

After you configure entry point detection, improve the usability of the information by:

How AppDynamics Identifies Business Transactions Using Entry Points

When application requests are received by transaction entry points, AppDynamics uses a transaction auto-discovery mechanism to identify the requests as business transactions. AppDynamics uses information from the transaction entry point to name the transaction. Automatic naming conventions include:

  • When a Servlet method executes, name the business transaction after the first two segments of the URI.
  • When a Struts action executes, name the business transaction after the Struts action name.

There are two scopes to identifying business transactions:

  • Automatic transaction naming configurations (sometimes called "global discovery rules" and "auto-detection scheme") by default apply across the entire business application and can be overridden at the tier level. AppDynamics provides default, out-of-the-box automatic configurations. You can modify the automatic global transaction naming configuration across the entire business application or tier in the Transaction Detection Entry Points and Transaction Naming Configuration windows.
  • Custom transaction naming configurations (sometimes called "custom match rules") by default apply across the entire business application and can be overridden at the tier level. AppDynamics provides some platform-specific custom match rules that are disabled by default. When you need different configurations for different parts of the application or different web contexts, add custom match rules in the Transaction Detection and New Business Transaction Match Rule window.  

As you might expect, you can use a combination of the global and specific configurations to effectively identify and represent the most important business transactions in your application. 

Example Entry Point

The ACME Bookstore checkout operation uses the following URL:

http://acmeonline.com/checkout

When this request is received, the application triggers a sequence of actions:

1. On the first tier that receives the request (called the originating tier), the /checkout URI is mapped to a Servlet called CheckoutServlet.

2. On the execution of the doGet/doPost method, AppDynamics uses the URI /checkout to identify the business transaction and name it "Checkout".

3. As the application makes calls to other tiers, AppDynamics maintains the context of this particular transaction. On downstream tiers, entry points correlate to incoming http calls, web service requests, and other communications from instrumented tiers.

Multiple user requests, as long as they follow the same code path, are grouped as a single business transaction. In the ACME Bookstore example, one user-click results in the Checkout Business Transaction being identified as a single transaction. Then, when another user performs the same action, AppDynamics associates the two requests with the same Checkout Business Transaction.

Auto-Discovered Default Entry Points

By default AppDynamics discovers many commonly-used entry points. AppDynamics classifies entry points by the type of framework (such Web Service) and maintains a default detection scheme for each type.

The UI displays the default entry points and allows you to:

  • Completely disable an entry point type.
  • Disable the default discovery mechanism so that only custom configurations can be used instead.
  • Configure transaction naming schemes for some common entry points.

See Web Entry Points and Messaging Entry Points.

If the default entry points do not provide all the business transactions you want to monitor, you can configure how AppDynamics detects your application's entry points.

You may want to do this if the auto-discovered entry points for certain types do not map precisely to the business perspective or if AppDynamics is detecting too many business transactions. When AppDynamics detects too many entry points it creates a special business transaction called "All Other Traffic - <Tier Name>" that you can use to fine-tune your entry points. See All Other Traffic Business Transaction.

Configuring Entry Points

To gain better visibility for selected types of user requests, you can customize how AppDynamics detects business transactions at the tier or application level by configuring custom entry points. You can:

  • Customize detection settings using custom match rules on entry points to establish a set of transactions that represent important business activity while not being too granular.
  • Combine business transactions using custom match rules on entry points to reduce the overall number of business transactions.
  • Use dynamic values to fine-tune transaction detection or exclusion based on a parameter or user data.

For examples see the related topics for your app agent:

Configuring entry points involves:

To access business transaction detection configuration

1. From the left navigation pane select Configure -> Instrumentation.

2. Click the Transaction Detection tab if it is not already selected.

3. Click the detection subtab that corresponds to your environment.

4. Select the tier for which you want to configure the transactions or select the application if you want to configure at the application level.

5. To configure a custom configuration for the tier, select Use Custom Configuration for this tier. For information about inheritance for transaction detection, see Hierarchical Configuration Model.

Custom Match Rules and Transaction Splitting

A custom match rule contains two parts:

 

 

The Match Part part defines different match conditions for various parts of a request, such as the URI pattern, value of a HTTP parameter etc.

The Splitting Part (optional) defines the dynamic part of the rule, used to name the transaction, such as a pointer to the third URI segment, a pointer to a parameter key, etc.

If a splitting part is configured, the transaction will be named as:

(custom match rule name) + (the name derived from the splitting part)

If no splitting part is configured, the name of the transaction will have the name of custom match rule.

Sequence and Precedence for Auto-Naming and Custom Match Rules

AppDynamics transaction detection process uses following sequence for automatically naming the transactions:
1. As soon as the entry point is discovered, AppDynamics checks for a custom match rule. If a custom match rule exists, the business transaction is named based on that rule.
2. If no custom match rule exists, AppDynamics checks the custom exclude rules. If the custom exclude rule exists, the transaction is excluded from discovery.
3. If no custom exclude rule exists, AppDynamics applies its auto-detection naming scheme.

The following illustration shows the sequence for the transaction discovery process:

To create custom match rules

1. In the Custom Match Rules panel of the Transaction Detection tab, click Add (the plus icon).

2. From the dropdown menu select the Entry Point type for which you want to create the custom match rule and click Next.
The New Business Transaction Match Rule window appears for the selected entry point type.

3. Check the check boxes and enter the match criteria for AppDynamics to use to detect business transactions of this type.
The match criteria on which you can configure the rule vary with the entry point type.

4. Click Create Custom Match Rule.

Sample custom match rule

The following rule creates a custom match rule for a business transaction for Servlet-based requests in which the URI begins with "/products/outdoor". This will also be the name of the business transaction in the Business Transactions List, unless you rename it. See Business Transactions List Operations for information about renaming.

Transaction Splitting for Dynamic Discovery

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, the following URL represents a Checkout transaction when a user checks out an item from the electronics section:

http://nwtrader.com/checkout?category=electronics

You can configure the transaction auto-detection mechanism to identify these types of user requests as a Checkout.electronics business transaction by specifying the user request data to use to define the transaction.

With this configuration the business transaction is created dynamically based on the user request. If the request is

http://nwtrader.com/checkout?category=clothing

the transaction would be Checkout.clothing and so on.

Transaction splitting is optional for the entry point types for which it is offered.

If a splitting part is configured, the transaction is named as:

<custom match rule name> + <name derived from the split configuration>

Sample custom match rule with split

This example splits a custom match rule similar to the one created in Sample custom match rule into separate business transactions, one for each color value in the request.

After this configuration is applied, requests that were previously detected as the "/product/outdoor" business transaction are now detected as "/product/outdoor/blue", "/product/outdoor/red" and so on. Now that the "/product/outdoor" business transaction is split, metrics are no longer collected for the old "/product/outdoor" business transaction. Now that the "/product/outdoor" business transaction is split, metrics are no longer collected for the old "/product/outdoor" business transaction.

The Priority Parameter when Multiple Rules Apply

You can use the Priority parameter on a custom rule to specify which rule to apply to the detection of a business transaction if it could be detected by more than one rule. Priority applies from highest number to lowest number. The rule with the highest number is matched first. 0 is the lowest priority. 

Custom rules with whatever priority always have higher precedence over the default auto-discovery rules. 

If none of the custom rules apply, and auto-discovery is enabled, then the auto-discovery rules apply. 

If none of the custom rules apply, and auto-discovery is disabled, then the business transaction is not captured. 

If a business transaction limit is reached before a match rule evaluates, use exclude rules to prevent detecting transactions that you do not need to monitor.

Collect Extra Traffic into a Catch-all Transaction

After configuring the most important entry points, consider creating a new "catch-all" rule to collect all other website traffic. This will help keep down the number of business transactions.

Create a custom match "catch-all" rule where:

  • Entry point type is the default value for the platform (the most commonly encountered entry point type)
  • 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.

(info) 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.

Creating 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.
  • You want to trim the total number of business transactions.
  • You need to substitute a default entry point with a more appropriate entry using a custom match rule.

For example, the Weblogic Jax RPC Servlets rule excludes any business transaction with a servlet-type entry point based on a class with a name that starts with "weblogic.wsee.server.servlet".

The ASP.NET WebService Session Handler rule excludes any business transaction with an ASP.NET-type entry point based on the System.Web.Services.Protocols.SyncSessionlessHandler class.

You can view the other default exclude rules for more examples. See To view default exclude rules.

If you create an exclude rule after transactions based on the exclude criteria have already been created, you need to remove the transactions manually using Actions -> Exclude in the Business Transactions List. See Business Transactions List Operations.

AppDynamics provides and enables default exclude rules for Servlets and for ASP.NET.

You can view, modify, disable, or remove these rules.

To view default exclude rules

1. In the Exclude Rules panel of the Transaction Detection tab, select an existing exclude rule.

Default exclude rules for Java platforms

Default exclude rules for .NET platforms

2. Click Edit (the pencil icon).

3. To exit the exclude rule configuration screen without changing anything, click Cancel.

To create custom exclude rules

1. In the Exclude Rules panel of the Transaction Detection tab, click Add (the plus icon).

2. From the drop-down menu select the Entry Point type for which you want to create the exclude rule and click Next.
The New Exclude Business Transaction Match Rule window appears for the selected entry point type.

3. Enter the match criteria for business transactions to be excluded from discovery.
The match criteria on which you can configure the rule vary with the entry point type. See Match Rule Conditions.

4. Click Create Exclude Rule.

Excluding Business Transactions from 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 business transaction limits.

Excluding transactions using this method 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, AppDynamics may have discovered a business transaction that currently has no traffic. You can find these easily by scanning the Business Transactions List with the Transactions With Performance Data option disabled:

If you know you will never see interesting traffic for the business transaction, you can create an Exclude Rule. If you anticipate traffic in the future, you can exclude it from the UI.

The exclude action in the UI is also useful for business transactions where a single class or service detects many methods/operations, and you want to monitor some but not all of them. If you would have to set up many custom exclude rules, it is simpler to select the subset you do not want and exclude them via the UI.

To exclude a business transaction from the UI

1. In the left navigation panel click Business Transactions.

2. In the Business Transactions List select one or more transactions that you want to delete.

3. Either right-click -> Exclude Transactions or select Actions -> Exclude Transactions.

To resume monitoring the business transaction, you can click More Actions -> View Excluded Transactions and "un-exclude" it from the View Excluded Transactions window.

Deleting Old Unwanted Business Transactions

After you have modified the business transaction discovery configuration using custom match rules, 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.

To delete old unwanted business transactions

1. In the left navigation panel click Business Transactions.

2. In the Business Transactions List select one or more transactions that you want to delete.

3. Click More Actions -> Delete.

Renaming 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 names that are recognizable to everyone who monitors your application. See Organizing Traffic as Business Transactions.

To rename business transactions

1. In the left navigation panel click Business Transactions.

2. In the Business Transactions List select the transaction that you want to rename.

3. Click More Actions -> Rename.

4. Enter the new name and click Rename.

Grouping Business Transactions

Grouping in the UI makes your lists and flowcharts easier to read by reducing visual clutter. It does not decrease the overall count of transactions; to do that see Configuring Entry Points.

For example, you may have a web service that has 20 methods and AppDynamics identifies them as 20 business transactions. You can group them together in the flowmap, and still have access to the metrics for individual transactions in the Business Transactions List. See Organize Business Transactions into Groups.

To group Business Transactions

1. In the left navigation panel, click Monitor -> Business Transactions.
AppDynamics lists the Business Transactions for the application.

2. Select the business transactions you want to visually group together.

3. Right-click and select Create Group.

4. Provide a name for the group.

5. Save the information.

AppDynamics lists the group on the Business Transactions List.

Learn More



Have a question about the topic on this page? Ask the AppDynamics Community.