Disabling UEM - When is it going to come to 0 requests.
I have disabled UEM in production now to debug an issue. What I want to know is from when can I expect drop in traffic due to dynatracemonitor requests.
New users are not going to get the js. so that is clear... Current users will have this js till when?
Jibi
Is there a way not to inject js agent for specific uri patterns?
Currently to my knowledge there is no way to limit specific URI patterns from UEM injection. Unless the below scenarios would be acceptable to you.
Create an "Application" with all of the URIs you want/don't want to have UEM enabled for. Then, Either enable or disable UEM for that application specific. Then set the default UEM to be the opposite.
E.g. Application called "UEM Enabled", all URIs that you want UEM on are within the application rules, UEM is enabled for this specific application and the Default UEM is set to server side data only (the slider at the top of the UEM settings).
or
You can set up your application to do manual injection by using the section titled Manual Injection under Web Applications
There is an option since 5.5. In the User Experience Sensor you can specify URI Patterns and how our automatic injection should work on these URIs, e.g: "auto injection", "no injection", "before a specific HTML", ...
Andi
Hi Jibi
Our restrictions are always related to our Auto Injection. It means that our Web Server or Servlet Sensor will ADD the <script> tag to the HTML that is generated by your application. If you specify a restriction we look at e.g. User-Agent or IP and in case it is excluded we wont modify the HTML
Obviously with caching the HTML on a CDN you run into problems in case browsers that you have excluded from injection are now getting an injected version of the HTML page from your CDN. There is nothing we can do about this in the moment.
As for the cached version of an older dtagent.js. The cached document that is important for us is the HTML document. If you upgrade to a new version of dynaTrace the injected JavaScript file has a new name which will show up in the HTML Document. As long as the browser gets this new HTML Document it will download the new version of the JS File
Andi
Thanks Andi. For me it was actually a non cached cart and so I did not have to go through cache clear and all.
Also I was wondering since the pages are cached, is excluding a browser going to really work?
I don't think changing the JS path is going to help?
Also we have this dtagent56_xnp3t_5924.js now. Suppose I upgraade and go to a new version of js. What is going to happen to customers who have the old js version until cache clear/expire?
Rob - Another case today whee i had some issues with IE7 users. So I excluded IE7. Now since the pages are cached, IE7 users will have issues till cache expires or is cleared at Akamai.
My question is if changing the js path going to be of any help before cache clear / expire?
It's the page (your page) that contains the reference to the JS that matters. Until that expires, when users download the page from your CDN they will get a page with a reference to that JS, which means a request to d/l that JS will happen if the JS is not still in the user's browser cache.
It is cached at CDN. What is the expiry for this js?
Jibi
If you've stopped injecting, then there will be no reference in your pages to that JS file so that will not be an issue even if the JS remains in the user's browser cache.
If your pages are cached at a CDN, then you will still see traffic until the cached pages age out.
