AppDynamics switched from Semantic Versioning to Calendar Versioning starting in February 2020 for some agents and March 2020 for the entire product suite.

    Skip to end of metadata
    Go to start of metadata

    Related pages:

    Your Rating:
    1 Star2 Star3 Star4 Star5 Star
    27 rates

    Regular expressions appear 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 topic 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 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, 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*/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:


    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 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.

    • No labels