topic Re: Why would data collector info not be included in snapshot's user data? in AppD Archive

Why would data collector info not be included in snapshot's user data?

CommunityUser — Thu, 23 Oct 2014 04:21:48 GMT

I've refactored some Java code to expose data that might otherwise be difficult for AppD to capture and to provide a convenient hook for a data collector. The method looks something like this:

private static long duration(long startNanoTime) {
    return (System.nanoTime() - startNanoTime) / 1000;
}

The data collector is configured to use the method's return value. However, even though I know that the method is being executed, the data collector isn't being displayed in the user data section of the snapshot. Does the method have to appear in the call graph for its return value to also appear in user data? Does a full stack have to be captured? It's obviously possible that this is just a configuration error that I've missed, and I'll keep checking, but I'd appreciate any insight into other possibilities - thanks!

Re: Why would data collector info not be included in snapshot's user data?

Arun_Dasetty — Thu, 23 Oct 2014 09:19:49 GMT

Hi,

To assist you further, please send the following logs:

- screenshot from data collector config and BTs associated from UI?

- screenshot from snapshot and if possible exported snapshot pdf?

- zipped version of agent logs for the same snapshot BT collected above

To answer your query, method does not need to appear in call graph but the method must be part of execution of BT associated for which data collector is configured, hope that clarifies.

Regards,

Arun

Re: Why would data collector info not be included in snapshot's user data?

CommunityUser — Thu, 23 Oct 2014 17:14:42 GMT

It does help clarify, thank you. The method should be executed within an async snapshot of the transaction - is it possible for the data to be "dropped" if AppD doesn't properly identify the start of the async activity?

Kris

Re: Why would data collector info not be included in snapshot's user data?

Arun_Dasetty — Fri, 24 Oct 2014 09:21:33 GMT

Hi Kris,

Your understanding is right, if the async calls are not part of same BT and the api on which collector is defined is part of async calls then the collector data will not be captured.

But we see in ideal cases we should be able to capture async class if the async calls are part of supported apis listed in <fork-config> under <agent-dir>/conf/app-agent-config.xml , Hope that information helps.

Screenshot and logs requested earlier would provide us more insight and clarity here.

Regards,

Arun

Re: Why would data collector info not be included in snapshot's user data?

CommunityUser — Fri, 24 Oct 2014 15:35:41 GMT

Thanks again, Arun. Is there any more detailed documentation available regarding <fork-config> than:

Configure Multi-Threaded Transactions for Java

I'm not quite sure I understand the details of what <exclude>, <include> and <job> are really doing and how they impact async snaps.

Kris

Re: Why would data collector info not be included in snapshot's user data?

Arun_Dasetty — Sat, 25 Oct 2014 01:36:25 GMT

Hi Kris,

Class/packages mentioned in <exclude > section will not be considered for async instrumentation and class/packages stated in <include> under <fork-config> element are considered for async instrumentation and regarding the job elemenet

Say if your class is implementing Thread class or class listed in <job> element in <fork-config> it means they are shown as async exit calls in BT snapshot call graph but if you see that your class is not fallen under any of the <fork-config> -< <job> section in file <agent_install_dir>/conf/app-agent-config.xml than you can add one addition <job> element to add support for async for your classes that implement different thread class:

Hope that clarifies. Also we see no other specific regarding the description on above elements. To better assist you we request you to provide agent logs folder archive version and screenshot from call graoh hightlight the api that you are referring to.

Regards,

Arun