Answer by Dorian C. ·
Oh and in case the reason for this is that methods that are called very often shouldn't be instrumented (because of their overhead), well... sometimes the critical piece of information for the diagnosis lies in those methods, we need to know where in the tree and how many times they're called.
Sometimes these methods are also the only thing worth instrumenting, because thats all the app code does (call a method a billion times), and we need to find that out at some point.
Answer by Dorian C. ·
I started using Dynatrace a few weeks ago and one of the thigns that bother me when analysing Purepaths is the fact that the amount of nodes explodes on a regular basis since apparently EVERY SINGLE occurence of a method call / event / purepath node in general is displayed in the Purepath tree.
I found a useful option in the configuration of the JDBC sensor pack which allows me to aggregate all of the similar SQL Statements that are children of the same node.
I wanted to know if the same was possible for methods or for any node that is not a leaf of the tree. In many cases, this makes Purepaths tedious to read at best, and completely useless in some cases.
Another great feature, if it doesn't already exist, would be to allow for complex inclusive and exclusive filters, and not just a Find feature, in order to select what I want to see or not.
Is anyone else having this problem?!
Regards,
Dorian
JANUARY 15, 3:00 PM GMT / 10:00 AM ET