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

This product reached the end of support date on March 31, 2021.

Apache Rewrite Rule - UEM 404

jerry_lobenstei
Dynatrace Advisor
Dynatrace Advisor

If the
UEM volume should expire or become unavailable due to a license change.
The agent injection continues and the Monitoring Beacon is still sending
data back to the Web Server. The 404 errors can cause issues for the
site and in some cases; causes issues with the Apache instance. I have
also seen the requests be sent onward by Apache to the Application tier which
can causes some additional problems and errors in the application.

This rule below was added to the: /etc/httpd/conf/rewrite_http-https.conf

RewriteCond %{REQUEST_URI} ^/dt/* [NC]

RewriteRule ^.*$ - [L,R=404]

We pushed the rule today and once we turned on UEM, they are realizing that every single request
matching this pattern is getting issued a 404. We need a rule that’s
going to issue a 404 ONLY when our Apache sub-module isn’t present.

Anyone have any thoughts?

4 REPLIES 4

henry_apletree
Inactive


Hi Jerry,


Rather than add a RewriteRule to explicitly 404 anything which is sent to /dt/* I'd recommend instead changing the actual rule which is forwarding the traffic to your application tier.



At the moment it sounds like there is a rule configured to forward everything on to the application server, which is forarding on dtagent requests when the agent module is not loaded in apache.


I'd recommend explicitly excluding anything to /dt/* from being passed to the application tier, that way when our agent module is present in apache it will be handled as normal, but when our agent is not present the requests will not be forwarded to the application tier and will 404 as normal.



E.g. if you're using proxy pass

ProxyPass /dt/*	!
ProxyPass /* Balancer://myApplicationTier

Best regards,

Henry

chase_hulderman
Inactive

Thank @Henry A.!

So as it turns out, we had a rewrite rule that was prepending a URI to all requests that didn't already match a predefined pattern. This was applying this URI value that then hit the vhosts file to push to the weblogic endpoint.

The simple solution was to write a rewrite rule that took precedence over the standard rule allowing the dynatrace request to hit the vhosts file as a standard request (eg. /dt/dtagent.js or /dt/dynaTraceMonitor) for which there was no explicit rule. By default Apache will issue a 404 response and not pass to the apptier. For an Apache instance that has the agent installed as a module, the agent will intercept the request and issue a 200.

RewriteCond %{REQUEST_URI} ^/dt/* [NC]
RewriteRule ^.*$ - [P,L]

I'd suggest we update documentation to verify that there is an explicit or implicit catch for Dynatrace traffic.

Even better would be employing a 'best practice' configuration. In this case, it seems what Henry has done is ideal.

Jeffrey_Fynboh
Dynatrace Organizer
Dynatrace Organizer

Take a look at the Apache <IfModule> directive https://httpd.apache.org/docs/2.4/mod/core.html#ifmodule.

I think something like the below would do the trick so the rewrite would only happen if the dtagent_module wasn't loaded:

<IfModule !dtagent_module>

### Rewrite rules in here to handle the 404

</IfModule>

andreas_grabner
Dynatrace Guru
Dynatrace Guru

Just an FYI. The team is currently working on changing the current behavior of responding with 404s. This will be changed to avoid the problem you are working around right now.