Working with PurePath Tree View for Java
I am using dT 6.0 and very new to it. I require some tips in de-mystifying PP tree view for Java Web. As I understand it, it is a view of a single invocation but there are elements to the tree view that don't appear to corroborate this.
Example: this is from a PP view of an occurrence of an error that happened during execution of the Servlet filter chain:
doFilter(...)
Database Summary [list of SQL calls]
exception
exception
... (more exceptions)
doFilterInternal [start of call stack]
doFilterInternal [start of call stack]
My Questions:
- While the Database Summary is nice, it would be great to show when/where in the call stack the SQL queries are being executed. But drilling down into either doFilterInternal doesn't show this clearly. I do see a query method call to JdbcTemplate, but the argument column is blank so the query is not shown there
- Related: how to instrument to at least get all SQL queries passed as arguments to properly show up under argument column
- Why are multiple exceptions being shown? Is this due to nested exceptions? Would the first exception listed be the root exception? Similar to the DB queries above, it's also not clear when/where in the call stack these exceptions are being thrown.
- Why are there two doFilterInternal calls for single invocation that this is showing?
- Biggest mystery to me is how dT determines what particular call stack to show in the PP tree view. How is this generally decided? For example, if a method used other objects to call other methods:
isSystemInit(DataSource ds) {
final Tenant tenant = ds.getTenant();
final boolean init = checkInit(tenant, ...);
...
doSomethingElse(...)
}
In PP tree view for the above, you won't see a trace for getTenant, but you may see one for checkInit. You may also see a trace for doSomethingElse, or you may not. How is this decided?
Hopefully someone can help explain this a little bit better, or point me to an in-depth Java based tutorial on this! Thanks!
A PurePath represents all methods called during a single transaction. We basically follow the transaction based on Byte Code Instrumentation with Sensors, and also pick up methods invoked using CPU sampling (Auto Sensors). So we "decide" what to show by the placement of Sensors, but the Auto Sensors just pick up whatever methods might be running in between these methods, which we then correlate to the PurePath based on thread id.
Auto Sensor methods are light grey and italicized in the PurePath tree. They only have estimated timings and have no context information since we are not "in the method" to get more details as we can with instrumented methods.
You can get a lot of good information about PurePaths from this page: PurePaths
Also, the APM University will have lots of additional information about PurePaths, Sensors, Database-related questions and much more.
To see database query variables passed in prepared statements, you can enable bind variables. This will also turn off aggregation of SQL, which is the default. You should then be able to better see in the PurePath where exactly the SQL was called. Just be aware that pulling bind variables induces overhead on the agent. Also, the lack of aggregation will lead to more nodes in the PurePath tree, so that will have a performance impact on the dynatrace server.
In 6.1, there is a new feature to allow exception aggregation.
The database query information is generally visible in the PurePath SQL statements, and in the Database and Database Hotspots dashlets.
You can drill down from an SQL statement to the calling PurePath, which helps put things in context.
I hope this helps you some!
Yes it does David, thank-you!
I now understand that Auto Sensors are implemented with CPU sampling and not the same as full on instrumentation.
I will look into bind variables for the SQL queries.
I'm still not clear on the exceptions however. Can you provide more details? What is meant by exception aggregation? If we're viewing a single thread, I'm still not clear why multiple exceptions are being listed (some exceptions even mentioned more than once). Is this due to nested exceptions? It's not clear from viewing all the exceptions where these are actually thrown in the pure path (similar to my problem with SQL queries not shown in the pure path).
Thanks again!
Roy
I think you are correct that they are from nested exceptions, or they could be due to code that is letting exceptions "bubble up". Methods can either catch and re-throw exceptions or just declare the exceptions thrown to let them "bubble up".
I copied this question and answer from an old internal post since the question was identical to yours:
Working with a customer and notified there are lot of exceptions in the purepath. Customer claimed they do not have those exceptions from their code and puzzled by those expcetions.
From the purepath tree, the hierarchy does not provide inside on where are those exceptions from,
Exceptions in the PurePaths are shown underneath the latest Instrumented Method. That is obviously not necessarily the method where this excxeption was thrown. Simply open the Details Dialog on these Exceptions and you will see the full stack trace and with that knowing where this exception was thrown. Many excepetions happen within frameworks that never make it to the surface of the custom code - thats why customers are typcially surprised about that many exceptions. The Details dialog will give you more details.
If you dont see Details it is probably because of our Exception Sensor Overhead Protection. We only capture a certain amount of full stack traces per second in order to keep overhead low. (Original Internal Post)
As of dynaTrace 6.1, Exception Aggregation is available to reduce the PurePath node count in situations where many exceptions are thrown.
The aggregation is done per instrumented node level. The first 3 exceptions are captured normally (including stacktrace, if configured so). Beginning with the 4th exception, aggregation will take effect and only count occurences of distinct class+message combinations.
See this page for more details. Java Exception Sensor
More details on Exceptions
Hope this helps!
