Exclude/Ignore HTTP 5xx Series Error with specific exception message

[janne_olkoniemi]

Could someone confirm that can we still ignore even HTTP 500 class exceptions by utilizing the Client abort exception? As far I have understood correctly we could utilize the following option to exclude exception even when a 500+ is returned.

We are trying to exclude exception from calls which are throwing "500 - Internal Server Error" and have excluded the following exception RequestError / "Samat tiedot muokattavana toisessa ikkunassa" as client abort exception but the exception rules are not working on this case.

[ChadTurner · Accepted solution]

Yes this is correct 🙂 

[janne_olkoniemi]

Just to confirm, that should we still be able to exclude the HTTP 500 series vie Client abort exception since I got this answer to my support ticket. So currently little bit confused that should it work or not.

If you look at the error detection result on the call, you can see that the call fails because of the HTTP code (500), not because of an exception. You could suppress 500, but that is usually not what you would like to have. Currently, there is no way of doing something like "ignore 500 if a specific "harmless" exception is thrown"; this is a known shortcoming of the current failure detection approach.

[Malaik]

Hi @janne_olkoniemi 
Im facing exactly the same problematic.

[Julius_Loman]

It works as described. You can use client abort - if such an exception is found, the request is automatically considered as successful. It will definitely work for the use case above.

[janne_olkoniemi]

Yep, that's something that I also expected about but we have case where is not working and I had support ticket open about the case and I got the following answer from support.

If you look at the error detection result on the call, you can see that the call fails because of the HTTP code (500), not because of an exception. You could suppress 500, but that is usually not what you would like to have. Currently, there is no way of doing something like "ignore 500 if a specific "harmless" exception is thrown"; this is a known shortcoming of the current failure detection approach.

[Julius_Loman]

Hi @janne_olkoniemi ,

I believe the answer you have from support is incorrect. I use the client abort exception list exactly for this purpose and it works as I described. However be aware of the fact if such exception occurred it is automatically marked as successful. If there is another exception in the service call representing failed request it will be ignored. So put in the client abort exceptions only those when you are confident these request are successful.

[Malaik]

Hi @Julius_Loman 
I get exactly the same response from the support

For The client abort exception:
You need to put this exception under every single service? or you made it globally via API?

If via API, could you please show us the parameter and the rule you are using?

But, for the mentioned note

If there is another exception in the service call representing failed request it will be ignored.

Its not also correct to ignore such an exception.

[Julius_Loman]

Hi @Malaik ,

you will either need to put this exception for each service in the failure detection settings or you can use the failure detection api to apply the setting across set of services. The failure detection API is an early-access feature and settings made using the Failure Detection API are not (yet) visible in the UI. 

Using the API you need to create a Parameter Set and use the successForcingExceptionPatterns properties. Then you need to create a detection rule describing where to apply the Parameter Set. For example for services having a particular tag.

For the note - the exception won't be ignored as such, it's still visible in the PurePath. It just won't be a reason for a failure if the request contains an exception from the client abort exception list for the service.

Hope this helps.
Julius

[Malaik]

Thanks @Julius_Loman 

This is exactly What I did.

Whether under the service itself or globally via API, some failures still going up.

Thanks and good day.

[Julius_Loman]

Hi @Malaik ,

please check the reasons in the Errors tab for such requests or use the "View details of failures" analysis.

[Malaik]

Thanks

I created this rule:

{
"id": "FDP_2",
"name": "shipping",
"description": "for requests from shipping module",
"clientSideMissingHttpCodeIsFailure": false,
"serverSideMissingHttpCodeIsFailure": false,
"failingHttpCodesClientSide": "400-599",
"failingHttpCodesServerSide": "500-599",
"http404NotFoundFailureEnabled": false,
"brokenLinkDomains": [
"mydomain.com"
],
"successForcingExceptionPatterns": [
{
"classPattern": "System.Net.WebException",
"messagePattern": "The remote server returned an error: (500) Internal Server Error."
}
],
"tagConditions": [
{
"tagKey": "myTag",
"predicate": {
"type": "STRING_EQUALS",
"value": "NG",
"ignoreCase": true
}
}
]
}

After, this exceptions still coming:

[Malaik]

Thanks @Julius_Loman 

This is exactly What I did.

Whether under the service itself or globally via API, some failures still going up.

Thanks and good day.

[janne_olkoniemi]

Our case is little bit different since the same error happens on the database call which the "root" service has made. So even when we have excluded the event from the database also it seems that it causes that our root level exception rule does not work.

Got the following confirmation trough our Dynatrace technical contact also that's the case currently and need to find a some other way to play around than the client abort exception rule.

The reason why the client abort exception does not work in this case is because the way this feature is designed to work is to check the root node for an exception. In the provided example the exception happens somewhere on the node tree. The reason why this feature was implemented like this is because there is no way to preserve consistent behavior if we want to enforce success forcing exceptions happening somewhere on the node tree. For example, what should be the outcome when the node entry point has a success forcing exception but also there is another exception(s) happening somewhere on the node tree.