I'm trying to exclude a couple of Exceptions that our application handles on its own and does not represent errors to the end user. I managed to have that configured under Deep monitoring > Exclude noisy and unnecessary exceptions, even with redundant and broad filters.
However, problems are still being reported with those Exceptions as the root cause.
Monitored processes have already been restarted. I also tried adding the Exceptions to the specific filter under the Service configuration, but the configuration seems to go away everytime the application is restarted.
On a note, monitored applications are running in a Kubernetes cluster and the agent is deployed using the k8s operator provided by the official helm chart. The operator is configured with apm mode, meaning it is only injected into specific annotated Pods. Infrastructure hosts in this cluster are not monitored. Only pods & containers.
In case someone else comes across this, we finally found a solution... or rather, an explanation.
In our case, even with the Exception listed in the filter to be ignored, related transactions still result in a HTTP 500 error for the user. For those, the application itself has a neatly formatted error page displayed to the end user. But, since the HTTP result code returned to the browser is still 5xx, DynaTrace insists to report that the transaction failed.
It is possible to configure the Service to ignore some HTTP error codes:
In this case, 500 will not be considered as errors. This works, only as far as not reporting any 500 error at all for the entire Service... and this might be desired in some cases.
Either the application changes its behavior to avoid returning HTTP error codes to the user, or the filter needs to be included for the entire Service at the risk of creating false positive scenarios.
Featured Posts
