Guide to WebLogic Server Monitoring

Application monitoring is crucial for ensuring that your applications are available and performing as expected. It enables you to gauge overall system health, identify network bottlenecks, detect anomalous behavior, debug errors, and alert development teams in case of critical failures.

WebLogic is a modern application server for building and running Java applications. It offers native support for Kubernetes, allowing you to deploy your applications within a Kubernetes cluster seamlessly. Cluster management tools and APIs give you full control over the cluster and enable you to automate operational workflows. Application nodes are automatically scaled and restarted to achieve high availability.

In this article, we will guide you on how to monitor WebLogic Server performance. We’ll describe its architecture, list the top performance metrics, and discuss how to monitor via different tools.

What is WebLogic?

WebLogic is a comprehensive platform for building, managing, deploying, and scaling Java applications. It allows you to harness the full potential of Java EE and Jakarta EE to build robust and resilient applications. It’s environment-agnostic: you can run it in-house or on any cloud platform.

You can use WebLogic to build dynamic or static web applications. It has built-in support for Java Messaging Service (JMS), XML processing, Remote Method Invocation (RMI), and Enterprise JavaBeans (EJB). The WebLogic Security Service allows you to secure your applications using features like SAML authentication, OAuth 2.0 authentication, SSL authentication, and network connection filters.

WebLogic architecture

WebLogic exists in the middle of a multi-tier architecture, between the front-end/client tier and the back-end tier. In such an architecture, the client tier manages the presentation layer, the back-end tier manages the data, and the middle tier executes business logic to deliver data from the back end to the client.

You can use WebLogic to connect your client-tier applications with different systems, such as databases, identity, and access management (IAM) services, enterprise applications, mainframe applications, transaction monitors, and business intelligence platforms.

WebLogic protects your back-end systems from being directly accessed by client applications, significantly decreasing your attack surface. Abstracting the back-end end points ensures that client applications are not affected by changes in the back end. Moreover, using techniques like resource pooling and caching in the middle tier leads to greater scalability.

The WebLogic Server cluster feature allows you to distribute client requests across a group of servers. An intelligent load-balancing algorithm is used to relay a client request to a server capable of serving it. If a request fails or times out, a secondary server is assigned to retry. You can add or remove WebLogic servers from a cluster as your needs change.

To understand how a WebLogic server processes a request, consider an example. A browser sends a request for a web page to the WebLogic server, which in turn relays the request to a servlet running inside it. The servlet uses built-in Java database connectivity (JDBC) to retrieve some data from a database, uses JMS to fetch additional information from a helper service, and finally, creates an HTML response using the retrieved data and sends it back to the client.

Why is it important to monitor WebLogic Server?

There are a few reasons why monitoring WebLogic is crucial to the success of your business:

Ensure high availability

As the WebLogic server lies at the center of distributed, multi-tier architectures, monitoring its performance lets you ensure high availability. Monitoring tools provide all the metrics necessary to determine if WebLogic is timely and accurately responding to incoming requests.

Detect memory leaks

Memory leaks cause heap memory overutilization and exhaustion, which can hamper system performance over time. Monitoring tools track garbage collection, heap memory usage, memory pool size, and other metrics, which lets you find and resolve memory leaks.

Achieve peak performance

Monitoring tools offer metrics that you can use to benchmark your application. For example, metrics like memory usage, number of idle/busy threads, number of active connections, and number of timeouts give you an idea of how your application performs in different scenarios. Using these metrics, you can determine whether you need to scale up/down and tweak your configurations accordingly.

Predict malfunctions

Continuous monitoring of a WebLogic instance allows you to detect anomalous behavior and predict malfunctions. For example, a monitoring tool may alert you that your disk usage has exceeded 80%, giving you enough time to remove unnecessary files before reaching 100%.

Quickly resolve issues

Performance monitoring enables you to contextualize issues. By looking at various interrelated metrics, you can determine the potential causes of an issue. For example, if your server is generating too many error responses, and the CPU utilization of your database is 100%, there’s likely something wrong in the database layer.

