Monitoring WebLogic Server 12c

Exclusive offer: get 50% off this eBook here
Oracle WebLogic Server 12c Advanced Administration Cookbook

Oracle WebLogic Server 12c Advanced Administration Cookbook — Save 50%

Over 60 advanced recipes to configure, troubleshoot, and tune Oracle WebLogic Server with this book and ebook

$29.99    $15.00
by Dalton Iwazaki | June 2013 | Cookbooks Enterprise Articles Oracle

In this article by Dalton Iwazaki, author of Oracle WebLogic Server 12c Advanced Administration Cookbook, we will cover the following recipes:

  • Customizing the Administration Console tables

  • Using the JRockit Mission Control Management Console

  • Monitoring Linux with SAR

  • Sending e-mail notifications with WLDF

  • Generating an SMNP trap

  • Creating a Monitoring Dashboard custom view

  • Viewing historical data in the monitoring dashboard using a database

(For more resources related to this topic, see here.)

Customizing the Administration Console tables

The Administration Console is the central tool for managing, configuring, and monitoring WebLogic.

This recipe shows how to customize the Administration Console tables to display more columns and more information and data that are hidden by default. This is a simple but essential feature to help monitor the WebLogic Server.

Getting ready

Access the Administration Console. The following procedure customizes the threads' monitoring table of the Managed Server Self-Tuning's thread pool.

How to do it...

Carry out the following steps to customize the Administration Console tables:

  1. Access the Administration Console with your web browser at http://adminhost.domain.local:7001/console.

  2. Click on the plus sign to open the Environment tree on the left and then click on the Servers link.

  3. Click on any server, such as the PROD_Server01 link. Click on the Monitoring tab and then on the Threads tab to open the Threads page.

  4. Click on the second Customize this table link of the Self-Tuning Thread Pool Threads table.

  5. Click on the >> button to add the columns Application, Module, and Work Manager. Change the Number of rows displayed per page value to 1000. Click on the Apply button.

How it works...

The Administration Console allows the user to customize and add more columns to the monitoring tables. In this recipe, the Application, Module, and Work Manager columns are added to the Self-Tuning Thread Pool Threads table.

The added columns are very useful to monitor the application requests being processed. The following table displays thread 0 processing a request of the testWeb application and thread 1 processing a request of the myApp application.

Customizing the Administration Console monitoring tables is a common task and can be applied in a variety of tables, such as the data sources, the JMS queues, and transactions.

Using the JRockit Mission Control Management Console

Mission Control is a monitoring and troubleshooting application provided with Oracle JRockit.

From a monitoring point of view, Mission Control provides a Management Console to monitor the garbage-collection behavior, processor utilization by the JVM, memory allocation, thread utilization, and some other useful monitoring metrics.

Mission Control is a standalone application, so it must be started either locally from the same machine that WebLogic is running on or from a remote workstation.

If you run Mission Control locally on the Linux server prod01, an X window must be available.

This recipe will run Mission Control in a Microsoft Windows desktop and will remotely connect and monitor the PROD_Server01 Managed Server.

Getting ready

Oracle JRockit must be downloaded and installed in the Windows desktop. Download Oracle JRockit 6 for Microsoft Windows at http://www.oracle.com/technetwork/ middleware/jrockit/downloads. The filename is jrockit-jdk1.6.0_XXX-windowsiaYY. exe, where XXX stands for the JRockit release and JDK version and YY stands for 32 bits or 64 bits. Choose the version that matches your desktop and accept the license agreement to download it.

How to do it...

Enable the PROD_Server01 Managed Server to accept JMX connections from Mission Control:

  1. Access the Administration Console with your web browser at http://adminhost.domain.local:7001/console.

  2. Click on the Lock & Edit button to start a new edit session.

  3. Click on the plus sign to open the Environment tree on the left and then click Servers.

  4. Click on the PROD_Server01 link and then click the Server Start tab.

  5. Add the following to the Arguments field and click on the Save button:

    -Xmanagement:autodiscovery=false,authenticate=false,ssl=fa
    lse,interface=prodsrv01.domain.local,port=8081 -Djava.rmi.
    server.hostname=prodsrv01.domain.local -Djavax.management.
    builder.initial=weblogic.management.jmx.mbeanserver.
    WLSMBeanServerBuilder

  6. Click on the Activate Changes button.

  7. Restart PROD_Server01.

