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

Mixed results trying to use custom injection rules - better documentation?

larry_roberts
Champion

On our PRD tenant we keep the Default Web Application disabled, but now and then we turn it on either when we are doing onboarding or to see what traffic we might be catching and want to define. With that said, we have some systems that are old and just do react well to RUM - as in they break.

I have been playing around with the custom injection rules attempting to exclude specific known traffic but it seems to be hit and miss. I am also not really finding much in terms of documentation on what you can and can not do with these rules.

For example, I would think that the below would not inject on any URL containing the example pattern.

Is that correct?


Also I would like to not inject on specific domains. The problem is we have clusters so you could have something like this...

I tried a few things, but it seemed to be hit and miss. For example - URL contains: somedomain*

I can not find any documentation on if wildcards can be used or not for these rules.

Can wildcards be used?

Is there a better method of not injecting via the Default Web Application on a straightforward method without the need for 50 "Do not inject" rules?

Thanks!

3 REPLIES 3

dave_mauney
Dynatrace Champion
Dynatrace Champion

It might be counter intuitive, but have you considered setting up rules for the problematic apps, routing them to a single RUM application and turning off RUM for it?

That way, only unknown domains and IPs would be routed into the default application and you could then route it out as found when you turn it on periodically.

I know this doesn't help with your original question but I wanted to be sure your known problem apps are taken care of so you don't break them when you need to turn on the default app.

Another strategy is to NEVER turn on the default app, but do the mapping blindly... Only map domains and URL patterns known in advance.

I had done that before, but it drove me crazy having that configuration is there for an application just to have it disabled. I know, I am strange like that 🙂

I agree that never turning on the default app would be another way, but that seems counterproductive for what the default app can be used for.

Sounds like I need to create an RFE on it to enhance the current options in define custom injection rules to become much more useful. For example the ability to use a wildcard. It even makes me wonder if that would be a great place for such options.

For example, if you need to exclude specific domains as in my example of...

A screen with configurable global rules around RUM which provides basic abilities like wildcards.

Thanks for the response with ideas - Much appreciated!

dave_mauney
Dynatrace Champion
Dynatrace Champion

One more comment: if you turn the XHR stuff off for the default app it will greatly reduce the odds of causing a negative impact on an app and it should still give you enough info to route the traffic accordingly.