Monitoring a .net console app or service.. purepaths?
folks,
.net console apps / services usually start with a Main() method.. which in turn calls other methods..
2 questions..
1)
Lets assume Main() calls A() calls B() calls C()
Is it possible to instrument all 4 functions, and ensure each has its own purepath?
What i am observing is that if i specify Main()'s method sensor rule "Capture" column, as "active and start purepaths".. then subsequent methods do not start their own purepaths.. and in a complex batch/service, often exceeds the purepath size.
How do i profile Main() in such a case?
2)
Dynatrace has two places to specify "active and start purepaths".. one at the method sensor level (ie entrypoints), and another in "sensor configuration".. why 2 places? Does one override the other?
Hi Satish,
1) That is the intended behavior and there is no way to change it. The 'active and starts purepath' setting will only start a new PP at that method if there is none currently running. In your case the only way to instrument is to have the start point at a small enough sub-step of the batch job, e.g. method A or B. For diagnosing the main method you could use CPU sampling, as you pointed out the PurePath will run into its limits (size or timewise) there.
2) The one in sensor configuration means that every method in the sensor group or pack will start a PurePath while the one a method level only does this for selected methods.
Best, Roman
Here's a feature request.. maybe it is already there in DT.
Enable a method sensor that profiles ONLY THE METHOD.. and not the stuff it calls underneath..
I guess disabling auto-sensors will give me that view right?
Another feature request.. allow for another setting where I can explicitly start a purepath, even if one is already currently running.. that way i can have 4 separate pure paths for my example.. one each for Main(), A(), B(), and C()..
Let me ask you why you want to have separate purepaths for these methods? I assume you want to chart the response time of these methods - correct? or is there any other reasons for it? in case its just the response time you can create individual measures for these methods and you can chart them individually
In case thats not the use case you are looking for please explain what the reason behind creating multiple purepaths is
andi
i have a couple of issues.. let's assume the structure of the program is like this:
Main()
{
calls A()
calls D()
}
A() { for-loop
{
calls B()
calls C()
} }
Problem 1) I can't start the purepath at Main().. its like the agent can't inject / trace quickly enough, even though i see the sensor deployed. Bug?
Problem 2) to solve the above problem, i start the entry-point / purepath at A()... but then i mysteriously exceed the purepath time, and the PP timeouts!!
Timeout for documentation:
Indicates a PurePath that received not all expected events within the timeout period. This means that either:
At least one method within the PurePath has not returned and for a certain timeout (default 10min) no new data has arrived for the PurePath -> Probably the transaction is stuck
The PurePath is a long running transaction that has not been finished within the "maximum PurePath Age" timeout (default is 1h)
I'm not sure why my purepath times-out..
All the methods, B(), C() and D() complete under 10 mins.. A() could take longer, but because its in a for-loop, i assume "new data" is being generated for it..?
Problem 3) The bodies of each of these methods are equally complex.. with database calls / thread sleep() etc.. The PP shows elapsed time, but doesnt quickly tell me the Exclusive and Inclusive method call times for each method.. where :
Inclusive for A() = method time of A()'s body + B() + C()
Exclusive for A() = only method time for A()'s body
So i have to resort to creating purepaths for each method so i can get a better sense of their exclusive time's.. Maybe this is another feature request for DT.. enable a couple of extra columns at the call-tree level that computes "exclusive" and "inclusive" times.
Charting is not my intent.. just trying to time these methods as granularly as i can..
hi Satish,
concerning 1)
starting the PurePath at Main() should not be a problem in general. however, we strongly discourage it, because you'll very likely get neverending PurePaths which will time-out after some time.
concerning 2)
you should see in the timed-out PurePath, where is it timed out (a node called 'time-out'), which should be shown in your case after the B() and C() calls in method A(), i guess. in this case, this would mean that A() in fact takes more time than the current time-out settings allow.
concerning 3)
dynaTrace already calculates all these times, named as:
Exec Time: excluside time
Exec Total Time: inclusive time
which is also available for CPU/Sync/Wait/Suspension times. and additionally the
Elapsed Time: time a method was started relative after PurePath start
you can get them by right-clicking in the column bar and clicking 'more...'
so i guess these are the timings you need, right?
best,
Christian
apologies for the late reply.. you really helped reveal the hidden columns :) thx!!
the other questions still remain.. ie :
1) why is DT never able to start from Main()?
2) why should the purepath timeout in A()? All A() does is process the for-loop, and B() and C() run under 10 mins.
3) im not getting sync and wait times reported.. another thread open for this.
concerning 1)
usually it IS possible, it's just not something we suggest, because enterprise applications usually run for quite a long time and the PurePaths would time out or run into node limits.
if it's not working in your environment and you really need this, then please open a support ticket.
concerning 2)
if you have a PurePath session, this should give us more insight rather then speculating about the behavior.
my guess would be that A() is taking more than 10 minutes in this for-loop you're talking about. and as long as there are no instrumented methods in this for-loop, there is no new PurePath data generated and it will eventually timeout (as said in the doc).
concerning 3)
should IMHO also be handled by support.
best,
Christian
EMEA Community Member of the Month - November 2018
Announcing Dynatrace's EMEA Community Member of the Month for November 2018, Mathieu C.! Click here to read more! LATAM Community Member of the Month - November 2018
Announcing Dynatrace's LATAM Community Member of the Month for November 2018, Rene S.! Click here to read more! 