Start Mission Control on the desktop, as follows:

  1. Start Mission Control by double-clicking on the Oracle JRockit Mission Control icon.

  2. On the JVM Browser panel to the left, right-click on the Connectors folder and click on the New Connection option.

  3. Type prodsrv01.domain.local in the Host field and 8081 in the Port field and click on the Finish button.

  4. Right-click on the newly created connection, prodsrv01.domain.local:8081, and click on the Start Console menu option.

How it works...

Mission Control connects to the specified host and port defined in the Xmanagement start-up argument and starts monitoring the PROD_Server01 JVM.

Add the start-up arguments to monitor the other WebLogic instances. Mission Control can connect to any running JRockit JVM.

Monitoring Linux with SAR

A Linux host with Red Hat Enterprise Linux or Oracle Linux can be monitored using the SAR command-line utility. The SAR is included in the SYSSTAT package bundle and is usually included with these Linux distributions.

SAR retrieves activity counters of the operational system, such as CPU, memory, disk, and network I/O usage. By default, it keeps a history of seven days, so it is a very useful tool to retrieve past reports and quickly search for behavioral patterns.

This recipe will retrieve some statistics from the prod01 machine using the SAR command-line utility.

Getting ready

SAR should already be installed in a Red Hat or Oracle Linux distribution. If it is not installed, you can use the yum package management utility to install the SYSSTAT package, which includes SAR.

As root user, execute the yum command and follow the onscreen instructions to install SYSSTAT:

[root@prod01]$ yum install sysstat

All SAR commands are executed from the Linux shell. Log in to the host first. The root user is used only to install the SYSSTAT package.

How to do it...

To retrieve the queue length and load averages from the current day, as a wls user execute the following command:

[wls@prod01]$ sar -q

This will display the following result:

To retrieve a past CPU usage from the 21st day of the month, as a wls user execute the following command:

[wls@prod01]$ sar –u –f /var/log/sa/sa21

This will display the following result:

The default SAR configuration keeps historical data for a week.

How it works...

The SAR utility is very flexible and provides a quick way to watch the host behavior for the current day and for the past seven days. SAR runs every 10 minutes and saves a summary at the end of the day.

These are the default values in the crontab and can be adjusted.

There's more...

Apart from the options discussed earlier, we can view more fine-grained data as well.

Collecting SAR data every minute

SAR can store statistical data in a more fine-grained time interval.

Log in as a root user to the shell and execute the following command:

[root@prod01]$ vi /etc/cron.d/sysstat

Locate the following lines:

# run system activity accounting tool every 10 minutes
*/10 * * * * root /usr/lib64/sa/sa1 1 1

Change these lines to the following:

# run system activity accounting tool every 1 minute
*/1 * * * * root /usr/lib64/sa/sa1 1 1

Type :wq! to save and close the file.

Oracle WebLogic Server 12c Advanced Administration Cookbook Over 60 advanced recipes to configure, troubleshoot, and tune Oracle WebLogic Server with this book and ebook
Published: June 2013
eBook Price: $29.99
Book Price: $49.99
See more
Select your format and quantity:

Sending e-mail notifications with WLDF

The WebLogic Diagnostic Framework (WLDF) is a set of functionalities to monitor, collect, and analyze runtime counters, metrics, and statistical and diagnostic data from various WebLogic Server components. The metrics can be gathered from the JRockit JVM, the WebLogic domain, the WebLogic clusters, Managed Servers, applications, and every component that exposes data through MBeans.

WebLogic Administrators can include active monitoring in production environments with WLDF. It is possible to configure WebLogic to send e-mail alerts when certain conditions and metrics are reached.

In this recipe, the WebLogic domain will be configured to send e-mail alerts when the WebLogic thread pool from a Managed Server has queued requests waiting to be processed.

Getting ready

A mail session called EmailAlertMailSession and a diagnostic module named EmailAlertModule will be created using the Administration Console, so make sure the Administration Server is running.

How to do it...

