How to test RUM without disturbing application users.

[Adam-Piotrowicz]

Problem

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 purposes.

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

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 Dynatrace can get it. Let's configure Dynatrace to enable RUM only for this IP and then overcome this restriction in two possible Scenarios:

1. modifying the User-Agent header in the browser
   or
2. sending a custom HTTP header with a fake client IP

Requirements

• Scenario #1: the monitored website is not sensitive to modified User-Agent header (scenario #1), but this requirement is avoidable - see the note. 

• Scenario #2: the network must not remove custom HTTP headers,

• Scenario #2: we must install ModHeader browser extension,

 

Configuration and Usage

 

Scenario #1 - Modifying the User-Agent header in the browser

If using the Browser Extension for RUM and/or using custom HTTP headers is/are not possible, there is another way:

1. Go to problematic RUM Application -> edit Settings -> Capturing -> Exclusions -> IP address exclusions ,

2. Add the fake client IP and flip the These are the only IP addresses that should be monitored flag ON:

   

3. 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 .

Note

This may not work if the web application is sensitive to non-standard User-Agents. In these cases, 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.

Alternatively you can use below Scenario #2.

 

Scenario #2 - Sending a custom HTTP header with a fake client IP

 

Configure client web browser

1. Install ModHeader browser extension in your selected browser,

2. 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.

3. Make sure the next request contains the header in HTTP:

   

Configure Dynatrace

1. Go to Settings -> Web and mobile monitoring -> IP determination

   

   Note: Ensure the created entry is at the top of the list.

2. Go to the problematic RUM Application -> edit Settings -> Capturing -> Exclusions -> IP address exclusions ,

3. Add the fake IP configured previously and flip the These are the only IP addresses that should be monitored flag ON:

   

[AntonioSousa]

@Adam-Piotrowicz,

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 😉

[Adam-Piotrowicz]

@asousa, thanks for sharing - nice presentation!

[prasad_arugonda]

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

[Adam-Piotrowicz]

@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.