I'd like to understand the different options for disabling RUM features and RUM injection a bit better. I see these three options:
1. Disable RUM for a process group via Deep Monitoring Troubleshooting settings
2. Disable the option "Automatically inject RUM JS tag" under a process group's settings
3. Disable RUM from the application's settings
Some questions related to that:
A. It looks like option 1 might overwrite option 2, is that correct? So if the Troubleshooting setting says "RUM = off", the process group's setting isn't basically read anymore? Is there anything else that the Troubleshooting setting affects, is it essentially just disabling RUM injection for that process and that's it? And what about having the Troubleshooting setting say "RUM = on" but then I disable it under the process group - will it then be on or off?-)
C. Finally, which of the three require a process restart for the setting to take effect?
Solved! Go to Solution.
we usually used 2 and 3 options to disable JS injecting. option 1 is override in global scope or as override for specific PG(s). Disabling using 2 is effective even option 1 is on (which is usually always on as this is only troubleshooting option).
disabling via 3 affects all calls to specific url/host regardless of PG(s) used, while disabling via 2 is effective for whole PG regardless of url used to access endpoint.
setting 2 or 3 is effective immediately (when injection is done automatically, not via manual js injection) without need of restart
1, 2 and 3 disables injection of JS and thus limits DEM license usage
Got a comment from support:
"if you restart an application with unplaced RUM toggle the following
restart is needed to instrument particular classes again to allow
injecting of JS"
So I suppose it means that you can edit RUM settings and have them applied without a restart. But if you're configuring the "master" switch, i.e. is RUM on or off, that actually does require a restart.