Exclude 5xx Error with specific exception message

[janne_olkoniemi]

Have anyone found some feasible way with Dynatrace to exclude HTTP 500 status codes when they are combined with specif exception classes or messages?

We have an situation than for certain reasons some of our applications are returning HTTP 500 message when they are facing some "normal" business exception (like wrongly filled form as example).

We don't want to filter out the whole HTTP 500 error code from the service level either since it would be too risky solution and would certainly be a problem in some point. Currently it seems that there is no support for exclude rules which would combine rule set like "when there is HTTP 500 code + exception message X == treat it as non-failed call".

[kalle_lahtinen]

Hi Janne,

I've been struggling with the same problem. To me it doesn't look like it's supported at the moment - even if you add the exception to the "Ignored exceptions" list, the 5xx response will basically override that and it's still regarded as a failed request. So... looking forward to hear if anyone has a solution for this, or whether we just need to submit an RFE.

[janne_olkoniemi]

Yep, I have tried also to find some way to get over this but as you mentioned also the 5xx response will override the "ignored exception" rule. So currently the only change seems to be to get lots of false positives or exclude the HTTP 500 competently (which is not solution at all since it will backfire in some point).

Not sure if we could build at least some kind of event filter under alerting profile for this case but at least have not figured out way to do it yet.

[JamesKitson · Accepted solution]

If you're primarily just concerned with the ignoring the exception even when a 500 is returned you can do this by marking it as a client abort exception instead of just as an ignored exception. This takes precedence over HTTP response codes:

[kalle_lahtinen]

Looks like that should work, thanks James!

[janne_olkoniemi]

Yes, this works like a charm in our case 🙂