The aim of this post is to explain how to help you monitoring Java applications deployed on SCP.
First of all, let’s go through the main monitoring built-in functionalities available and clearly visible and then we will go through the advanced functionalities which may be a bit hidden but are very important and valuable to use.
Step1 : Using the main monitoring built-in functionalities available and clearly visible
- Monitoring physical resources such CPU, Memory, Disk I/O:
In order to monitor such metrics, that’s the probably easiest to get.
They are available within the cockpit whenever a Java application is deployed:
First of all, go to the Java applications:
Click on your Java application that you need to monitor. Then the following navigation menu displays as per below:
Then, this is where the interesting part starts 🙂
Clicking on the Application Monitoring will display the following graphs:
- Average Response Time (ms)
- Busy Threads
- CPU Load (%)
- Disk I/O (B/s)
- Free EBS Space (%)
- Heap Memory Usage (%)
- OS Memory Usage (%)
- Requests per Minute (requests)
- Used Disc Space (%)
Each graph can be zoomed-in in order to check for a specific timeframe or sometimes, it is useful whenver it is required to adjust the scale such for example once a very high response time appeared and it is not then possible to see the details later on.
Step 2 : Using advanced monitoring built-in functionalities available and not visible cleary
There is a huge of valuable monitoring information avaiable from the JMX console.
The JMX console is accessible in the navigation as below:
Then, a folder hierarchy like structure will appear.
Now, let’s go the most important metrics from the JMX console (… or at least the ones I could find the most useful for me once monitoring) .
- Monitoring the JDBC connection pool:
Once monitoring a live system or also a system where we put some load for example for performance and stress tests, it is always a good idea to monitor it and make sure we do not run into a performance bottleneck in this area.
In order to monitor it, you need to browser into the following level:
com.sap.cloud.jmx -> Persistence -ConnectionPools:
Once monitoring a system, these information above are very precious.
Below, the most critical metrics in my view:
- MaxConnections is the maximum number of connection the pool will open.
- BorrowedConnectionsCount is the number of connections “borrowed” to the application.
- PooledConnectionsCount is the number of connections available in the pool.
There are others metrics which can also show how much time threads have been waiting to get a connection and which could also be a good indicator to help you sizing properly the number of maxium connections to set in the pool.
- Triggering thread dumps:
As for all Java applications, it is sometimes required to be able to trigger thread dumps to analyze locking situation issues/hanging situations. Therefore, it is also possible
The previous KBA/Note will also explain you how to download the thread dumps then and analyze them.
In order to analyze them, I will then recommend you to use the SAP Thread Dump Viewer tha you can also find below:
- Analyzing Garbage Collections:
It is possible to analyze the Garbage Collections. To do so, you can review them from the SCP cockpit from the Logging and then in the section ‘Garbage Collection Logs’:
You can the either visualize it online from the cockpit or download the file itself and open it with your prefered GC viewer log.
- Setting JVM arguments (neo command line)
Below, is the reference guide how to configure VM arguments:
You can for example fine tune the JVM parameters if you wish to increase the heap memory/resize the new area, etc…
Another useful guide is the one to deploy using the neo command line:
I will keep enriching this blog… therefore stay tuned…