Top performance metrics for WebLogic

To get a clear idea of how well a WebLogic server is performing, here are a few key metrics to focus on:

JVM resource utilization

Java Virtual Machine (JVM) provides the execution environment for WebLogic and Java applications. Tracking JVM health is arguably the most important part of WebLogic performance monitoring. Bottlenecks or issues in JVM can lead to severe performance degradation.

The JVMRuntimeMBean MBean exposes attributes that let you track JVM metrics. For example, the HeapFreeCurrent attribute indicates the currently available heap memory in bytes, the HeapSizeCurrent attribute shows the overall size of the heap, and the Uptime attribute tracks the elapsed time since JVM was started, in milliseconds.

WebLogic offers several tuning factors to optimize JVM performance, including a garbage collection scheme, UNIX threading models, and heap size tuning. While monitoring JVM resource utilization, it’s important to ask the following questions:

• What is the average thread processing time? Is there a thread consuming an excessive amount of CPU resources? If yes, you can view the contents of its stack to debug.
• What is the maximum heap size setting? Is the heap memory growing too fast? If yes, which component has the memory leak?
• What is the frequency of garbage collection, and is it impacting overall performance? You can enable the verbose garbage collection option (verbosegc) to track the time and resources used by garbage collection.
• Do the logs show any OutOfMemoryError exceptions? For example:
  java.lang.OutOfMemoryError <<no stack trace available>> Exception in thread "main"
  These exceptions typically indicate that JVM has run out of heap memory, which may cause the application to crash soon, if it hasn’t already. If you see too many OutOfMemoryError exceptions in your logs, consider setting a higher value for max heap size.

JDBC performance

Most Java applications rely on a database to persist data. However, database operations, such as connecting, reading, and writing, are resource-intensive. To address this problem, you can use connection pools to mitigate the performance overhead of creating and closing database connections.

A connection pool is a group of database connections that are initialized when the server starts. Whenever an application wants to connect to a database, it requests a connection from the pool. Once the application finishes its database work, it returns the connection back to the pool, making it available for reuse.

You can use the CREATE_POOL command on the administration server to create a connection pool. The TEST_POOL command can be used to test a pool by simulating the request and release of a connection. It’s also possible to create a dynamic connection pool using the JDBCConnectionPool MBean.

The JDBCDataSourceRuntimeMBean MBean has the following attributes to monitor JDBC performance:

• ActiveConnectionsAverageCount: The average number of active connections
• ActiveConnectionsHighCount: The highest number of active connections detected since server start-up
• ConnectionDelayTime: Average time taken to establish a connection with the database server
• FailuresToReconnectCount: Number of times a reconnection attempt failed
• LeakedConnectionCount: Number of leaked connections
• WaitSecondsHighCount: The longest an application had to wait to get a connection

Monitoring the performance and utilization of connection pools is important. Ask the following questions

• How many connections are in use? Are you close to running out of connections?
• Has a thread been holding onto a connection for a very long time?
• How long does it take to get a connection from the pool?
• Are there any warnings in the logs that indicate connection leakage?
• What is the maximum allowed number of processes that a database can spawn? This is important because most operating systems create a new process for every connection. For Oracle, you can use the following command to check this setting:

  SELECT name, value FROM v$parameter WHERE name = 'processes';

• What is the memory and CPU utilization of your database server?

Execute queues

Whenever a WebLogic server receives a request, it places it inside an execute queue. The queue has a pool of threads responsible for processing incoming requests. WebLogic comes with three built-in queues:

• weblogic.kernel.default: The default queue, which has 15 threads. If there are no user-defined queues, all applications use this queue.
• weblogic.admin.HTTP: This queue is used only for communication with the administration console.
• weblogic.admin.RMI: This queue is reserved for administrative traffic.

Users can create additional queues and assign them to specific applications. Tracking the performance of execute queues lets you gauge the overall processing ability of WebLogic. For example, the ExecuteThreadCurrentIdleCount attribute from the weblogic.management.configuration.ExecuteQueueRuntimeMBean MBean tells you the number of idle threads available to a given queue. The PendingRequestOldestTime attribute from the same MBean indicates when the longest waiting request was put into the queue.

