I am not quite sure if I can comprehend this correctly.
Because I always encounter the case where Database is the root-cause of other issues, but not the other way round.
Why would slow database caused by a .NET service? anyone has any idea or suggestion on how to understand this? Also, I am not sure if this only comes after enabled AI 2.0 or not.
Solved! Go to Solution.
It is after enabling AI 2.0 (before you would not get those "Metric anomalies detected").
It does not make sense at first, but it is correct - the database requests can be slower - for example, the conditions from the applications have changed (such as different values for prepared statements). Everything might be OK here.
Database, itself can be OK, Dynatrace sees just the same request, but the payload may differ. In this case, you should check the slowest database responses and see what is happening there. Having the "AI" is great, but it won't give you direct answers in all possible situations you can imagine.
We do accept @Július L. answer that is new feature of AI 2.0 but the title here should change from "Root cause" to "Metric anomalies detected" other wise it would be "funny" not to say odd sometimes, for example: root cause of failure rate is less traffic?!
Great insight, thanks to Yos, Julius and also Sebastian.
Let's see how would the A.I 2.0 developed along the way.
To be honest though, right now I still don't enable A.I 2.0 for my customers if possible (well, some are not possible because the customers also has admin access and they enable it by themselves). Somehow I just don't have enough confidence to enable it for my customers, and I believe in this question alone we already see multiples example of it --- that, the new A.I seems to invite more questions than answers