It's not a bug - that decision was intentionally made as there was a lot of confusion around the fact that a PurePaths view will only show 100 PurePaths at a time and if you use the PurePaths view to sort by something like response time it lead people to the conclusion that transactions were being missed instead of just not being in that 100 that got included.
Basically the issue was too many users using the PurePaths view to start an investigation rather than being where the final analysis is done if required. Using the filtering options and other analysis views to find the slowest transactions (the 'zoom in' feature is especially helpful) can get you to a point where you have only a handful of PurePaths to look through as opposed to trying to sort through 100+ PurePaths.
I'm sure there is feedback coming in that this change can also lead to confusion so perhaps this will change but at the moment it is not a bug.
I encounter the same remarks at customer.
Maybe it could be great to have an intermediate behavior: having the ability to sort the results, but only if there are 100 results or less (if not, sort feature would be disabled).
I would say that decision is making Dynatrace SaaS to go backwards not forward. Any APM tool should be able to have a feature that allows sorting by certain metrics. Especially considering that Dynatrace AppMon has same feature.
Why not make it as feature flag? those who do not want - they can disable from some settings. Also if they don't want to use that sorting, simply they should not use it.
For me, that is the most important feature to start troubleshooting anything.
Could you elaborate how you use this for troubleshooting? which column are you sorting and what kind of answers does that give you?
Typically we would encourage our users to use any of the more specialized views that are able to deal with many thousands of requests and tell you the answers right away, instead of looking manually at a list of requests.
This way Dynatrace leverages the PurePath data and gives you answers instead of just serving data.
Any of these analysis views has the same filter possibilities as the PurePath views and provides rich analysis capabilities.
* Response time analysis
* Outlier analysis to find slow requests (instead of sorting by response time in PP list)
This one very naturally leads to a list of just a few PurePath that then make sense to look at individually
* Failure analysis to understand errors
* Service Flow and Backtrace for flow analysis, with rich multi tier filters
* The TopX request and attribute tables at the bottom of service screens
* Multi-dimensional analysis views to slice and dice data the way you want graphically
As you stated, when you deal with many requests, a list is not really that helpful, we would rather give you the answer straight away. Can you help me understand what you are trying to achieve?
@Michael K., currently, for some of our systems we use AppMon, and for some Dynatrace SaaS. We have been using AppMon for over 5 years and obviously got used to the way it works etc... My understanding from Pre Sales technical engineer , which we met here, is that Dynatrace SaaS will eventually have most features of AppMon and also should almost work similarly in terms of how we troubleshoot etc... and to me so far it looked correct (of course not everything is exactly the same, but I could find what I needed using same techniques I used with AppMon). However, removing the sort feature in pure path, how to say , "broke my heart" : ) Our aim was to move everything to Dynatrace SaaS eventually.
I strongly believe that the main key difference between Dynatrace (AppMon or SaaS) and other APM tools is that, it is able to track each and every single request. This is the key differentiator for us as in our systems we must be able to track every request slow or fast. Could you, please, elaborate a bit more about purePath showing only last 100 pure paths, how can we see what was before that 100th purePath? I thought if we select past 5 mins then we could go backwards and then we can find?
There are 2 main cases I use sort feature.
1. In general, i.e we open pure path and we just want to know what is slow and we sort by response Time. Have a look at this sample:
Without being able to sort, how can one know?
2. 2nd case , in Analyze outlier -> then going to pure path. like I said , there are many requests here but we want to concentrate on slowest ones, and without sort feature we must use our "eyes". See this sample picture:
In general the PP view does not show all the Purepath there is in one list. That is because even if we give you a list of 10000 you could not look at them manually. The intention is to use that view as a result not an analysis view. Therefore I recommend to
* use the outlier analysis to find slowest and correlation between error and time
* Use the response time hotspot to understand why a certain set of requests is slow
* Use the failure analysis screen to understand why some requests failed
* Use the service flow to understand where in the call chain the time is spent
Use all of these views and the "Add Filter" to narrow down you pp list. Once you have narrowed it down you can then look at each of them of course. You "can" look at 10 I guess but you can't look at 1000 manually. That is what Dynatrace should do for you.
That being said we are about to improve the list view to cater better for the finding slow and error use case and also to make it easier to look at certain timeframes and more.
One issue we've encountered on this topic is that we are unable to locate a specific PurePath (a user encountering an issue that is disconnected from the User Action) in which we are unable to locate it due to the view constraints (Top 100). We will certainly look to link the PurePath and the User Action in the future in addition to capturing contextual request attributes to filter, however, for that particular user, we may not be able to locate the transaction due to the viewing constraints.
Have you tried to use the User sessions view? it allows you to go to a specific user, to a specific visit and session of the user. You'll see all requests and can go to the individual PP from there? The PP list is not meant as an entry point for this, the filtering pattern would be rather complicated.
the search actually allows you to search all. if you type into the search field it will tell you that you can filter on the server which might be slower but will do the trick. That being said please also use the Add filter function it has very powerful search capabilities. even hierarchical (which DB do you call, or from where does a Call come from) are possible.
We also have the same issue - we are missing the coolest feature. @Michael K. we used PPts for complete diagnostics...we were able to trace each request that happened on the system!
What is the example use case for displaying last 100 PPts ?
"With PurePath technology, you get complete diagnostics, such as timing data and code-level context, across the entire user click path spanning device, operating system, page actions, methods, code, and bind values. This enables more accurate reporting, granular business transaction grouping, precise SLA management, and fast root cause resolution."
The Purepaths are all there, but we want to give you better ways then a list to find the.
* Outlier analysis to find slow/fast requests or of a certain range
* Service Flow to understand the flow of your requests and you can use this to filter requests based on call patterns
* Backtrace to understand where requests are coming from.
* Response time hotspot to understand why a certain request set is slow
* Filter options on all of the views that are very powerful.
Basically All other views look at all requests and are designed to give you answers instead of just a list of requests.
The reason for the PP list is really just if you want to navigate to one. It is not meant to be a standalone analysis view, it is more of a result view for other analysis views. E.g. if we give you a list with a 1000 then you could still not easily look at all of them manually. Dynatrace can and does this is what the analysis views are all about.
You can also apply any kind of filter to the PP view but also to all other views. Actually the other views apply filters as part of their analysis steps and reduce the PP you look at.
See this video for example: https://www.youtube.com/watch?v=bbZdkuClx-E
It explains how to use service flow to slice through a large number of PurePaths and find the ones you are looking for.
All of that not withstanding we are about to add some more power to the PP list itself to make it more usable and also to make it more obvious how to best use it and other views to find slowest or failed requests that fit a certain pattern.
Finding it very difficult with new change without having an option to sort by Response Time, looks to be there are lot of filter conditions added but when we have an critical issue in prod like a stuck thread or a transaction stuck with wait time or application getting slow with transactions taking time with DB SQLs, sorting by response time will point us to the issue with in seconds, with lot of filter options without knowing which filter to apply for that real time issue and i believe we cannot pre determine an filter for a real time prod analysis.
This is making things more complicated and all our users are finding very tough with this change.
Would be great if you can atleast add an capablity to sort slow/ very slow transactions , current filter options doesnt help much, it may help people doing a historical analysis and not for the one who needs to quickly debug a production issue.
Can I ask why you did not try the Response Time Analysis view, it has been built specifically to show these kind of problems right away.
We will add functionality to find the slowest one, the issue is that the sort did not do that. It just sorted the result which is only the 100 last purepath based on filters. People expected the sort to really go through all Purepath and deliver the slowest ones and opened support tickets for this.
As a result we instead looked at the use cases again and will add functionality to cater for finding slowest (among other things) more directly.
@Michael K., reasoning is understood, but not being able to sort is annoying. we want to sort. What if we want to find slowest from the slow transactions. currently we have to use our eyes to find it. Why not just make it as feature flag. whoever does not want it then they can disable it? even if it sorts whatever listed in page then it is good enough.
@Michael K.yes it makes more sense to have a feature flag and let the customers have an option to decide they need sorting by response time capability or not instead of completly removing that capability .
Eventhough it may be listing 100 sorting will atleast help sort from that 100 for a small time duration instead of clicking through 10 different buttons .