Response time and throughput

Average response time and throughput are primary indicators of a server’s performance. If the average response time is too high, data may take too long to load on the client side. If the throughput is too low, you probably need to allocate more resources, and/or increase your thread counts.

Several attributes in the WseeBaseOperationRuntimeMBean MBean let you track key request processing metrics:

• ResponseTimeAverage: Average response time
• LastResponseTime: Time stamp of the last generated response
• ResponseTimeHigh: Highest response time
• ResponseTimeLow: Lowest response time
• InvocationCount: Total number of times an operation was invoked
• ExecutionTimeTotal: Cumulative execution time for all operations
• ExecutionTimeAverage: Average execution time
• ExecutionTimeHigh: Highest execution time
• ExecutionTimeLow: Lowest execution time
• ErrorCount: Total number of encountered errors
• LastError: The most recently encountered error

JMS performance

JMS allows different applications to communicate with each other. WebLogic JMS supports two means of communication:

• Point-to-point: Application A sends a message to Application B. The message is pushed into a queue. It remains in the queue until it’s processed by Application B or expires.
• Pub/sub model: In the publish/subscribe model, messages from the publisher are broadcasted to all active subscribers.

WebLogic supports multiple MBeans to track JMS performance. For example, the JMSConnectionRuntimeMBean MBean can be used to monitor JMS connections. Its SessionsCurrentCount attribute returns the number of active sessions for a connection.

The JMSConsumerRuntimeMBean MBean is used to monitor JMS consumers. The BytesPendingCount attribute is a count of the bytes that the consumer is yet to acknowledge, whereas the MessagesPendingCount attribute returns the number of pending messages.

Similarly, the JMSProducerRuntimeMBean MBean offers attributes to track producers. The BytesSentCount attribute is a cumulative count of the bytes this producer has sent, whereas the MessagesSentCount attribute indicates the number of messages it has sent.

Tracking JMS metrics like pending messages, active sessions, and sent bytes enables you to detect any messaging-related issues. For example, if there are too many unacknowledged messages, it’s likely that there is a problem with the consumer.

To tune WebLogic JMS for high performance, a good start is to configure message count quotas, avoid large message backlogs, optimize the WebLogic Message Bridge, and use multi-threaded producers and consumers where possible.

Monitoring performance using the WebLogic Diagnostic Framework

The WebLogic Diagnostic Framework (WLDF) is a native monitoring solution for WebLogic and its applications. It includes several components that let you track runtime performance metrics and collect diagnostic data.

Built-in diagnostic modules enable you to monitor JVM, messaging, WebLogic’s internal components, Java EE containers, and databases. The graphical monitoring dashboard lets you analyze the historical performance of a server. The Diagnostic Image Capture feature allows you to generate a working snapshot of a server, which can be used for post-failure debugging.

WLDF also maintains an archive of data events, metrics, and logs. The WLDF harvester service allows you to collect attribute data from WebLogic server MBeans and custom MBeans. You can use JMX APIs to dynamically enable, configure, and use WLDF.

Monitoring JDBC with WLDF

WLDF offers built-in diagnostic modules to monitor JDBC statistics, including the number of used connections, leaked connections, and idle connections. You can use the WebLogic Scripting Tool (WLST) to enable and configure built-in diagnostic modules.

The WLDF harvester module aggregates performance metrics by reading attributes from specified MBeans. By configuring it to read attributes exposed by JDBC MBeans (e.g., JDBCDataSourceRuntimeMBean), you can access real-time JDBC performance data. Consider this sample WLDF configuration file:

<wldf-resource xmlns=”http://xmlns.oracle.com/weblogic/weblogic-diagnostics” 
        xmlns:xsi=”http://www.w3.org/2001/XMLSchema-instance”> 
