In a recent article, I shared my first steps (small step for mankind, big steps for me) with Oracle Management Cloud: First steps with Oracle Management Cloud – Application Performance Management for Node (JS) applications. In that article, I have explained in broad terms the purpose of Application Performance Monitoring in the scope of OMC:
Application Performance Monitoring (APM) is clearly indispensable to any organization adopting a DevOps approach – and frankly required for any organization in general running applications to support business objectives. APM provides insight in the non-functional behavior of applications – or better yet: of the business functions provided by these applications. It alerts administrators to functions that have unacceptable response times or are at risk to display poor performance and it allows us to analyze these situations to figure out where in the application stack – front end, services, integration flows, database, etc. – and in which specific component the problems have arisen. After performing this type of root cause analysis, resolving the problem still needs to be done, but is kick started as early as possible and with as much analysis details as possible.
In that earlier article, I also demonstrated how monitoring can be set up for Node (JS) applications. In this article, I will work with the APM Java agent. This agent can be installed and configured for a range of Java EE application servers – including Oracle WebLogic Server, Apache Tomcat Server, JBoss/WildFly, IBM WebSphere Server. It will observe the activity in the JVM and derive meaningful metrics from its observations. These metrics are forwarded to the OMC cloud where they are stored, processed, visualized and analyzed.
In this article I will apply the APM Java Agent to an existing Oracle WebLogic plus SOA Suite environment. After installing and configuring the agent, I have to make one small change to the WebLogic startup script, (re)start the server and subsequently and activity on that server is reported to OMC and exposed in the APM Dashboard and analysis screens. Subsequently my colleague executed the same steps on his personal laptop, using an agent with the same registration key and applying this agent to a WebLogic Server running an ADF application against a local database. Within minutes, the metrics from his machine and his ADF application appeared in the APM section of OMC, ready to be analyzed. (this particular ADF application is intentionally equipped with a number of performance black holes, for training and demonstration purposes; OMC APM was capable of identifying most of them.
Our set up:
The steps for getting this set up and running smoothly are really quite simple. The first insights are easily gained.
Note: some of the preparatory steps are described in the previous article. These include downloading the agent installer and extracting the installer to a staging directory, getting hold of the registration key.
We will start the deployment and configuration of the APM Java Agent – assuming the installer has been extracted to a directory /u01/temp/apm. Also see the documentation: http://docs.oracle.com/en/cloud/paas/management-cloud/emcad/downloading-master-installer2.html.
The command to actually install the Java agent is as follows:
/u01/temp/apm/AgentInstall.sh AGENT_TYPE=apm_java_as_agent STAGE_LOCATION=/u01/temp/apm AGENT_REGISTRATION_KEY= RMxMm7chywi-J-VZ7
after successfully running this command, a number of files I generated in to the STAGE_LOCATION. Note that emcs.cer file was generated specifically for our OMC instance.
At this point, there has not been any Java Agent applied to a specific WebLogic instance (or any other Java application server). That is what comes next.
Set the values of REG_KEY, STAGE_DIR and DOMAIN_HOME (the domain home for the WebLogic Domain that we want to apply the APM Java Agent to) as shown below.
Note that I first did not pay attention to the Oracle Wallet and after being alerted about not having Oracle Wallet enabled, I re-ran the script with the no-wallet option. The directory apmagent is created under the DOMAIN_HOME directory. It contains configuration, library and log files.
After running this command, the following instructions appear, about configuring the APM Agent in the WebLogic startup script (corresponding to the documentation http://docs.oracle.com/en/cloud/paas/management-cloud/emcad/modifying-startup-script-your-weblogic-server.html) :
Open {DOMAIN_HOME}/bin/startWebLogic.sh (after making a back up copy of that file) and add the specified line:
JAVA_OPTIONS="${JAVA_OPTIONS} -javaagent:${DOMAIN_HOME}/apmagent/lib/system/ApmAgentInstrumentation.jar"
Save the file and restart the WebLogic admin server and all relevant managed servers. From this moment on, the agent is active:
and will send metrics on the activity in the JVM to the OMC cloud instance.
The managed server also logs the initialization of the APM Java Agent:
Over to the Cloud
After starting the WebLogic domain with its managed servers, the agents have started and have reported to the OMC instance. If we take a look in the cloud console at the list of agents, then we will find the two agents attached to the WebLogic Admin Server (port 7001) and the Managed Server (with SOA Suite) on port 8001:
Note that this WebLogic domain is running inside a Virtual Machine on my laptop; from there it reports to OMC.
Each agent is associated with an application server – either Node.js or WebLogic:
The first metrics have been received and are shown in the dashboard.
One of the test calls I have performed is a Web Service call to a SOAP Web Service exposed by a SOA composite running on SOA Suite. The SOA Composite looks as follows:
The test call from the Web Service tester UI in
This overview makes clear what actions were performed in the server in order to process the web service call after the user pressed the button in the browser UI. Various database interactions take place from WebLogic. Finally, the call is made to SOA Suite, visualized by the orange circle. From the context menu, we can drill down, following this call down its path:
(the text balloons are added by me). Note how the structure of the SOA Composite instance flow trace is clearly depicted in this visualization. For each step in the execution of the web service, we can see what had to be done and how long that took – on average or at its longest. We can also use the size and weight of the diagram elements to indicate the number of executions and the number or percentage of errors.
We can hover over or click on any node to see more details. For example for a SQL node – indicating database interaction which could be PL/SQL as well – we can see the SQL statement that was executed over JDBC:
Note how much insight we get on the processing inside SOA Suite, the steps within SOA Composite, without doing anything more than configuring the agent. No changes were required in the SOA Suite nor in the SOA Composites. We did nothing to get insight in the SQL calls that are performed – but we have that insight anyway. And we can tell whether these calls fail, how long they take, how many there are etc. APM does not understand SOA Suite by the way. Nothing special is currently done in APM to make interpretation of SOA composite activity any easier than analysis of activities on applications running on Tomcat or Web Sphere. Even without preferential treatment, we can get a lot of value. So surely we can with other types of applications as well.
I will shortly take a look on an ADF application that was running on a WebLogic domain that was configured with the APM Agent; stay tuned for a subsequent article.
