I need the wisdom and experience of the crowd here:
We have a site which hosts many digital applications. In many cases the end user is experiencing an "application" error - meaning there cold be that no error has been raised on the server. these errors can either be identified by accessing some custom error pages or by seeing some text on the end user page.
The requirement: list all situations where this has happened with information about the end user (i.e. using USQL).
1.how do we identify these situations?
2. can USQL support this query ?
Solved! Go to Solution.
I think the best approach would be to raise these errors by using dtrum API (dtrum.reportError / dtrum.reportCustomError). However, this involves changes in the application code (just call the dtrum api when the error happens for the user) and might not be easy or suitable in your situation.
If this is not applicable in your situation, then if your application redirects the user to an error page, it might be possible to catch this as a user action (Load action probably in this case) and this should be visible in the user session.
Application errors that are just displayed for the user as regular text on the page are more difficult to catch. At the moment you don't have any other options than capture this text by defining a user action property that will capture this text. Probably by using a CSS selector or a server-side request attribute. Typically those errors would be displayed in an element having a class indicating this is an error message, so CSS is probably suitable.
And yes, USQL supports querying sessions having such aspects.
Thanks @Július L.
Code changed are not an option right now. using Load actions would mean it is an action on its own then and usually they are a result of an XHR action so I guess USQL would be hard in this case.
Seems like CSS or server side request attributes are the way to go and that was my thoughts initially. now all is left to do is find out the characteristics of these components when dev guys are not cooperating 😞
If the error pages are XHR, this should be easy to identify anyway.
Identifying those proper CSS selectors might be difficult, especially if they are not standardized in your application.
If you have trouble replicating those errors, maybe session replay functionality would help you. Just capture sessions and if you are able to locate a particular session with an application error, then replay the session and drill down in the replay window to the particular element to find the selector. Not that straightforward, but this is handy especially if you don't have access to the application itself.
Queries on user action properties are available from Dynatrace 1.200 (August 2020).
There are also significant improvements in terms of querying on errors ( just use the usererror table or see some examples in the blog post.)