Match conditions appear in various places in the AppDynamics configuration. Most often, they are used to determine the applicability of some part of the configuration. For example, they are used in configurations for fine-tuning transaction detection, backend detection, data collectors, EUM injection, and health rules.
A match condition consists of a named property to match (such as a method name, Servlet name, URI, parameter, or hostname), a comparison operator, and a matching value. For complex match conditions, you can use regular expression.
Match rules are case sensitive. Also, matching is based on subsequence pattern matching. To match a complete string instead, you need to include "^" to match the start of the string and "$" to match the end of the string in your regular expression.
In the context of business transaction matching, the pattern does not include the protocol (e.g., " host, port, or query parameters in the URL. So for example, a URI of would be matched by a business transaction regular expression with only "/account/settings.html".
Regular Expression Engines
The Java Agent uses Java libraries for regular expressions. For more information see:
- Tutorial: http://download.oracle.com/javase/tutorial/essential/regex/index.html
- Javadoc: http://download.oracle.com/javase/1.5.0/docs/api/java/util/regex/Pattern.html
The .NET Agent uses the built in .NET regular expressions engine. For more information, see:
The PHP Agent uses PHP's built-in PCRE regular expression engine and requires the same syntax, including delimiters (for example: /^Foo/). For more information, see:
The Python Agent uses Python's regular expression syntax. For more information, see:
The Web Server Agent uses Perl regular expression syntax. See:
Regular Expression Examples
The following sections illustrate examples of how to construct regular expressions to achieve different results.
Matching non-adjacent URL segments
A typical use of regular expressions in the AppDynamics configuration is for business transaction custom match rules in which the expression is matched to a requested URI. In this context, it's common for an application's URI pattern to put information that would be useful for business transaction identification in different segments of the URI.
For example, given an example URL of, a business transaction might need to match on “/store/jump” and “all” to group user requests to view all of an available category.
A regular expression to match this case could be:
Matching any digit
Say you want to ignore numbers contained within a pattern. For example, consider the following URL examples:
Examples of matching regular expressions would be:
Requiring a digit
To group URLs that contain letters then numbers into one business transaction, such as the following:
You could use an expression such as the following:
Not matched would be a URL that does not have digits after the letters, for example: /z.aspx
Handling letter casing
Regular expression matching is performed in a case-sensitive manner. To match any case letters, you can use something similar to the following:
Or match in a case-insensitive fashion using the i modifier. For example:
Would match "addToCart" as well as "addTocart".
Backend Discovery Rules
For an example of a JDBC backend regular expression, see the section JDBC with complex URLs in JDBC Exit Points for Java.
You can find resources for testing your own regular expressions at http://www.regexplanet.com/advanced/java/index.html. This site include a regular expression test pages for many language engines, including Java, JS, .NET, PHP and more.