UEM with Custom Apache Rules Defined
I ran into a situation a few weeks ago on a POC where I installed dT on an app that was developed several years ago, and its infrastructure was never really updated.
They wanted to see UEM, but were using Apache 1.x, which we do not support for UEM. The next logical approach was to enable UEM through the Java agent, which we did. This allowed the js file to be injected into each page, but the dT monitoring POSTs were not making it back to the dT server. After spending a lot of time troubleshooting this, with the help of support, we determined the cause had to do with the Apache configuration not allowing the monitoring POSTs to pass through Apache to the app server.
So...for anyone who may run into a situation where Apache is too old, or when Apache has a lot of custom configuration around which requests can pushed to the app server or not, the below snippet might help.
To work around this, I had to add a new rule in the web.xml file for the app to allow the UEM monitoring POSTs to pass through to the app server.
These are sample steps for what I had to do in this environment (OAS 10g), but may vary slightly, depending on the app server in place.
- Open D:\ora10gas\j2ee\home\dcss\WEB-INF\web.xml
- add servlet mapping entry to ensure dynaTrace js and monitoring requests make it to the java agent
<servlet-mapping>
<servlet-name>action</servlet-name>
<url-pattern>/dynatrace/</url-pattern>
</servlet-mapping>*
- change dynaTrace UEM settings to specify /dynatrace/ for uem agent and monitor agent paths
Kevin, this is a good solution.
Have you tried to set the agent and monitor signal to a path already know by the apache? For example the context root of the current web app? So then the signal should also end in the app server and you don't need to redeploy the application.
Alex
Alex-
Yes, we tried that during the PoC. I don't remember the exact reason now, but I believe it did not work because the server rules were very specific and prevented our posts from making it through.
Kevin
