Configure service error detection

DESK failure detection automatically detects the vast majority of error conditions in your environment, including the underlying root causes. With this approach, DESK 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, DESK 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 500-599 error codes for web requests are interpreted as errors on the server side.
HTTP 400-599 error codes for web requests are interpreted as errors on the client side.

To configure service error detection

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.
From the settings provided (see the following sections), adapt those appropriate for 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. DESK error detection functionality reflects this assumption:

You can however explicitly specify which missing HTTP response codes should be treated as server side errors and which as client side errors.

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, DESK will assume the former. You can choose the latter as an opt-in.

HTTP 404 - broken link configuration

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

Requests aborted by the caller

Some exceptions indicate that the client aborted the operation. Although this is a technical error, in principle doesn't count as a failed request as it's not something that is the services fault. If a service request encounters such an exception, DESK won’t consider the request failed, regardless of the HTTP error code or any other information. Error detection will simply ignore such exceptions. You can add exception classes that indicate such situations.

Ignore exceptions

There are 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, DESK shouldn’t consider such exceptions as failed request indicators. You can configure this, through an explicit setting, as shown below.

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 DESK. When this happens, DESK doesn’t detect failed requests or alert you to errors. Such situations can easily be remedied by simply specifying any 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 is not found then the exception will not lead to a failed request.

If DESK finds the defined exception (and the optionally-defined exception message) on any request, DESK will mark that request as failed. Note that this will not work if you excluded the exception class from being captured in the Deep 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 decide 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, DESK 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

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 errors section of the page, click the Add custom error rule button.
Select a request attribute from the displayed list (note that not all listed attributes may be available for the respective service).
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 DESK 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

Detection of business logic-related errors using request attributes