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.
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 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.Fig. 1: WebLogic architecture
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.
There are a few reasons why monitoring WebLogic is crucial to the success of your business:
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.
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.
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.
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%.
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.
To get a clear idea of how well a WebLogic server is performing, here are a few key metrics to focus on:
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.
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:
OutOfMemoryErrorexceptions? For example:
java.lang.OutOfMemoryError <<no stack trace available>> Exception in thread "main"
OutOfMemoryErrorexceptions in your logs, consider setting a higher value for max heap size.
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
JDBCDataSourceRuntimeMBean MBean has the following attributes to monitor JDBC performance:
Monitoring the performance and utilization of connection pools is important. Ask the following questions
SELECT name, value FROM v$parameter WHERE name = 'processes';
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:
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.
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:
JMS allows different applications to communicate with each other. WebLogic JMS supports two means of communication:
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.
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.
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.
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.
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:
This configuration file enables the harvester module, sets the sample period to 1,000 milliseconds, and configures it to read the
ConnectionDelayTime attributes of the
JDBCDataSourceRuntimeMBean MBean. It also configures it to harvest from a custom MBean (
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.Fig. 2: WLDF monitoring dashboard
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.Fig. 3: The metric browser
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:
Follow these steps to set up 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:
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:
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:
You can also directly monitor web applications and servlets. Follow these steps to do so:
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.
Write for Site24x7 is a special writing program that supports writers who create content for Site24x7 “Learn” portal. Get paid for your writing.Apply Now