System Profile - Error Detection

Use the Error Detection item of the System Profile Preferences dialog box to configure the following items:

  • Thresholds for when to alert for overall failed transactions or user actions.
  • Rules for what to report as an error and with what impact.

To access, right-click your system profile and select Edit System Profile > Errors Detection. See Error Analysis for more information.

Alerts

You can configure two kinds of alerts directly from the Error Detection tab. These are alerts based on the rate of failed transactions or user actions within a certain time frame. Use incidents based on failure measures for more advanced alerts.

Both alerts (High Overall Failed Transaction Rate and High Overall Failed User Action Rate) are enabled by default with a time range of five minutes and a threshold of 3%, that trigger an e-mail to the Incident Email Group.

Rules

This lists all existing rules that trigger error reports. You can adapt several out-of-the-box rules to match custom requirements or you can create your own rules.

The following Error Detection rules types are based on captured PurePaths data:

  • HTTP Response Code Rules
  • Logging Rules
  • Java/.NET Exception Rules
  • Browser Error Rules
  • Mobile Error Rules

Each error detection rule defines on of the following impacts:

The error is simply detected and does not have further consequences.
The error indicates that the whole transaction (PurePath) where the error was detected has failed.
The error indicates that the whole PageAction (including the transaction) to which the PurePath belongs has failed.

Configure error detection rules

For each rule, specify:

  • Type.
  • Unique name.
  • Impact. See the previous impacts table.
  • Conditions. See detailed descriptions below for your particular rule type.

Note

To trigger an error all conditions must be fulfilled.

HTTP response code rules

HTTP response code rules are based on data captured by the Servlet Sensor. For each rule in the Rule group box, select target HTTP response class, which is classified as an error, and where it should be captured. You can use response code captured on the web server, on transaction entry, or all of them.

The following conditions can be evaluated for HTTP response code rules:

  • URI: Limits the rule to a specified URI or URI pattern.
  • HTTP Response Code: Includes or excludes specific HTTP response codes.
  • Redirect Target (class 3xx only): Limits the rule to detect errors only if the request has been redirected to a specified target or target pattern.
  • Referrer (class 4xx only): Limits errors detection for requests coming from a specified referrer or referrer pattern.

Logging rules

Logging rules are based on captured log statements. You can restrict rule usage to a particular log level. Specify it in the Rule group box. All other levels are ignored. For the selected log entries additional conditions can be applied:

  • Logger Name
  • Log Message

You can specify a particular logger or message, or templates for them.

Java/.NET exception rules

Java/.NET exception rules are based on captured Java/.NET exceptions. Use the Rule group box to select where the exceptions, which are classified as an error, should be captured for each rule. The following options are available:

  • Captured within a transaction: All exceptions captured by the Java or .NET exception sensor are treated as an error. For these exceptions, you can specify an additional condition or pattern for the applicable Throwable class name.
  • Leaving a transaction: When the entry point of a transaction (PurePath) returns by throwing any exception this rule matches. Capturing the exception by a sensor is not required to detect such exceptions.
  • Occurring on inter-tier calls: Matches when a call is made from tier A to tier B within a transaction and the call-initiating method on tier A or the first method on tier B throws an exception.
  • On database calls: Matches when a database call throws any exception, captured by one of our database sensors.

Browser error rules

Browser error rules are based on the JavaScript errors, detected on the client side by the User Experience Sensor. Use the Rule group box to select browser error severity, which is classified as an error, for each rule. All other browser errors are ignored. You can also restrict rule usage to a particular messages. You can apply additional conditions for the selected browser errors:

  • Action Name
  • Action Type
  • Page Title
  • URI
  • Query

For each of them you can specify a particular entry, or a template.

Mobile error rules

Mobile error rules are based on error events sent by the Mobile App ADK. Use the Rule group box to select which mobile error events should be classified as an error for each rule. Each of them has its own set of conditions:

Conditions for the Error type:

  • Error Message: Do not set it if you want to match an error code.
  • Error Name
  • Error Code: Do not set it if you want to match an error message.
  • Action Name
  • App Version
  • App Build

Conditions for the WebRequest Error type:

  • URL
  • Error Message: Do not set it if you want to match an error code.
  • Response Code: HTTP status code of failed web request.
  • Action Name
  • App Version: CFBundleShortVersionString for iOS and versionName for Android apps.
  • App Build: CFBundleVersion for iOS and versionCode for Android apps.

Conditions for the Crash type:

  • Reason
  • Exception Name
  • App Version: CFBundleShortVersionString for iOS and versionName for Android apps.
  • App Build: CFBundleVersion for iOS and versionCode for Android apps.

For each of them you can specify a particular entry, or a template.

PHP error rules

PHP error rules are based on errors detected on the client side by the PHP Sensor. The following conditions are applied:

  • Error Message
  • Exception Class
  • Throwing Class
  • Throwing Method
  • Error Type

For each of them you can specify a particular entry, or a template.