Maybe removing application errors (http, java) on configure service error detection could be a solution approach for avoiding problems related to increase of faillure rate ?
In affirmative case has to be applied for specific services or is possible to be applied for the complete dynatrace cluster ?
You can do a global setup to change detection rules, via UI and via API. You also can do it by services, but only inside the UI.
Remember that DT learns the way a service might work. At some point, if the behavior of the app is always the same then a normal error rate would be expected, so at some point, they would become frequent errors, and unless the error rate change to a higher value there would be no problems raised about those.
True, though if possible I would still recommend cleaning up the false positive / client-side type of errors from creating a constant noise in failure rate, because when you're reporting things, analyzing issues, etc. it's a nicer scenario to have 0 % failure rate as the "normal" as opposed to e.g. always having a 5-10 % rate there. But yes, purely from an alerting perspective I agree with that.
Well, yeah. Sadly most of the time I see that is just business logic treated as technical errors and those are not real problems, just bad code or use of definition without reading the W3C spec.
And even if the W3C Code description is updated also means that a lot of errors or logic is also bad, years later.
The best way is to understand how the org define such errors for internal application and how it covers external communications and adapt from there.
Well, this seems so obvious, but that's what I try to tell our clients, and help them achieve. Since alerting from Dynatrace is so low in normal circumstances, the way forward is correcting the problems, and than avoiding the situations that could create them...
There are a few situations where some tweaking from Dynatrace would help though, and this RFE comes to mind: