|
 |
| e-docs > WebLogic Server > Creating and Configuring WebLogic Server Domains > Monitoring a WebLogic Server Domain |
|
Creating and Configuring WebLogic Server Domains
|
Monitoring a WebLogic Server Domain
The following sections explain how to monitor your WebLogic Server domain:
The tool for monitoring the health and performance of your WebLogic Server domain is the Administration Console. The Administration Console allows you to view status and statistics for WebLogic Server resources such as servers, HTTP, the JTA subsystem, JNDI, security, CORBA connection pools, EJB, JDBC, and JMS.
Monitoring information is presented in the right pane of the Administration Console. You access a page by selecting a container or subsystem, or a particular entity under a container, on the hierarchical domain tree, in the left pane.
The Administration Console provides three types of page that contain monitoring information:
The Administration Console obtains information about domain resources from the Administration Server. The Administration Server, in turn, is populated with Management Beans (MBeans), based on Sun's Java Management Extension (JMX) standard, which provides the scheme for management access to domain resources.
The Administration Server contains both configuration MBeans, which control the domain's configuration, and run-time MBeans. Run-time MBeans provide a snapshot of information about domain resources, such as JVM memory usage or the status of WebLogic Servers. When a particular resource in the domain (such as a Web application) is instantiated, an MBean instance is created which collects information about that particular resource.
When you access a monitoring page for particular resources in the Administration Console, the Administration Server performs a GET operation to retrieve the current attribute values.
The following sections describe some of the monitoring pages that are useful for managing a WebLogic Server domain. These pages have been selected simply to illustrate the facilities provided by the Administration Console.
The servers table and the monitoring tab pages for individual servers enable you to monitor WebLogic Servers. The servers table provides a summary of the status of all servers in your domain. If only a small subset of the log messages from the server are forwarded to the domain log, accessing the local server log may be useful for troubleshooting or researching events.
For more information about the log files and the logging subsystem, see Using Log Messages to Manage WebLogic Servers.
You can access monitoring data for each WebLogic Server from the monitoring tabs for that server. The Logging tab provides access to the local log for the server (that is, the log on the machine where the server is running).
The Monitoring
The Monitoring
The Java heap is a repository for Java objects (live and dead). Normally you do not need to perform garbage collection manually because the JVM does this automatically. When the JVM begins to run out of memory, it halts all execution and uses a garbage collection algorithm to free up space no longer used by Java applications.
On the other hand, developers debugging applications may have occasion to force garbage collection manually. Manual garbage collection may be useful, for example, if they are testing for memory leaks that rapidly consume JVM memory.
The Monitoring
The Monitoring
The Monitoring
WebLogic Server 7.0 provides a new self-health monitoring feature to improve the reliability and availability of servers in a domain. Selected subsystems within each WebLogic Server monitor their health status based on criteria specific to the subsystem. (For example, the JMS subsystem monitors the condition of the JMS thread pool while the core server subsystem monitors default and user-defined execute queue statistics.) If an individual subsystem determines that it can no longer operate in a consistent and reliable manner, it registers its health state as "failed" with the host server.
Each WebLogic Server, in turn, checks the health state of all its registered subsystems to determine the overall viability of the server. If the server finds one or more critical subsystems have reached the "failed" state, the server marks its own health state as "failed" to indicate that the it cannot reliably host an application.
When used in combination with the Node Manager application, server self-health monitoring enables you to automatically reboot servers that have failed. This improves the overall reliability of a domain, and requires no direct intervention from an Administrator. See Managing Server Availability with Node Manager for more information.
In WebLogic Server version 7.0, the health state of a server and its registered subsystems is not visible via the Administration Console. However, you can check the health state of a server programmatically by calling the getHealthState() method on the ServerRuntimeMBean. Similarly, you can obtain the health state of a registered WebLogic Server subsystem by calling the getHealthState() method on its MBean. In WebLogic Server version 7.0, the following MBeans automatically register their health states with the host server:
See the Javadocs for WebLogic Classes for more information on individual MBeans.
You can also configure the frequency and timing of automated self-health checks by setting attributes of the ServerMBean. See Managing Server Availability with Node Manager for information on setting these attributes using the Administration Console.
Monitoring JDBC Connection Pools
Java Database Connectivity (JDBC) subsystem resources can also be monitored via the Administration Console. The Monitoring tab for a JDBC connection pool allows you to access a table listing statistics for the instances of that pool. As with other entity tables in the Administration Console, you can customize the table to select which attributes you want to be displayed.
A number of these attributes provide important information for managing client database access.
The Waiters High field indicates the highest number of clients waiting for a connection at one time. The Waiters field tells you how many clients are currently waiting for a connection. The Connections High field indicates the highest number of connections that have occurred at one time. The Wait Seconds High field tells you the longest duration a client has had to wait for a database connection. These attributes allow you to gauge the effectiveness of the current configuration is in responding to client requests.
If the Connections High field value is close to the value of the Maximum Capacity field (set on the Configuration Connections tab), you might consider increasing the value of Maximum Capacity (the maximum number of concurrent connections). If the value in the Waiters High field indicates that clients are subject to a long wait for database access, then you might want to increase the size of the pool.
The value in the Shrink Period field is the length of time the JDBC subsystem waits before shrinking the pool from the maximum. When the subsystem shrinks the pool, database connections are destroyed. Creating a database connection consumes resources and time. If your system has intermittent bursts of client requests, a short shrink period might mean that database connections are being recreated continually, which may degrade performance.
|
|
|
|
||
 |
|
|
 |
 |
 |
|
||