Follow these steps to create the EmailAlertMailSession mail session:

  1. Access the Administration Console with your web browser at http://adminhost. domain.local:7001/console.

  2. Click on the Lock & Edit button to start a new edit session.

  3. Click on the plus sign to open the Services tree on the left and then click on Mail Sessions.

  4. Click on the New button and type EmailAlertMailSession in the Name field. Type mail/emailAlertMailSession in the JNDI Name field.

  5. Add to JavaMail the properties needed according to the SMTP Server used:

    mail.smtp.host=<smtp-host>
    mail.smtp.port=<smtp-port>

  6. Click on the Next button and select the All servers in the cluster target. Click on the Finish button.

  7. Click on the Activate Changes button to finish.

Follow these steps to create the EmailAlertModule WLDF module:

  1. Access the Administration Console with your web browser at http://adminhost. domain.local:7001/console.

  2. Click on the Lock & Edit button to start a new edit session.

  3. Click on the plus sign to open the Diagnostics tree on the left and then click on Diagnostic Modules.

  4. In the Summary of Diagnostic Modules page, click on the New button.

  5. Type EmailAlertModule in the Name field and click on the OK button.

  6. Click on the newly created EmailAlertModule WLDF module and then on the Targets tab. Select the All servers in the cluster radio button and click on the Save button.

  7. Click on the Configuration tab and then the Collected Metrics tab. Change the Sampling Period value to 60000 and click on the Save Button.

  8. Click on the New button in the Collected Metrics in this Module table to create a new Harvester.

  9. Choose ServerRuntime from the MBean Server location drop-down menu and click on the Next button.

  10. Select weblogic.management.runtime.ThreadPoolRuntimeMBean from the MBean Type drop-down menu and click on the Next button.

  11. Select the QueueLength item from the Collected Attributes table on the left and click on the > icon to move it to the Chosen table on the right. Click on the Next button.

  12. In the Select Instances page, leave the Chosen Collected Instances and Instance Expressions textboxes empty and then click on the Finish button.

Follow these steps to create the watches and notifications for the WLDF module:

  1. Click on the Watches and Notifications tab and then on the Notifications tab below. Click on the New button to create a new notification.

  2. Select the SMTP (E-Mail) option in the Type drop-down menu and click on the Next button.

  3. Type EmailAlertNotification in the Notification Name field and click on the Next button.

  4. Select the EmailAlertMailSession option from the Mail Session Name drop-down menu. Type an e-mail address in the E-Mail Recipients textbox and click on the Finish button. This e-mail address will receive the alerts.

  5. Now click on the Watches tab and click on the New button to create a new watch.

  6. Type EmailAlertWatch in the Watch Name field. Leave the Collected Metrics option selected in the Watch Type field and click on the Next button.

  7. Click on the Add Expressions button to add a new expression rule.

  8. Select the ServerRuntime option from the MBean Server location drop-down menu and then click on the Next button.

  9. Select weblogic.management.runtime.ThreadPoolRuntimeMBean from the MBean Type drop-down menu and click on the Next button.

  10. Select the Enter a custom Instance radio button and type com.bea:Name=Thread PoolRuntime,ServerRuntime=PROD_Server*Type=ThreadPoolRuntime in the Custom Instance field. Click on the Next button.

  11. Select the QueueLength option from the Message Attribute drop-down menu and select the > option from the Operator drop-down menu and type 100 in the Value field. Click on the Finish button.

  12. On the following screen, click on the Finish button again.

  13. Click on the EmailAlertWatch to assign the notification. Click the Notifications tab.

  14. Select EmailAlertNotification from the Available table to the left and click on the > icon to move it to the Chosen table to the right. Click on the Save button.

  15. Click on the Activate Changes button to finish.

How it works...

WLDF is a very powerful framework and helps WebLogic Administrators to properly monitor a WebLogic domain.

The diagnostic module was created with a WLDF Harvester for the QueueLength attribute of the ThreadPoolRuntimeBean MBean and a sampling period of 60000. The sampling period is the interval between metric-collection cycles, in milliseconds. The data collected by the harvester is stored in a WLDF archive.

The default archive is stored in a file-based format at $DOMAIN_HOME/ servers/<serverName>/data/store/diagnostics.

The WLDF archive can use a JDBC-based store to persist the collected data.

The scenario of 100 queued requests waiting to be processed can indicate a potential problem because all threads of the WebLogic Server thread pool could be busy and the requests will not be processed fast enough, causing the incoming requests to pile up. The EmailAlertWatch watch was created for such situations to observe when the QueueLength value is greater than 100. When this condition is reached, the watch triggers an event to the EmailAlertNotification notification and an e-mail is sent to the specified recipients.

