on 17 Jan 2024 07:11 PM - edited on 20 Feb 2024 01:07 PM by HannahM
When the RUM breaks the monitored web application, we tend to turn off the whole RUM Application / Process Group to save the end-user from misery. Then, it might be a challenge to convince ourselves to enable it back for troubleshooting Support.
It's possible with single client IP(s) exclusion/inclusion enabled. Still, the real client IP addresses are often not configured in Dynatrace and represent a proxy or Load balancer IP.
The idea is to restrict the Dynatrace RUM to be enabled to a "futuristic", unreal client IP and overcome this restriction in a single browser instance where we want to play with RUM to troubleshoot a breaking scenario. For example, the 8.8.8.8
IP address is a Google DNS, so there is no chance that any of the clients monitored by Dyntarace can get it. Let's configure Dynatrace to enable RUM only for this IP and then overcome this restriction in two possible ways:
by sending a custom HTTP header with a fake client IP (8.8.8.8
)
or
modifying the User-Agent
header in the browser
The network must not remove custom HTTP headers,
We must install ModHeader browser extension,
The monitored website is not sensitive to modified User-Agent
header.
Convince the customer to install ModHeader browser extension in their selected browser,
Configure the name of the custom HTTP request header - make sure the name is unique, and the value is != other client IPs. The 8.8.8.8
might be a good choice.
Example configuration:
Note: The checkbox next to the name of the custom header disables/enables the header presence.
Make sure the next request contains the header in HTTP:
Go to Settings
-> Web and mobile monitoring
-> IP determination
Note: Ensure the created entry is at the top of the list.
Go to problematic RUM Application -> edit Settings
-> Capturing
-> Exclusions
-> IP address exclusions
,
Add the fake IP configured previously and flip the These are the only IP addresses that should be monitored
flag ON:
User-Agent
header in the browserIf browser extension and/or using custom HTTP headers is/are not possible, there is another way:
Go to problematic RUM Application -> edit Settings
-> Capturing
-> Exclusions
-> IP address exclusions
,
Add the fake client IP and flip the These are the only IP addresses that should be monitored
flag ON:
In the browser, configure dtHealthCheckIgnoreRestrictions
User-Agent:
The RUM injection will happen for this very browser; nevertheless, we send our real client IP that is different than the configured 8.8.8.8
.
This may not work if the web application is sensitive to non-standard User-Agents. Most likely, the page won't load.
If that's the case, contact Support, refer to this post, and ask for "configuring restriction ignoring" for User-Agent that is acceptable for the monitored website.
Neat trick! Of course, I remembered immediately the episode I did with Andi, regarding strategies to deal with the situation where RUM might break an application. Check it out after 21:52, in https://community.dynatrace.com/t5/Videos/Dynatrace-Tips-amp-Tricks-Episode-4-with-Antonio-Sousa/m-p...
Also going to link there back to this one, so we have one more trick in our sleeves 😉
Thank you for sharing this information.
If we keep Real User Monitoring (RUM) enabled, the Ruxit agent is injected into the web browsers of all clients.
If Ruxit remains injected, it could potentially impact the application right
@prasad_arugonda , if you configure below, there will be no HTML injection and nobody will get the ruxit agent module ...
Then with mentioned two tricks, you can bypass this restriction for selected browser instancies.