<name>sampleWLDF</name> 
  <harvester>    <enabled>true</enabled< 
    <sample-period>1000</sample-period> 
    <harvested-type> 
      <name>weblogic.management.runtime.JDBCDataSourceRuntimeMBean</name> 
        <harvested-attribute>ActiveConnectionsHighCount</harvested-attribute> 
        <harvested-attribute>ConnectionDelayTime</harvested-attribute> 
    </harvested-type> 
    <harvested-type> 
      <name>customMBeans.Sample</name>
      <harvested-instance>sampleDomain:Name=sampleMBean1 
      </harvested-instance> 
      <harvested-instance>sampleDomain:Name=sampleMBean2 
      </harvested-instance> 
    </harvested-type> 
  </harvester> 
</wldf-resource>

This configuration file enables the harvester module, sets the sample period to 1,000 milliseconds, and configures it to read the ActiveConnectionsHighCount and ConnectionDelayTime attributes of the JDBCDataSourceRuntimeMBean MBean. It also configures it to harvest from a custom MBean (customMBeans.Sample).

Monitoring JMS with WLDF

WLDF also has a built-in diagnostic module for monitoring JMS subsystem statistics such as number of pending messages by a consumer, number of active connections to a server, and number of pending messages in a destination.

Monitoring server and application state using the graphical dashboard

The monitoring dashboard can be used to view performance and diagnostic metrics related to the WebLogic server and its applications. The dashboard aggregates metrics from the attributes of runtime MBeans and data collected by the harvester.

The dashboard interface has a few built-in “views” that display critical runtime metrics, such as JMS runtime statistics, JVM runtime heap statistics, and thread pool runtime statistics. You can also create custom views to track additional metrics.

You can use the metric browser to select the metrics you want to visualize via charts on the dashboard. See Figure 3 below. Choose the relevant server from the dropdown at the top, and then find the instance that has the desired metric. Using these metrics, you can monitor server status and application performance.

Monitoring WebLogic using the administration console

The WebLogic Server Administration Console is a browser-based portal for managing and monitoring WebLogic server domains. A server domain is a collection of related WebLogic servers that can be managed as a unit. The administration console allows you to perform several operations via a graphical user interface, including:

• Configuring, starting, and stopping WebLogic servers
• Configuring services like JDBC or JMS
• Securing your servers
• Monitoring the performance of the server, services, and applications

Follow these steps to set up the administration console:

• Start the WebLogic administration server.
• Once the server has started, access this URL: http://hostname:port/console (Replace hostname and port with the IP address and port of the administration server, respectively. The default port is 7001.)
• When the log-in page displays, enter the username and password you chose when you installed/started the administration server.

Monitoring JDBC using the administration console

The administration console displays several statistics through which you can monitor JDBC data sources, including: active connections current count, connection delay time, current capacity, leaked connection count, current state of the data source, and highest available number of idle connections.

Follow these steps to view real-time statistics of a data source:

• From the Domain Structure tree, select Services > Data Sources.
• Find and click the relevant data source.
• Choose the Monitoring: Statistics tab to view the statistics.

Monitoring JMS using the administration console

You can monitor many JMS performance indicators, including the number of currently active consumers, the current number of messages in the destination, and the total number of received messages. To view statistics for JMS destinations, follow these steps:

Monitoring server and application performance using the administration console

The administration console allows you to monitor server health and performance, request manual garbage collection, view thread stacks, and log low memory conditions. To monitor a specific server instance, follow these steps:

• Select Environment > Servers.
• Choose the relevant server from the list of servers.
• Select Monitoring

You can also directly monitor web applications and servlets. Follow these steps to do so:

• Select Deployments and choose the relevant application.
• Click Monitoring > Web Application to view metrics like active server count and session-related data.
• Alternatively, click Monitoring > Servlets to view data related to the application’s servlets.

Conclusion

Monitoring the performance of WebLogic lets you ensure high availability and performance of your Java applications. In this article, we talked about using WLDF and the administration console to monitor different aspects of WebLogic performance. To learn more, visit the official WLDF documentation by Oracle or refer to the administration console help page.