important: OC4J instrumentation with dynaTrace (not only application part)
Hi everyone,
I know that OC4J instrumentation was covered in one topic, however I think this is a more advanced question.
The instrumentation of the application part of OC4J at the customer is working fine. We see the application tier in the transaction flow and all of that. However, OC4J also has an embedded webserver part, which I think I would need to instrument as well and I struggle with. The background for that is that they want to have UEM data as well, but do not have a real webserver (e.g. like apache) in front of the OC4J.
We actually get UEM data (but this appears more to be a work around) when we activate it for the application agent group sensor configuration and put that javascript agent file MANUALLY somewhere and reference it in the UEM configuration within dynaTrace. However, this manual approach cannot be the official supported solution for this...
In addition I think this will affect the clients time connecting to your application (because the client has to fetch that js agent file which is not necessarily within the same tier/module). Maybe I am on a wrong track, but then generally I would like to know if there is any best practice or any official process to get UEM data correctly using OC4J ? Especially how does it work compared to the normal apache approach of loading the module in the httpd.conf and putting the WS-Agent on? At the moment there is only the "application" agent (dtagent.dll) installed (but we have UEM data using the mentioned work around?!)
Any help would be highly appreciated.
Best regards,
Dennis
Hi Andi,
Thanks for your response. That is what we did, activating the UEM sensor directly on the Application Server. I think the problem we might have here at the customer is that their application which we want to monitor is first of all a FAT client on windows. However, parts WITHIN that FAT client are actually webbased, meaning that they are served by an internal IE-based browser within that FAT client which is however not visible to the user. It all appears as one FAT client containing however IE based web pages (only for some parts). I guess it is this mix what gives us difficulties. I am not fully sure but when I understood correctly, they get UEM data for the FAT parts (using the approach you suggested) however, for the web parts they would need the actual JavaScript agent, which they injected by changing the location from the "User Experience" option from the system profile (putting it on some server and referencing it from there). This approach is of course not best practice as this might influence the clients response time (by fetching the JavaScript which is not necessarily close to the application).
I was thinking here to instrument some web server part which actually serves these web requests (to my understanding) independently from the "FAT-"requests... To my understanding that was the webserver part of OC4J, but I might be wrong here...
I understand it might be hard to understand from my explanation, but maybe anyone had by chance a similar environment at a customer and could help?
Anyway thanks so far for your support, Andi.
Best regards,
Dennis
Hi Dennis
For Java Application Servers you can enable UEM by simply activating the User Experience SEnsor Pack on your Java Agent Tier. In your case thats the Java AGent for your OC4J tier. Enabling that UEM Sensor Pack will take care of automatically injecting the JavaScript file as well as processing the captured UEM data. It should not be necessary to manually inject the JavaScript file
Andi
