Partial / Full / Error graphs.

[Dawid.Wrobel]

Hello,

I have a question related to Graphs in Transaction Snapshots.
Why do some snapshots have Full (blue icon) / Partial (gray icon) / Error / No graph?

From where do those transactions gather data and yea - why do some of those transactions have full or partial graphs?

Thanks!

Regards,

DW

[Ryan.Paredez · Accepted solution]

Hi @Dawid.Wrobel,

Thanks for asking your question in the Community. I reached out to the Docs team and they made a quick update to this page to provide more info on your question.

https://docs.appdynamics.com/appd/23.x/latest/en/application-monitoring/business-transactions/troubl...

Here is also a bit more info provided by the awesome @Aaron.Schifman 

AppD continuously creates snapshots at 10 second intervals. This is aside from perhaps a diagnostic session taking place, initiated due to a health rule violation or done manually…but the product is always capturing transactions and if that transaction experiences a deviation from what has been deemed as normal, it creates a snapshot with a call graph…indicated in blue. If, however, that transaction crosses the 10-second window, perhaps because the deviation started at the 5-second mark and went on for 10 more seconds, for example, you will have what is called a partial call graph…seen as grey. If AppD was not able to capture the transaction calls, there simply will be no paper icon. 

[Dawid.Wrobel]

Thanks!

[Dawid.Wrobel]

Hello Ryan,

One question :
You have mentioned that AppD continuously creates snapshots at 10-second intervals. 

The default period is 1 snapshot for every 10 minutes isn't it?

And we can change it but too many snapshots can cause excessive resource consumption.

Regards.

[Aaron.Schifman]

@Dawid.Wrobel I am not sure of how you can change the snapshotting...that is generally handled by support, or perhaps it is something you would have access to, but I cannot advise of that.

The frequency that is default should be sufficient. I do get asked this question, especially around the fact that not all snapshots contain the call graphs which really make them valuable. The way I see it, there are enough snapshots that happen to account for providing the information you would need, without having to adjust those settings. 

The fact that if there is a systemic issue, it will be captured as you need. If you need to, you can also initiate what we call a diagnostic session which will be providing much more at a more controlled fashion. Those sessions should only be used when there is an issue that is not being resolved by the systems snapshots, or, perhaps because the problem is not seen as sufficiently abnormal to our AI engine. 

In summay...I would advise not changing the default settings, acknowledging your point about performance, and instead, leverage a diagnostic session just for a specific time frame. 
I hope this helps...

[Aaron.Schifman]

Here is the diagnostic session documentation link: https://docs.appdynamics.com/appd/23.x/latest/en/application-monitoring/business-transactions/troubl...

[Dawid.Wrobel]

Hello @Aaron.Schifman 
Two questions, one of which I have already mentioned :

The default period is 1 snapshot for every 10 minutes isn't it?
And we can change it but too many snapshots can cause excessive resource consumption.

I could see the reply from Aaron, but I'm preparing for the role of AppD and want to know in detail about this case.
I know how to change snapshotting (Transaction Snapshots  -> Configure -> Configure for Slow/Stall Transaction).

Second question :
You mentioned "If AppD was not able to capture the transaction calls, there simply will be no paper icon. "

What will be the case when AppD will not be able to capture the transaction calls?
Can you give me some examples?

Regards and thanks for your help!

Regards.

[Aaron.Schifman]

@Dawid.Wrobel 

Correct...AppDynamics, by default, will create a snapshot every 10 minutes, and they capture a 10-second window unless they are in what is called a diagnostic session. 

The UI can be used as you mentioned to change the frequency, but I must have misunderstood your question. I assumed you wanted to change the time period for what is captured...rather than the frequency. 

If you feel there is a need to take more frequent snapshots, I would ask what that reason is, and from my experiences, that change happens when there are systemic issues happening and the default rules don't do a good enough job capturing what is needed for troubleshooting, therefore, I suggest creating a manual diagnostic session rather than changing those types of global settings. 

If no paper icon is available, meaning, there is no partial or full call graph, it just means a snapshot was created without there being a slow, very slow, or error that will put the transaction into a diagnostic session. It can almost be considered normal operations or behavior.

Call graphs, whether they are partial or full, generate due to a diagnostic session. AppD can create the diagnostic session or you can manually. If you look at the differences, you will see a partial call graph does get to the line causing a violation, but will not encompass the entire flow like when having a full call graph...which is very useful if you want to know what is effected or being caused by downstream or upstream transactions.

If a transaction happens that deviates from a normal activity during the snapshot being captured, AppD will start a diagnostic session which will capture the method calls seen in a call graph. Depending on when that diagnostic session started, you may/may not get the whole transaction flow.

If nothing deviates from what AppD thinks is normal, then there would be no reason a diagnostic session gets created, meaning a call graph wont be generated and that is when we wont see a paper icon.

You can initiate a diagnostic session manually or via rules which will give you the control to capture when, for how long and how many snapshots per minute you want...which will surely get you the details you need.  

I am happy to try and help some more if you have further questions.