This page applies to an earlier version of the AppDynamics App IQ Platform.
See the latest version of the documentation.

Skip to end of metadata
Go to start of metadata

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. 

Matching Guidelines

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 a regular expression (often abbreviated to just regex)

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., "http://"), host, port, or query parameters in the URL. So for example, a URI of http://www.mysite.com:8000/account/settings.html?action=update 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. See:

The .NET Agent uses the built in .NET regular expressions engine. See:

The Node.js Agent uses JavaScript regular expressions. See:

The PHP Agent uses PHP's built-in PCRE regular expression engine and requires the same syntax, including delimiters (for example: /^Foo/). See:

The Python Agent uses Python's regular expression syntax. 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 http://retailstore.example.com/store/jump/category/shoes/departments/view-all/cat630006p, 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:

  • /group/1/session/

  • /group/1/session/

  • /group/31/session/

  • /group/2/session/

Examples of matching regular expressions would be: 

  • ^/group/\d*/nodsession/?$ 
  • nodsession 
  • /\d*/nodsession/?$ 

Requiring a digit

To group URLs that contain letters then numbers into one business transaction, such as the following:

  • /aaa123.aspx
  • /b1.aspx

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 manner 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 Example JDBC Backend Configuration.


You can find resources for testing your own regular expressions at http://www.regexplanet.com/advanced/java/index.html. There you can find regular expression test pages for many language engines, including Java, JS, .NET, PHP and more.

  • No labels