Configure service error detection

Dynatrace failure detection automatically detects the vast majority of error conditions in your environment, including the underlying root causes. With this approach, Dynatrace is able to provide you with answers when problems occur or when your application performance drops.

A detected service error doesn't necessarily mean that a request has failed. There may be cases where the default service-error detection settings don't meet your particular needs. In such cases, you can configure these settings as explained in this topic.

By default, Dynatrace detects:

  • Programming exceptions (Java, .NET, Node.js, and PHP) as the reason for failed requests when exceptions result in the abort of service calls.
  • Error pages provided by many web containers for handled exceptions.
  • HTTP 500599 error codes for web requests are interpreted as errors on the server side.
  • HTTP 400599 error codes for web requests are interpreted as errors on the client side.

Configure error detection

To configure service error detection

  1. In the Dynatrace menu, select Services.
  2. Select the service for which you need to adapt failure detection.
  3. Open the browse menu () and select Edit.
  4. Select the Error detection tab.
  5. From the settings provided (see the following sections), adapt those that are appropriate to your needs.

For further details regarding the supported service error detection settings, see the options below.

HTTP response codes

HTTP-4XX response codes usually only indicate client-side errors, not server-side errors. Normally, you wouldn’t want to be alerted when errors happen due to client problems that are outside of your control. Dynatrace error detection functionality reflects this assumption:

failed request detection

You can however explicitly specify which missing HTTP response codes should be treated as server-side errors and which as client-side errors. You can define multiple ranges separated by commas. For example 400-402, 405-417.

A missing response code is a special case here. In some situations this simply indicates a "fire and forget" call that didn't return a response at all. In other situations it might indicate a timeout or error situation. This is highly dependent on your application. By default, Dynatrace will assume the former. If you still want to report this as an error, select Treat missing HTTP response code as server side error or Treat missing HTTP response code as client side error respectively.

When a web server can’t find a certain page it returns an HTTP 404 response code. Usually, this indicates a problem on the calling side. In cases where the calling side belongs to the same website, this would be considered a broken link. Dynatrace doesn't detect broken links as service failures automatically as most customers don't consider this to be a problem in their service. However you can enable broken link detection as an opt-in setting. Moreover, you can consider additional hosts as belonging to your application by enabling Treat broken links as server side errors and adding the name of the host under Add broken link host rule.

Client abort exceptions

These exceptions indicate that the client aborted the operation. Although these are technical errors, in principle they don't count as failed requests as they aren't caused by faults with the service. If a service request encounters such an exception, Dynatrace consider the request as successful, regardless of the HTTP error code or any other information. Error detection simply ignores such exceptions. You can click Add client-abort exception to add exception classes that indicate such situations.

Ignore exceptions

These are cases where your code (or 3rd-party code that you don't control) returns exceptions that indicate a certain response and not an error. For example, the Thrift client for Cassandra returns a NotFoundException response when a row isn’t found. This isn’t an error, but simply a response code. As such, Dynatrace shouldn’t consider such exceptions as failed request indicators. You can click Add exception to configure this through an explicit setting. Additionally, you can define a string that must be found within an exception message for the exception to be ignored.

Custom handled exceptions

There are situations where application code handles exceptions gracefully in a manner that isn’t automatically detected by Dynatrace. When this happens, Dynatrace doesn’t detect failed requests or alert you to errors. Such situations can easily be remedied by simply specifying an exception class that should result in a failed request. Optionally, you can define a string that must be found in the exception message. If this string isn't found then the exception won't lead to a failed request.

If Dynatrace finds the defined exception (and the optionally-defined exception message) on a request, Dynatrace will mark the request as failed. Note that this won't work if you exclude the exception class from capture in Deep process monitoring settings.

Custom errors

Not all custom error situations are triggered by exceptions. Some error situations are only detectable via a return value or other means. To support such cases, you can define a request attribute that captures the required data. You can then define a custom error rule based on the request attribute that will check the value of the request attribute to determine if the request has failed or not.

There are many cases where requests fail for reasons that are related to business logic. While such situations often aren’t detectable via exceptions or HTTP response codes, they are nevertheless indicative of problems. In fact, these situations may be even more important than situations that are detected via exceptions and response codes. To handle these situations, Dynatrace allows you to use request attributes as indicators for error situations. For example, you might have a business function in your Java code that indicates an error via a return value. In other situations, you might have your own error handling functionality that, when called, indicates a functional business error. All of these situations can be captured via request attributes.

To create a custom error rule

  1. In the Dynatrace menu, select Services.
  2. Select the service for which you need to adapt failure detection.
  3. Open the browse menu () and select Edit.
  4. Select the Error detection tab.
  5. Within the Custom errors section of the page, select Add custom error rule.
  6. Select a request attribute from the displayed list (note that not all listed attributes may be available for the respective service).
  7. Define a condition for the rule. You can define a simple exists rule or a greater than, or a contains rule.

In the example below, a value of -1 in the Amount of recommendations attribute indicates an error. If Dynatrace detects such an error, it will mark the respective service request as failed and explain that the rule match is the reason for the failure.

request attributes