The notification can also be configured as an SNMP trap, a JMS message, a JMX operation, or a Diagnostic Image.

The WLDF is very flexible and can be configured with any attribute of the exposed MBean. Set up a watch expression that meets the condition and the monitoring requirements of your environment.

See also

  • Generating a SNMP trap

  • Viewing historical data in the monitoring dashboard using a database

Generating an SNMP trap

WebLogic provides Simple Network Management Protocol (SNMP) standards to monitor the domain, Managed Servers, and applications the same way the exposed MBean's attributes were monitored in the last recipe using WLDF.

In this recipe, an SNMP agent will be added to monitor all Managed Servers of the PROD_ Domain, watching for the same QueueLength attribute of the ThreadPoolRuntime MBean.

An SNMP trap will be triggered by adding a gauge monitor to verify if the QueueLength value is above 100.

Getting ready

The Server SNMP agent called PROD_SNMPAgent will be created using the Administration Console, so make sure the Administration Server is running.

This recipe assumes there is an SNMP Manager listening for an SNMP trap at the hostname snmphost on port 162.

How to do it...

Follow these steps to create the Server SNMP Agent:

  1. Access the Administration Console with your web browser at http://adminhost. domain.local:7001/console

  2. Click on the Lock & Edit button to start a new edit session.

  3. Click on the plus sign to open the Diagnostics tree on the left and then click on SNMP.

  4. Click on the New button from the Server SNMP Agent. Type PROD_SNMPAgent in the Name field and click on the OK button.

  5. Click on the newly created SNMP Agent, PROD_SNMPAgent.

  6. Click on the Enabled checkbox to enable it. Type 1610 in the SNMP UDP Port field and 7050 in the Master AgentX Port field. Click on the Save button.

  7. Click on the Targets tab and select the All servers in the cluster option from the PROD_Cluster target. Click on the Save button.

Follow these steps to create the gauge monitor and the SNMP trap:

  1. Click on the Configuration tab and then on the Gauge Monitors tab. Click on the New button to create a new SNMP Gauge Monitor.

  2. Type QueueLengthGauge in the Name field. Select the ThreadPoolRuntime option from the Monitored MBean Type drop-down menu. Click on the Next button.

  3. Select the QueueLength option from the Monitored Attribute Name drop-down menu and click on the Finish button.

  4. Click on the newly created QueueLengthGauge gauge and type 100 in the Threshold High field. Click on the Save button.

  5. Click on the Servers tab and enable the PROD_Server01, PROD_Server02, PROD_Server03, and PROD_Server04 checkboxes. Click on the Save button.

  6. Go to Diagnostics | SNMP on the left tree again and click on the PROD_SNMPAgent link.

  7. Click on the Trap Destinations tab and click on the New button.

  8. Type QueueLengthTrap in the Name field. Type snmphost in the Host field and 162 in the Port field. Click on the OK button.

  9. Click on the Activate Changes button to finish.

How it works...

The same notification from the previous recipe was created, but in this recipe instead of sending an e-mail alert using WLDF, a SNMP trap is generated to a hypothetical SNMP Manager running at snmphost on port 162.

The threshold condition is the same. The SNMP trap is sent when the QueueLength attribute from the WebLogic thread pool from a Managed Server of the PROD_Cluster value is above 100.

The trap generated has the following format:

--- Snmp Trap Received ---
Version : v1
Source : UdpEntity:<source_ip>:1610
Community : public
Enterprise : enterprises.140.625
AgentAddr : <source_ip>
TrapOID : enterprises.140.625.0.75
RawTrapOID : 1.3.6.1.4.1.140.625.0.75
Trap Objects : {
{ enterprises.140.625.100.5=Sun Nov 11 15:50:55 BRST 2012 }
{ enterprises.140.625.100.10=PROD_Server02 }
{ enterprises.140.625.100.55=jmx.monitor.gauge.high }

{ enterprises.140.625.100.60=100 }
{ enterprises.140.625.100.65=435 }
{ enterprises.140.625.100.70=com.bea:Name=ThreadPoolRuntime,Server
Runtime=PROD_Server02,Type=ThreadPoolRuntime }
{ enterprises.140.625.100.75=ThreadPoolRuntime }
{ enterprises.140.625.100.80=QueueLength }
}

