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.
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, Dynatrace 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.
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, 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 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 Dynatrace finds the defined exception (and the optionally-defined exception message) on any request, Dynatrace 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.
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.