From an infrastructure monitoring perspective, ensuring that Oracle WebLogic Server and all its underlying components are functioning should be your primary concern. In this section, we describe the monitoring of some core areas that have the largest influence on Oracle SOA Suite, namely managed servers, JVM, JMS destinations, and data sources.
As long as your managed servers are reported as healthy, there is usually not much to worry about. A warning state does not necessarily indicate that the managed server is unresponsive, but the cause of the warning should be investigated nonetheless. One of the key issues to managed server monitoring is ensuring the appropriate monitoring of threads.
To view the state of the managed servers, perform the following steps:
- Log in to the Oracle WebLogic Server Administration Console.
- On the home page, click on Servers.
- A list of all your managed servers will appear, as shown in the following screenshot:
Figure 6.21: Viewing managed server state and health
Ensure that the managed servers are running and are in a healthy state as designated by the green checkbox with OK. In Chapter 9, Troubleshooting the Oracle SOA Suite 12c Infrastructure, we have discussed the approaches to troubleshooting warnings or failed managed server states.
Although there are too many areas surrounding JVM monitoring to describe here, three of the more important ones include ensuring that the heap allocated on the JVM is appropriately sized (that is, comparing heap versus non-heap usage), that there is not excessive garbage collection, and that JVM thread performance is acceptable. Perform the following steps for the garbage collection information:
- Log in to the Oracle WebLogic Server Administration Console.
- On the home page, click on Servers.
- Click on one of the server names.
- Navigate to the Monitoring | Performance tab.
- Here, the total heap size and the percentage of the free heap are displayed.
- Click on the Garbage Collect button. Observe how much Heap Free Current is freed before and after the garbage collection.
Oracle WebLogic Server 12c also provides a dashboard that provides real-time monitoring of many metrics, including the JVM runtime heap. This is helpful for reviewing the server while there is a heavy load on the system as it allows you to view the current and free heap size.
Go to http://adminhost:7001/console/dashboard. Select JVM Runtime Heap and click on the start 
button. Heap Size Current and Heap Free Current are graphically displayed, as shown in Figure 6.22.
If the free heap hovers around zero for a considerable time, this is an indication that the heap size may be configured too small. If repeated and frequent garbage collections occur without much memory being freed up, additional JVM monitoring may be required at that point.
Figure 6.22: The Oracle WebLogic Server Monitoring Dashboard
From the Oracle WebLogic Server Monitoring Dashboard, the Thread Pool Runtime can also be monitored in real time. The key is to monitor the Hogging Thread Count and the Pending User Request Count. In a low-usage environment, these should hover around zero. From the Oracle WebLogic Administration Console, navigate to Servers | [wls_soa1] | Monitoring | Threads to view similar information. Various thread pool metrics are displayed there. Everything from Active Execute Threads to Hogging Thread Count is shown on this page.
The Throughput shown on this page is a single value that denotes the mean number of requests completed per second. The higher this value, the better. But the thread pool changes its size automatically to maximize the throughput, so in normal cases, there is nothing you need to do aside from monitoring it to understand the behavior of your server under different types of load.
More often than not, many of the integrations that run on top of Oracle SOA Suite 12c may leverage JMS destinations to support asynchronous integrations. These destinations can be JMS queues (for point-to-point integrations) or JMS topics (for publish-subscribe integrations). Oracle WebLogic Server 12c provides a way to easily create these JMS destinations that become accessible via a JNDI lookup in the code.
As an administrator, you must be aware of all queues and topics created, as there are many reasons why you would want to monitor them:
- Ensure that messages in the queues and topics are being produced and consumed without error and/or delay.
- Ensure that poison messages (messages that can never successfully be processed) are not persisted in the queue or topic.
To monitor your JMS destinations, perform the following steps:
- Log in to the Oracle WebLogic Administration Console.
- Click on JMS Modules.
- Click on the JMS module name that is hosting your queue/topic.
- Click on the queue or topic name.
- Click on the Monitoring tab. Here, you will see a summary of statistics regarding your JMS destination such as current, pending, and total messages.
- If the JMS destination already has subscribers, click on the checkbox beside your destination name and then click on the Show Messages button. From here, you can export some or all of the messages to an XML file should you choose to (for either backup purposes or with the intention of importing them into a different environment).
- Click on the JMS message ID. The following screenshot displays the result of this. Details of the message are displayed as part of the JMS header, including the ECID, composite instance ID, and the payload of the message:
Figure 6.23: Viewing the details of a JMS message
For data source monitoring, usually all that is needed is the connection pool configuration to be valid (that is, there are no connectivity issues to the database) and the number of active connections does not approach or exceed the maximum configured connections. There are cases, such as where the time it takes to establish a connection is long (refer to the Connection Delay Time column), but these are not common and usually appear in inadequately sized environments.
To check the JDBC Data Source Runtime Statistics, go through the following steps:
- Log in to the Oracle WebLogic Administration Console.
- Click on Data Sources.
- Click on the Monitoring tab. Here, the state of the data sources (for example, running), as well as the average, current, and high active connection counts are displayed.
- Click on Customize this table. From the Column Display Available table, select Current Capacity, Leaked Connection Count, Number Available, and Active Connections Current Count and move them under Chosen Column.
- Click on Apply.
- The Monitoring tab of the data source will look as shown in the following screenshot. The key is to ensure that the sum of Active Connections Current Count and Leaked Connection Count does not exceed the connection pool's Current Capacity. If they do, then it is either time to fix the leaked connections or increase the pool's capacity.
- To get the maximum capacity to determine how to appropriately size your connection pool, perform the following steps:
- Click on the data source name (for example,
mds-soa). - Navigate to Configuration | Connection Pool.
- Note the setting of the Maximum Capacity parameter.
Figure 6.24: Monitoring data sources
- Click on the data source name (for example,
In cases where the database may not be accessible or is down, the database password used for the connection pool has had its password reset, network-related issues occur, or data source-related errors begin appearing in the logs, it may be worth testing to ensure that the data source is working properly by performing the following steps:
- Log in to the Oracle WebLogic Administration Console.
- Click on Data Sources.
- Click on the data source name (for example,
mds-soa). - Navigate to Monitoring | Testing.
- Select the radio button and click on the Test Data Source button.
- If the connection is working (that is, the data source is able to access the database at the host, port, database name, username, and password), the following message will appear at the top of the page:
Test of [mds-soa] on server [wls_soa1] was successful.