Showing results for 
Show  only  | Search instead for 
Did you mean: 

This product reached the end of support date on March 31, 2021.

Method sensor is not giving the calltree from the method in pure path


Dynatrace verison 7.0.18

I have created a method entry point for a standalone java application. Dynatrace is able to identify the method entry point however it is not providing the call tree from that method.

The entry point has two methods in it

a. static method in logging utils class

b. Private method in the current class.

Both these methods and anything below this are not displayed in the call tree in purepath.



Dynatrace Leader
Dynatrace Leader

What is the typical response time of this new entry point? If it's quite fast, AppMon will not show any details as it's not statistically relevant, unless you explicitly put in sensors for those additional methods. But if it's fast enough additional sensors seem unnecessary.

AppMon tries to find a balance between the cost of measuring and the value of the resulting data. Is it possible for your application the cost/value ratio doesn't justify additional visibility?


In In my test i get the response time of the whole transaction around 300ms. This is a messaging system and expected latency is around 10ms.

There's two options:

1) Explicitly add instrumentation points for the two methods. This will give you the highest accuracy and granularity of metrics, but at a higher runtime cost.

2) Use the CPU Sampler and set the sample rate high enough. You can go as high as 10 ms, but even then it's possible to miss a method invocation that's faster than 10ms. This approach would give you a broader view of what's going on, without needing to know the explicit methods that are called, as well as any downstream calls, including system level calls. This could be used to determine where to put explicit instrumentation points, but CPU Sampler does not give high fidelity response time metrics.

Given your situation I would use the CPU sampler to get an understanding of where most of the 300ms is spent, then optionally define additional instrumentation points as needed for more precise measurements.