Related pages:

Regular expressions display in various places in the AppDynamics configuration. These places include, for example, transaction detection rules, data collectors, EUM injection settings, health rules, and more. This page describes the use of regular expressions in AppDynamics. 

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

These examples show 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:

/store/jump.*\b?all\b

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*/session/?$ 
  • session 
  • /\d*/session/?$ 

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:

/[a-z]+?[0-9]+?

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:

/[a-zA-Z]+?[0-9]+?

Or match in a case-insensitive manner using the i modifier. For example: 

(?i)\w*cart\w*

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.

Performance Considerations

 Although regular expressions are a powerful way to set AppDynamics configurations, you should consider the following to avoid performance issues:

  • Do not use wildcard expressions unless absolutely needed. You do not need to use wildcard expressions (.*) before or after a match, and each wildcard regular expression results in approximately an order of magnitude performance impact.
  • The number of configurations, the frequency the configuration is applied, and the content length of the target string: For example, if the configuration using a regular expression is applied in many places at high frequency for longer target strings, you might consider reducing the usage of the configuration or decrease the frequency of its application.