Showing results for 
Show  only  | Search instead for 
Did you mean: 

Options for disabling RUM


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?-)

B. The third option states "Only applications with injected JavaScript tags can be monitored." -> So actually if I've done either of the first 2 options, and all of that application's data comes via said process group(s), that application setting does nothing since the process group doesn't have the JS tag to begin with. Is the point of the application's settting then more about limiting RUM/DEM license usage, so essentially the JS tag may be there but data just isn't collected?

C. Finally, which of the three require a process restart for the setting to take effect?


DynaMight Pro
DynaMight Pro


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

Alanata a.s.


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.

Featured Posts