Dynatrace tips
Tips and workarounds from Dynatrace users for Dynatrace users.
cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

Pro Tip: Prevent RUM Collisions on Legacy Sub-Paths

Maheedhar_T
Mentor

Heya Community,

In large organizations, we often deal with complex web applications where different sub-paths (like /notebooks or /checkout) are managed by different teams using different tech stacks.

Imagine Team A manages the main site home.dynatrace.com on a modern stack, but Team B manages home.dynatrace.com/notebooks on an older version of WebLogic. Following a OneAgent update, you might find that the RUM (Real User Monitoring) JavaScript injection causes a functional conflict on that older sub-path.

If this happens in Production, you can't afford to lose functionality while waiting for a platform upgrade. You need to stop the injection immediately—but there is a common trap most people fall into.

The Common Mistake: Disabling the Sub-App

Most admins think: "I'll just disable monitoring for the 'Notebooks' application in Dynatrace or disable injection at the host level."

Why this fails: If a user starts their journey on the Home Page (which is still monitored), Dynatrace starts a user session. To maintain end-to-end visibility, the RUM agent "follows" the user. Even if you've "disabled" the sub-app, the injection rules from the parent domain often still apply because the session cookie and headers are already active.

The Solution: Custom Injection Rules

To truly "silence" Dynatrace on a specific part of your site, you must tell the main application specifically where not to go.

How to do it:

  1. Navigate to your Main Application (e.g., the Home Page app) in the Dynatrace UI.

  2. Go to Settings > Injection > Custom Injection Rules.

  3. Click Add Item.

  4. Set the rule to "URL contains" (e.g., /notebooks).

  5. Change the rule behavior to "Do not inject".

Why this matters

By doing this, you ensure that as soon as the user hits that specific path, the RUM agent stands down, preventing any JS conflicts with legacy code.

A Word of Caution

While this restores your application's functionality instantly, remember: this is a workaround, not a permanent fix.

Turning off monitoring and calling it "fixed" is like putting a piece of black tape over your car's "Check Engine" light. The light is gone, and you can see the road better, but the underlying issue remains.

Keep this in your back pocket for emergencies, but ensure the legacy teams have a plan to upgrade their stack to stay compatible with modern monitoring!

Happy Monitoring!
@Maheedhar_T 

Maheedhar
0 REPLIES 0

Featured Posts