Improved failure detection for functional errors based on request attributes

Published December 8, 2017 Updated May 12, 2020 6 min read

Michael Kopp

Dynatrace failure detection automatically detects the vast majority of error conditions in your environment, including the underlying root causes of such error conditions. With this approach, Dynatrace is able to provide you with answers when problems occur or when your application performance drops. While automated failure detection works well for technical errors that require the attention of your developers, there are some types of functional errors that Dynatrace can’t detect automatically because the conditions technically aren’t errors from the perspective of the application (for example, a business transaction fails because a credit card has expired or is over limit).

Because we’ve received a lot of feedback from our customers about such functional-error situations, we’ve released a major upgrade to Dynatrace service-failure detection. These enhancements improve the accuracy of Dynatrace failure detection while simultaneously enabling you to detect functional errors in your environment.

Custom error handling and exceptions

Dynatrace automatically detects programming exceptions (Java, .NET, Node.js, and PHP) as the reason for failed requests when the exceptions result in the abort of service calls. Many web containers provide error pages for handled exceptions; Dynatrace detects most of these situations as well. Beyond this, however, 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 now easily be remedied.

To inform Dynatrace which gracefully-handled exceptions should be marked as failed requests

Select Transactions & services from the navigation menu.
Select the service for which you need to adapt failure detection.
Click the […] browse button and select Edit.
Select the Error detection tab.
Within the Custom handled exceptions section of the page, click the Add exception button.
Type in the Exception class that, when associated with a failed request, even if the exception is handled gracefully, the request will be marked as failed.
(Optional) Type in an Exception message to serve as a filter—only exceptions that include the specified message will lead to failed requests.

Following these steps, if Dynatrace finds the defined exception (and optional defined exception message) on any request, Dynatrace will mark that request as failed.

Custom errors, business errors, & request attributes

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

You might imagine that in such cases the actual error messages can be retrieved via some other method call. All of these situations can already be captured via request attributes. For complete details, visit the links below:

You can now use the existence and values of such request attributes as indicators that your requests have failed.

To create a custom error rule

1. Select Transactions & services from the navigation menu.
2. Select the service for which you need to adapt failure detection.
3. Click the […] browse button and select Edit.
4. Select the Error detection tab.
5. Within the Custom errors section of the page, click the Add custom error rule button.
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, a greater than rule, 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.

Other improvements and changes

HTTP client and server-side errors

We’ve also made a variety of other improvements. While we’ve long been able to track the failure of requests both from the calling and the server side, failure detection doesn’t make such a distinction. 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 you can’t fix on your end. The new error detection functionality reflects this:

Consequently, you can now track the failure rate of a service along with the calls to the service, assuming the service is monitored by Dynatrace (see the Failure rate of requests sent by monitored services chart example below).

Improved HTTP response code treatment

In most cases, an empty HTTP response code isn’t indicative of an error, but rather of a client abort situation. However, this isn’t always the case. You can now inform Dynatrace when you consider the absence of an HTTP status code to be indicative of a failed request. Be careful with this on the client side however: “Fire and forget” HTTP posts that don’t wait for responses also don’t have HTTP response codes.

Broken link detection now an opt-in setting

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 used to automatically treat such situations as server-side errors. It turned out however that most of our customers don’t consider such situations to be server-side errors. While the functionality still exists, it’s now no longer the default for new services and is now available as an opt-in setting.

Ignore errors that aren’t errors

In a perfect world, every request that triggers an exception would be considered a failed request. There are however cases where your code (or 3rd-party code you have no control over) returns exceptions that indicate a certain response and not an error. Take the Thrift client for Cassandra, for example. It returns a NotFoundException 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. This could be configured previously, but now the setting is more explicit:

Additionally, you can define a string that must be found within an exception message for the exception to be ignored.

Client abort situations

In contrast to exceptions that must be ignored, there are other exceptions that indicate that a call was aborted and as such shouldn’t be considered as failed under any circumstances—even when other information is available. This can now be explicitly configured as well.

If a service request is left with such an exception, Dynatrace won’t consider the request failed, regardless of the HTTP error code or any other information. Error detection will simply ignore such exceptions.