The previous SNMP trap example was triggered from PROD_Server02 and the QueueLength attribute was 435 at the time.

There's more...

Now we will see how to create an SNMP agent through WLST.

Creating the SNMP Agent by using WLST

  1. Log in as a wls user to the shell and start WLST.

    [wls@prod01]$ $WL_HOME/common/bin/wlst.sh

  2. Connect to the Administration Server using wlsadmin as user, <pwd> as the password, and t3://adminhost.domain.local:7001 as the server URL.

    wls:/offline> connect("wlsadmin","<pwd>","t3://adminhost.domain.
    local:7001")

  3. Run the following WLST commands:

    edit()
    startEdit()
    cmo.createSNMPAgentDeployment('PROD_SNMPAgent')
    cd('/SNMPAgentDeployments/PROD_SNMPAgent')
    cmo.setMasterAgentXPort(7050)
    cmo.setEnabled(true)
    cmo.setSNMPPort(1610)
    cmo.setPrivacyProtocol('NoPriv')
    cmo.createSNMPGaugeMonitor('QueueLengthGauge')
    cd('/SNMPAgentDeployments/PROD_SNMPAgent/SNMPGaugeMonitors/
    QueueLengthGauge')
    cmo.setMonitoredMBeanType('ThreadPoolRuntime')
    cmo.setMonitoredAttributeName('QueueLength')
    set('EnabledServers',jarray.array([ObjectName('com.bea:Name=PROD_
    Server01,Type=Server'), ObjectName('com.bea:Name=PROD_
    Server02,Type=Server'), ObjectName('com.bea:Name=PROD_
    Server03,Type=Server'), ObjectName('com.bea:Name=PROD_
    Server04,Type=Server')], ObjectName))
    cmo.setThresholdHigh(100)
    cmo.setMonitoredMBeanName('(None)')
    cmo.setMonitoredMBeanName('')
    cd('/SNMPAgentDeployments/PROD_SNMPAgent')
    set('Targets',jarray.array([ObjectName('com.bea:Name=PROD_
    Cluster,Type=Cluster')], ObjectName))
    cmo.createSNMPTrapDestination('QueueLengthTrap')
    cd('/SNMPAgentDeployments/PROD_SNMPAgent/SNMPTrapDestinations/
    QueueLengthTrap')
    cmo.setPort(16200)
    cmo.setSecurityLevel('noAuthNoPriv')
    activate()
    exit()

See also

  • Sending e-mail notifications with WLDF

Oracle WebLogic Server 12c Advanced Administration Cookbook Over 60 advanced recipes to configure, troubleshoot, and tune Oracle WebLogic Server with this book and ebook
Published: June 2013
eBook Price: $29.99
Book Price: $49.99
See more
Select your format and quantity:

Creating a Monitoring Dashboard custom view

The Monitoring Dashboard is embedded with the Oracle WebLogic Server 12c. The dashboard is an application deployed in the Administration Server and is accessible at the URL http://adminhost.domain.local:7001/console/dashboard.

The Monitoring Dashboard can graphically display the metrics collected from the WLDF and exposed by the MBeans.

In this recipe, a Dashboard custom view will be created to display the Queue Length attribute from the ThreadPoolRuntime MBean of the PROD_Server01 Managed Server. This is the same attribute monitored in the previous recipes.

Getting ready

The Monitoring Dashboard is a functionality of the Administration Console. Make sure the Administration Server is running.

How to do it...

Carry out the following steps to create a custom view:

  1. Access the Monitoring Dashboard with your web browser at http://adminhost.domain.local:7001/console/dashboard.

  2. From the View List tab, click on My Views and then on the down arrow to display the drop-down menu. Click on the New View menu option.

  3. Type QueueLengthView to set the View name.

  4. Click on the arrow down on the chart of the display pane to the right. Click on New Chart.

  5. Click on the Metric Browser tab, select the PROD_Server01 option from the Servers drop-down menu, and click on the GO button.

  6. Click on the ThreadPool item from the Types selection list and then on the ThreadPoolRuntime from the Instances selection list. Click on the QueueLength (int) option and drag it to the QueueLengthView chart on the right display panel.

  7. Click on the green start button on the left to start collecting.

How it works...

A custom view was created with a new chart to display the QueueLength counter metrics. The QueueLength attribute is collected directly from the exposed ThreadPoolRuntime MBean.

Other charts can be created and any other exposed runtime MBean attribute can be added. The QueueLength attribute from the other Managed Servers of the PROD_Cluster cluster can also be added to the same chart.

The chart polls for the online and real-time statistics, keeping by default 100 samples of 20 second intervals each, giving about 30 minutes of time range.

See also

  • View Historical Data in the Monitoring Dashboard using a Database

Viewing historical data in the monitoring dashboard using a database

In the previous recipe, a Dashboard custom view was created to display the QueueLength attribute of the ThreadPoolRuntime MBean of the Managed Servers of the PROD_Cluster cluster.

The Dashboard can collect the data from two sources. One is from the exposed MBeans, displaying polled runtime statistics like the previous recipe. The other form is from the WLDF archive data collected from a WLDF harverster. This stored data is called collected metrics by the Monitoring Dashboard.

In this recipe, the PROD_Server01, PROD_Server02, PROD_Server03, and PROD_Server04 WLDF archives will be configured to use a database instead of the default file-based archive to hold the data collected from a WLDF Harvester. A new custom view will be created to display this data and it will be able to display all the collected historical data instead of the default 30 minutes collected from the polled collector. The QueueLength attribute will be used.

The database is an Oracle database, running in the dbhost hostname and listening to the port 1521. The listener is accepting requests to the service named dbservice.

Getting ready

The recipe will use the database dbhost, so create a new JDBC data source named ds-wldf-archive, with a JNDI name jdbc/ds-wldf-archive targeted to the PROD_Cluster cluster.

The database tables WLS_EVENTS and WLS_HVST have to be created. WebLogic uses these tables to store the WLDF archive data.

The Monitoring Dashboard is a functionality of the Administration Console. Make sure the Administration Server is running.

How to do it...

Follow these steps to create tables in the Oracle dbhost database:

  1. Connect to the database at dbhost, port 1521, and service name dbservice.

  2. Run the following SQL script:

    DROP TABLE WLS_EVENTS;
    CREATE TABLE WLS_EVENTS (
    RECORDID number NOT NULL,
    TIMESTAMP number default NULL,
    CONTEXTID varchar2(128) default NULL,
    TXID varchar2(32) default NULL,
    USERID varchar2(32) default NULL,
    TYPE varchar2(64) default NULL,
    DOMAIN varchar2(64) default NULL,
    SERVER varchar2(64) default NULL,
    SCOPE varchar2(64) default NULL,
    MODULE varchar2(64) default NULL,
    MONITOR varchar2(64) default NULL,
    FILENAME varchar2(64) default NULL,
    LINENUM number default NULL,
    CLASSNAME varchar2(250) default NULL,
    METHODNAME varchar2(64) default NULL,
    METHODDSC varchar2(4000) default NULL,
    ARGUMENTS clob default NULL,
    RETVAL varchar2(4000) default NULL,
    PAYLOAD blob default NULL,
    CTXPAYLOAD varchar2(4000),
    DYES timestamp default NULL,
    THREADNAME varchar2(128) default NULL
    );
    DROP TABLE WLS_HVST;
    CREATE TABLE WLS_HVST (
    RECORDID number NOT NULL,
    TIMESTAMP number default NULL,
    DOMAIN varchar2(64) default NULL,
    SERVER varchar2(64) default NULL,
    TYPE varchar2(64) default NULL,
    NAME varchar2(250) default NULL,
    ATTRNAME varchar2(64) default NULL,
    ATTRTYPE number default NULL,
    ATTRVALUE varchar2(4000)
    );
    DROP SEQUENCE MON_EVENTS;
    CREATE SEQUENCE MON_EVENTS
    START WITH 1
    INCREMENT BY 1
    NOMAXVALUE;
    DROP TRIGGER TRIG_EVENTS;
    CREATE TRIGGER TRIG_EVENTS
    BEFORE INSERT ON WLS_EVENTS
    FOR EACH ROW
    BEGIN
    SELECT MON_EVENTS.NEXTVAL INTO :NEW.RECORDID FROM DUAL;
    END;
    /
    DROP SEQUENCE MON_HVST;
    CREATE SEQUENCE MON_HVST
    START WITH 1
    INCREMENT BY 1
    NOMAXVALUE;
    DROP TRIGGER TRIG_HVST;
    CREATE TRIGGER TRIG_HVST
    BEFORE INSERT ON WLS_HVST
    FOR EACH ROW
    BEGIN
    SELECT MON_HVST.NEXTVAL INTO :NEW.RECORDID FROM DUAL;
    END;
    /

Follow these steps to create the JDBC data source:

  1. Access the Administration Console with your web browser at http://adminhost. domain.local:7001/console.

  2. Click on the Lock & Edit button to start a new edit session.

  3. Click on the plus sign to open the Services tree on the left and then click Data Sources.

  4. Click on the New button and click on Generic Data Source.

  5. Type ds-wldf-archive in the Name field and jdbc/ds-wldf-archive in the JNDI Name. Leave the Database Type drop-down menu with the Oracle option selected. Click on the Next button.

  6. Choose *Oracle's Driver (Thin) for Service connections; Versions:9.0.1 and later from the Database Driver drop-down menu. Click on the Next button.

  7. Leave the Transaction options with the default values and click on the Next button.

  8. In the Connection Properties page, type dbservice in the Database Name field, dbhost in the Host Name field, and 1521 in the Port field. Complete the Database User Name, Password, and Confirm Password fields with dbuser and dbpwd. Click on the Next button.

  9. Click on the Next button in the Test Database Connection page.

  10. Click on each Managed Server checkbox of the PROD_Cluster cluster. Don't click on the All servers in the cluster radio button. Click on the Finish button.

  11. Click on the Activate Changes button to finish.

Follow these steps to configure the WLDF archive to store the data to a JDBC based store:

  1. Access the Administration Console with your web browser at http://adminhost. domain.local:7001/console.

  2. Click on the Lock & Edit button to start a new edit session.

  3. Click on the plus sign to open the Diagnostics tree on the left and then click on Archive.

  4. Click on the PROD_Server01 Managed Server.

  5. Select the JDBC option from the Type drop-down menu. Select the ds-wldfarchive option from the Data Source drop-down menu. Click on the Save button.

  6. Repeat the previous steps for the PROD_Server02, PROD_Server03, and PROD_Server04 Managed Servers.

  7. Click on the Activate Changes button.

Follow these steps to create a new WLDF module and a new WLDF Harvester:

  1. Access the Administration Console with your web browser at http://adminhost. domain.local:7001/console.

  2. Click on the Lock & Edit button to start a new edit session.

  3. Click on the plus sign to open the Diagnostics tree on the left and then click on Diagnostic Modules.

  4. In the Summary of Diagnostic Modules page, click on the New button.

  5. Type QueueLengthModule in the Name field and click on the OK button.

  6. Click on the newly created QueueLengthModule module and click on the Targets tab. Select the All servers in the cluster radio button and click on the Save button.

  7. Click on the Configuration tab and then the Collected Metrics tab. Change the Sampling Period to 60000 and click on the Save Button.

  8. Click on the New button in the Collected Metrics in this Module table to create a new WLDF harvester.

  9. Choose ServerRuntime from the MBean Server location drop-down menu and click on the Next button.

  10. Select weblogic.management.runtime.ThreadPoolRuntimeMBean from the MBean Type drop-down menu and click on the Next button.

  11. Select the QueueLength item from the Collected Attributes table on the left and click the > icon to move it to the Chosen table on the right. Click on the Finish button.

  12. Click on the Activate Changes button and restart all Managed Servers.

Follow these steps to create a new custom view in the Monitoring Dashboard:

  1. Access the Monitoring Dashboard with your web browser at http://adminhost. domain.local:7001/console/dashboard.

  2. From the View List tab, click on My Views and then click on the down arrow to display the drop-down menu. Click on the New View menu option.

  3. Type in QueueLengthCollectedView to set the View name.

  4. Click on the down arrow on the chart of the display pane to the right. Click on New Chart.

  5. Click on the Metric Browser tab and then enable the Collected Metrics Only checkbox. Select the PROD_Server01 option from the Servers drop-down menu and click on the OK button.

  6. Click on the ThreadPool item from the Types selection list and then click on ThreadPoolRuntime from the Instances selection list. Click on the QueueLength (int) option and drag it to the QueueLengthCollectView chart on to the display panel to the right.

  7. Repeat steps 5 and 6 and add the metrics from the PROD_Server02, PROD_Server03, and PROD_Server04 Managed Servers.

How it works...

A custom view was created with a new chart to display the QueueLength counter metrics of the WLDF archive stored in the database.

This chart can be used to display historical data and uses the time range stored in the database's WLDF archive. This is an important tool to understand the Managed Servers' behavioral data and past events in production environments.

See also

  • Sending e-mail notifications with WLDF

  • Creating a Monitoring Dashboard custom view

Summary

This article focused on showing the system administrators how to use the tools and features to monitor WebLogic. It did not intend to provide the metrics and thresholds that should be used.

Resources for Article :

 


Further resources on this subject:


About the Author :


Dalton Iwazaki

Dalton Iwazaki lives in Sao Paulo, Brazil and started working with technology in 1994 in a school lab, at the age of 17. As a system administrator, Dalton configured and maintained the network (Novel 3.12), the computers (Window 3.11, Windows NT 4.0, Windows 95), and the Internet. He also took his first steps in programming by building the school website in ASP and a computer voting system to simulate the election process in Delphi.

In 1999, Dalton moved to a new company and started working with Java development. During this period, he worked on many Java server-side applications and dug deep to understand the use of JDBC, JMS, JMX, XML, and multithreaded applications. He built some frameworks from scratch to help the development, and started working on the Application Server world with IBM Websphere, Resin, Tomcat, JBoss, and BEA WebLogic. Until 2004, Dalton moved around to other companies working either as a Java developer or Java Architect.

In 2004 and 2005, Dalton worked as a Software Development Manager; he lead 10 developers to build the entire website, provisioning and back office operations of a new ISP Provider with a variety of integrations and languages, such as Java, VB, C#, Perl, and PHP. Dalton then moved to a large international bank to work as a project manager in 2005 and 2006. His role was to manage the Internet Banking and Credit Card portals and integrate the business clients and the development team. From 2006 to 2008, Dalton started and worked on his own company, a design agency focused on the delivery of web solutions.

In 2008, Dalton started working in partnership with Oracle Consulting on the infrastructure level of the WebLogic Server. In the following year, Dalton started a new company named VN Tecnologia, an IT professional services provider and Oracle Partner Network member. Working together with Oracle's clients and projects, Dalton's solid expertise in infrastructure and Java development are a rare combination used in his specializations - WebLogic Server configuration, administration, troubleshooting, and tuning. You can reach Dalton Iwazaki at dalton.iwazaki@gmail.com.

Books From Packt


Securing WebLogic Server 12c [Instant]
Securing WebLogic Server 12c [Instant]

Getting Started with Oracle WebLogic Server 12c: Developer’s Guide
Getting Started with Oracle WebLogic Server 12c: Developer’s Guide

Middleware Management with Oracle Enterprise Manager Grid Control 10g R5
Middleware Management with Oracle Enterprise Manager Grid Control 10g R5

EJB 3.0 Database Persistence with Oracle Fusion Middleware 11g
EJB 3.0 Database Persistence with Oracle Fusion Middleware 11g

Getting Started With Oracle SOA Suite 11g R1 – A Hands-On Tutorial
Getting Started With Oracle SOA Suite 11g R1 – A Hands-On Tutorial

Oracle APEX 4.0 Cookbook
Oracle APEX 4.0 Cookbook

Oracle Weblogic Server 11gR1 PS2: Administration Essentials
Oracle Weblogic Server 11gR1 PS2: Administration Essentials

Oracle WebLogic Server 12c: First Look
Oracle WebLogic Server 12c: First Look


No votes yet

Post new comment

CAPTCHA
This question is for testing whether you are a human visitor and to prevent automated spam submissions.
K
V
p
G
L
9
Enter the code without spaces and pay attention to upper/lower case.
Code Download and Errata
Packt Anytime, Anywhere
Register Books
Print Upgrades
eBook Downloads
Video Support
Contact Us
Awards Voting Nominations Previous Winners
Judges Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software
Resources
Open Source CMS Hall Of Fame CMS Most Promising Open Source Project Open Source E-Commerce Applications Open Source JavaScript Library Open Source Graphics Software