In this article I’ll show how to check when the client-side monitoring has been disabled by uX filtering using uX traceLog. This is one of the most common steps to troubleshoot uX monitoring configuration.
First you probably recheck everything once again:
- the application is added to both Server and Client side monitoring – check,
- Server and Client monitoring are enabled – check,
- your application passes uX ACS (Application Code Scan) checking successfully – check,
- connection string to CSMCollector is valid,
- web application was restarted,
- even the client-side threshold has zero value..
- no errors in Intercept Log as well as no uX events in SEViewer.
- server events are collected as expected and defenitely suggest there will be client event…
But the UX events are not there.
What you probably hitting is the request filtering. Those filters can be enabled on specific application level or even under the “Web Applications” node. In desperation you disable all filters, run IISRESET, fire up your app and … voila – there are the client-side events.
But you need filters! They help to avoid the excessive noise and overhead and sometimes even prevent bad stuff from happening to application response. How can you find the exact filter you need to tweak / disable?
Fortunately uX 5.7 has log to help us. It is called traceLog and you can enable it in “CSM.action.config” (you should set “enable” for the whole section agentDiagnostics and for traceLog in particular):
Application restart is not required, you just need to save file and to refresh the browser page with F5. Collected log can be found in “C:\Program Files\AVIcode\Intercept\Agent\v5.7.491\Logs” folder.
Let us see how it works. First we need to create some test filter (as you remember we’ve already turned them all off).
Open uX Management Console and add DENY filter, for example, disabling client-side monitoring for the “Default.aspx” page of your application:
Next, restart your application to apply monitoring changes and browse “Default.aspx” page. View the page source and, of course, find no uX-injection.
Now let us take a look at what has been logged. Here it is – the log shows you that the request to “Default.aspx” has been filtered by our DenyFilter:
The log message is somewhat cryptic but you can see which filter is responsible. Now you can do the same thing but beware that this log can be rather heavy in a loaded environment. If you happen to have an HA cluster, it is a good idea to play safe, route smaller number of calls to a designated node and do the magic there.