09 Jan 2023 10:32 PM - last edited on 10 Jan 2023 02:21 AM by MaciejNeumann
In the release notes of version 1.256 you can find above change, a good reminder to always read these before you implement a new version 😀
The question from my side is, why this default behavior changed by Dynatrace? Or more general what are reasons to changing existing default setiings?
Solved! Go to Solution.
Good catch 🙂 Yes we decided to disable baseline alerts for this specific singelton service by default because we found it always generates a load of alert spam. Reason for this is that the baseline most likely never fits as this singleton service acts as a catch-all for all the non-mapped service endpoints. Those endpoints do not have anything in common between each other and also the baseline therefore is not really valuable.
Another issue is that multiple events on this single service always leads to the detection and muting of a so called Frequent issue, which means we detect a load of events which we automatically mute afterwards again. Reason for that is that all those unrelated endpoints share this artificial service.
In case that your service does not catch too many endpoints you can easily override the default again as this is a singleton service and you just need to switch the toggle again.
I would recommend to split out important endpoints into separate services which then get a valid baseline and where the frequent issue detection does not interfer.
I hope that answer helps to understand our reasoning behind changing the defaults here.
We will further enhance the release note entry to give more context about the decision.
A perfect answer,!