On this page:
A custom match rule lets you control how AppDynamics generates and names business transactions based on entry point requests.
After you configure custom match rules, it's possible than an incoming request can be matched by more than one of the configured detection rules in AppDynamics. The following sequence shows the order of priority in which transactions are detected and named:
- Upon receipt of the request, AppDynamics checks for a match against a custom match rule. If a custom match rule exists, the business transaction is named based on that rule.
- If no custom match rule exists, AppDynamics checks the custom exclude rules. If the custom exclude rule exists, the transaction is excluded from discovery.
- If no custom exclude rule exists, AppDynamics check the request against the default detection rules, and applies auto-detection naming scheme to the transaction.
The following illustration shows the sequence for the transaction discovery process:
If you want to reverse the order in which the Java and .NET agents evaluate rules so that exclude rules are evaluated before match rules set the check-bt-excludes-early node property to true. By default it is false.
Creating Custom Match Rule
A custom match rule directs AppDynamics to generate business transactions based on the match conditions you configure. The business transactions are named with the name of the match rule. Using them involves:
- Setting the match rule that identifies the class, method, URI, or other match criteria for the entry point.
- Specifying a naming convention for the rule.
- Setting a priority for the rule.
You can create a custom match rule from the Transaction Detection tab under Configuration > Instrumentation
You then choose the Entry Point type for which you want to create the custom match rule and the specific match settings for that type of entry point.
Configuring Custom Match Rules
The following example is a custom match rule that generates business transactions for Web Service GET requests in which the URI begins with "/cart/" followed by a number. The business transaction will be named cart.GET
You can add conditions to the match rule to match based on specific HTTP parameters or hostnames.
For certain HTTP-based request types, such as Servlets or ASP.NET, a match rule can have more than one HTTP Parameter match condition. A request must match all HTTP Parameter conditions to match this rule. (That is, there is an implicit AND operator between the parameters rather than an OR operator.)
You can use more complex regular expression matching. For example, for the following request URLs:
To match any incoming request URL to this business transaction, use the following:
Any request to a URL that includes mysite.com followed by letters (upper or lowercase) and numbers would be matched to this business transaction detection rule. A URL that has no digits after the letters, mysite.com/z.aspx, would not be matched.
See Using Regular Expressions for more information on using regular expressions in the UI.
Setting Match Rule Priority
If a business transaction could be detected by more than one match rule, the Priority field determines the order of precedence for the rules. The priority applies from highest number to lowest number, with 0 being the lowest priority. The rule with the highest number is matched first.
- 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.
Configure Transaction Splitting
For URI based matches, you can configure business transaction splitting. With splitting, you can configure a set of requests that are matched by URI to be resolved into separate business based on a dynamic part of a request. So, for example, incoming requests with the following request URLs:
Could be resolved to two different business transactions, named:
Notice that the transaction is named as:
<custom match rule name> + <name derived from the split configuration>
To specify this configuration, use category as the parameter on which to split transactions: