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.
599error codes for web requests are interpreted as errors on the server side.
599error 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-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:
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, Dynatrace will assume the former. You can choose the latter as an opt-in.
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 won’t consider the request as failed, regardless of the HTTP error code or any other information. Error detection simply ignores such exceptions. You can add exception classes that indicate such situations.
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 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.
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.
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.
Detection of business logic-related errors using 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 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 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.