cannot see the arguments/returns values of method calls
In my case it's OK as the methods are from a couple of classes only used on a very specific case.
But maybe it would be better if I could specify more restrictions on the cases I want them to be inspected, for example allowing me to put restrictions also on the set caller methods that will activate the introspection of the desired methods. Something like a AOP crosscut expression will be great for advanced use cases.
Hey Ramon,
This may not work for your app or organization but I have had a few customers who have actually written "do-nothing" methods and invoked them so they could be sure they were getting the exact data they wanted and nothing more, and could control how often they were invoked so to avoid overhead on the SUD and on dynaTrace.
Glad you were able to get your answer here for now
Rick B
hi guys,
before there's any confusion, I want to give a little background information here
ignore getters/setters
this setting will prohibit instrumentation of any custom sensors into trivial getter/setter methods, regardless if they're specified by <all methods> or explicitly by name.
however, just disabling this setting will of course not add any instrumentation or overhead. it depends on which custom sensor rules you have placed. however, since dynaTrace 4.0 and the introduction of auto-sensors the need for the instrumentation of whole packages or classes including all methods should be mostly gone, anyway.
so, as Pierrick already said: you should only instrument what you really need!
measure explosion vs. overinstrumentation
measure explosion refers to having a huge amount of measures written into the performance warehouse. so, usually just by instrumenting more, you will not get a measure explosion, unless you have a really big amount of measures defined for these methods and also a lot of splittings.
however, instrumenting more methods can lead to overinstrumentation at some point. overinstrumentation will on the one hand introduce some overhead on your application, but will also put load on the dynatrace system that has to handle all the data.
instrumentation of getters/setters
in general, it's perfectly fine to instrument a getter/setter method to capture a specific return value/argument. however, you should take a look at how often you see this getter/setter on your PurePaths, which you can easily do e.g. in the methods dashlet. if you have just 1-10 calls on each PurePath, you should be fine. if you have more than 1000 you should think about an alternative.
hope this helps,
Christian
hi Ramon,
based on your description it should record the return values as you described.
could you please take a look at the Agents Overview dashlet, select the affected agent and look at the bottom on Deployed Sensors. if you search for the SendDocumentForm class there, what does it say? a screenshot would maybe be helpful.
best, Christian
I just solved the issue.
Most of the methods I'm trying to see are getters/setters. To see those values I have to uncheck "Ignore getter and setter methods" on "Sensor Placement" options of my profile config. Sadly it's a global flag and not something I can do per rule or class...
Thanks!
Hi Ramon,
I'm glad you were able to find a solution!
However I would advice to try to find another method that would contain those values,
getters and setters are method that are called very often, therefore, you would increase your overhead greatly by instrumenting them.
That could result in measures explosion among other performance issues.
It is even more important since you are troubleshooting a production environment (we shouldn't have more than 3% overhead).
Please let me know if I can help you in any way,
Have a great day!
If I name the specific getter methods on my "Method Sensor Rules" instead of leaving them catching all methods (<all methods>( * ) ) would it intercept them even if I have "Ignore getter and setter methods" enabled?
Is there a way to know the overhead dynaTrace is incurring on a specific JVM (or at the dynaTrace server level)?
If this parameter is checked then I believe it will ignore it.
What you could do is look for the specific method that calls your getter, see if the paramter is used in this one, and instrument it instead of the getter.
If it's not possible, then only specifiy the name of this getter instead of "<all methods> (*)".
The goal is to only get information that are useful to your case.
If you want to see your overhead, I suggest using a CPU Sample (Diagnose Runtime -> CPU Sampling).
Hope this helps,
Pierrick
Having the caller method introspected is where I started. The problem is that it doesn't give me the values of the other methods that are called inside that method, which is what I will need to check why that bug is happening. That was what made me change to instead introspect those getters. I guess it will be better to explicitly mention each method I need, but most of them are getters so I will need to disable ignoring getters/setters which may add a lot of overhead.
Thanks for the suggestions!
Hello,
I'm new to dynaTrace. I've been trying to catch a problem that only happens on a production server. I've tried to see what are the aguments and return values of a method whenever is called. I created Method Sensor sules matching all methods of a specific class, and marked it as "placed" and "active and start PurePaths", and made sure the "Method return values will be recorded" checkbox is checkd.
I also went to the profile and clicked on "Hot Sensor Placement" to make sure everything was enabled. Still when any of the methods is executed, I don't see any data. Not on the contributions of a PurePath:
Or on the PurePath itself:
(Note: The hot placement was more tha an hour before that PurePath was captured)
Is there anything else I should configure to see those values?
Thanks
